WordPress е много популярен начин за бързо стартиране и работа на сайт. В бързината си обаче много разработчици в крайна сметка вземат ужасни решения. Някои грешки, като напускане WP_DEBUG зададено на true може да се направи лесно. Други, като обединяването на целия ви JavaScript в един файл, са толкова често срещани, колкото ленивите инженери. Която и грешка да успеете да допуснете, прочетете, за да разберете 12-те най-често срещани грешки в WordPress, които допускат нови и опитни разработчици. Ако откриете, че извършвате една от тези грешки, не се отчайвайте. Всяка грешка е възможност за учене.

1. Поставяне на JavaScript кода на WordPress тема в един основен файл

Веднъж, докато правех оптимизация на скоростта на страниците за уебсайтове на клиента, забелязах, че те използват първокласна тема, която съдържа всички библиотеки, които използват, включително персонализирания код, в един единствен файл, наречен main.js, theme.js или custom.js. Тази практика е лоша поради следните причини:

1. С времето файлът може да стане наистина голям, тъй като темата, която се развива активно, ще се разраства във функции и понякога ще виждате файлове с размер до 1 MB. Файлът ще бъде зареден за целия сайт, дори ако на някои страници са необходими само 10% от кода от файла. Това ще накара изтеглянето на страниците да отнеме повече време и да се покаже по-бавно, особено ако е така рендиране блокиране код в главната секция на страницата.
2. Това прави управлението на кода във файла по-трудно, тъй като не можете да използвате функции като wp_dequeue_script() за разтоварване на част от кода в някои страници, или за подобряване на скоростта на страницата, или за предотвратяване на конфликт с друг JavaScript код, който може да бъде зареден от един от активните плъгини. Разбира се, файлът може да бъде разделен на множество и поставен в опашка в WordPress, но ако в някакъв по-късен момент администраторът на уебсайта извърши актуализация на темата main.js файл, тогава целият процес трябва да започне отначало.

2. Използване на имена, които са твърде често срещани за променливи, функции, константи или класове

Когато разработвате приставка, по-добре е да използвате конвенция за именуване, която предотвратява конфликт на код, в случай че има други плъгини, използващи същото име. Ето защо много разработчици добавят префиксите на своите променливи и имена на функции с нещо уникално и свързано със самия плъгин. Освен премахването на конфликта на кода, той също така улеснява намирането, когато имате активирани много плъгини.

Има разработчици, от друга страна, които предпочитат да използват PHP пространства от имена, за да капсулират елементи и да решат двата проблема, с които се сблъскват авторите на библиотеки и приложения, когато създават елементи за многократна употреба като класове или функции:

1. Именувайте сблъсъци между кода, който те създават, и вътрешен PHP, или трети страни, класове, функции или константи
2. Възможност за псевдоним (или съкращаване) Extra_Long_Names предназначен за отстраняване на първия проблем или подобряване на четливостта на изходния код. Този ми е любим, тъй като често разработвам теми или приставки, които имат много код. С това мога лесно да чета и управлявам кода, без да се притеснявам много, че имам дълги уникални имена.

Бих препоръчал добро разбиране на пространствата от имена, преди да ги използвате, тъй като те често могат да бъдат използвани по грешен начин.

В зависимост от проекта, който ще вземете на борда, е вероятно да се наложи да се придържате към съществуващия стил на кодиране, освен ако работата ви не е отделена предимно от съществуващата. В случай, че трябва да разширите съществуващ плъгин или тема, която вече следва PHP стандарти за кодиране за WordPress, тогава е най-добре да се придържате към тях, за да имате последователен стил, така че кодът да стане изчистен и лесен за четене. Имайте предвид, че някои правила се прилагат универсално с цел подобряване на производителността, като се пренебрегва стила на кодиране. Например, винаги е най-добре да използвате единични кавички (вместо двойни), ако не оценявате нищо в низа. Също така кодът трябва да бъде отстъпен, за да бъде прочетен, особено ако има вложен код (напр. IF S в IF s, вложени FOREACH s и FOR с).

3. Не използвайте съществуващата основна функционалност на WordPress до истинския й потенциал

Тъй като WordPress се предлага с набор от редовно актуализирани библиотеки, които могат просто да бъдат извикани в нашите плъгини и теми, най-добре е просто да се възползвате максимално от съществуващата основна функционалност. Виждал съм теми и приставки на WordPress, които са имали файлове в директорията на активите си, които вече са били в основните файлове на WordPress (напр. JQuery или Color Picker). Освен факта, че пакетът ще стане по-голям и ще отнеме повече време за зареждане по мрежата, вие също трябва да се уверите, че всички библиотеки на трети страни се актуализират редовно, което е просто още нещо, за което трябва да се погрижите.

Използвайте това, което WordPress вече може да предложи, тъй като библиотеките вече са актуализирани от основния екип за разработка на WordPress и можете да имате лек и по-лесен за поддръжка проект. Чрез редовното извършване на актуализации на WordPress получавате достъп до повече функции (независимо дали става дума за плъгин, тема или самото ядро ​​на WordPress, тъй като неговото табло за управление непрекъснато се подобрява) и правите уебсайта по-сигурен, в случай че в старите версии на кода бъдат открити уязвимости.

4. Не правите плъгина или темата лесни за промяна чрез действия и филтри

Редактирането на приставка или тема на WordPress директно е лоша идея, освен ако, разбира се, не сте пряко ангажирани с разработването на този пакет и не допринасяте за неговия код. Ако се извърши автоматична актуализация на приставката или темата, тогава всички директни промени в пакета ще бъдат загубени и ще трябва да редактирате файловете отново.

Ето защо използването на действия и филтри, както и създаването на дъщерна тема (която разширява родителската тема) са най-ефективните подходи за модифициране на тема, тъй като можете да промените съществуващата функционалност, без да редактирате родителската тема или самата приставка. Освен това, ако предлагате плъгин за безплатно изтегляне на WordPress.org и по-късно искате да създадете премиум разширение, което ще зависи от родителския плъгин, тогава трябва да разработите безплатния плъгин по такъв начин, че да бъде лесно да се разширява и да добавя премиум разширения към

5. Разработване с WP_DEBUG Зададено на false

По подразбиране WP_DEBUG константата е зададена на „false“, за да се избегне печатане на PHP грешки, предупреждения и известия. В среда на живо това е препоръчителен избор, тъй като запазва частни сървърни пътеки и скриптове скрити от публичния изглед, което е чудесно от съображения за сигурност. По време на етапа на разработка обаче е най-добре той да бъде настроен на „true“, тъй като ще ни уведомява за всякакви грешки в нашия код. Дори ако грешките не засягат пряко функционалността, това често ще ви принуди да напишете по-добър код и да развиете по-добри навици за кодиране. Случи ми се. Това също ще гарантира, че приставката или темата, които разработвате, не генерират PHP грешки в нито една инсталация на WordPress.

Въпреки че това е нещо, което правят повечето опитни разработчици, това се случва, особено в бързаме. Колкото и спешна да е работата, разработчиците винаги трябва да се опитват да поддържат стандартите за кодиране на WordPress, като очевидно гледат най-добрите практики за PHP.

6. Писане на PHP код, без да се има предвид, че страницата може да бъде кеширана един ден

Това е често срещана грешка в PHP и, подобно на предишната, е сравнително лесно да се избегне, ако се придържате към стандартите за кодиране на PHP.

Някои разработчици имат навика да прилагат PHP фрагменти в теми и приставки, които са валидни само ако PHP кодът се задейства през цялото време. Например, трябва да се предприеме или не PHP функция, която отговаря на HTTP потребителския агент с определени действия (напр. Скриптове за поставяне в ред, предназначени само за мобилни потребители).

Ако вашият клиент инсталира приставка, която кешира страницата (например W3 Total Cache или WP Rocket), без да задейства условните елементи във вашата тема или приставки, вашият PHP код ще бъде направен безполезен. Ако целта е да се направят страниците отзивчиви, тогава това трябва да се направи от лицевата страна чрез медийни заявки и JavaScript. Последното, само ако наистина се изисква. В идеалния случай искате да избягвате използването на JavaScript, за да направите сайта си отзивчив.

7. Не проследяване на промените, направени по професионален начин чрез система за контрол на версиите като Git

Файловете, които са кодирани по поръчка, като дъщерна тема или персонализирана приставка, в идеалния случай трябва да бъдат под контрол на версиите. Git създава запис на промененото и позволява на разработчиците да работят заедно върху един и същ проект на WordPress или лесно да се върнат към предишна версия, когато нещо се обърка с уебсайта. Освен това клиентите могат да използват Git, за да проследяват цялата работна история, извършена от всички разработчици, наети за конкретния проект, особено ако това е голям, дългосрочен потребителски уебсайт на WordPress.

Въпреки че може да бъде смущаващо в началото, особено за млади разработчици, разбирането на Git ще си струва времето и софтуер на Git GUI като SourceTree (един от любимите ми) просто ще бъде начинът, по който взаимодействате с вашите хранилища на Git, правейки цялото кривата на обучение по-приятна. След като разберете как работи, помислете за проверка Git Най-добрите практики и съвети от разработчиците на ApeeScape това обяснява по-задълбочено няколко начина за използване на Git.

8. Опазване на CSS и JavaScript файлове, когато не са необходими

Наличието на много HTTP заявки би довело до по-бавно зареждане на уебсайта, като по този начин ще има по-нисък резултат в Google PageSpeed, което вероятно би повлияло на класирането при търсене. Това също може да доведе до грешки в JavaScript поради конфликти между плъгини. Например, може да има два плъгина, използващи обща библиотека jQuery, които могат да бъдат заредени два пъти и могат да причинят проблеми. И наистина, това е най-добрият пример, тъй като jQuery се зарежда многократно на уеб сайтове на живо няколко пъти. Това вероятно се случва поради лошо написани приставки или теми.

9. Използване на .php Файлове за извеждане на CSS или JavaScript код вместо статичен .css и .js Файлове

Виждал съм теми и дори приставки за WordPress, които са имали файлове като style.php които бяха използвани само за генериране на персонализиран CSS код и отпечатването му. Неща като цветове, размери на шрифта и разстояния около елементи бяха зададени в настройките на темата и след това запазени в базата данни. Тогава style.php се чете (напр.) И генерира CSS кода въз основа на персонализираните настройки, които са актуализирани в таблото за управление.

Това наистина е лоша практика по отношение на производителността на WordPress. Ето основните недостатъци, които идват с него:

1. Тъй като CSS файлът се зарежда в рамките на head (което е нормално и повечето от тях се зареждат по този начин), има проблем с производителността, който идва с това, тъй като браузърът трябва да изтегли файла напълно, преди да изобрази страницата. Ако средата на WordPress е бавна поради някои приставки, това значително ще забави времето за зареждане. Дори ако се използват техники за кеширане или се зарежда само част от средата на WordPress, за да се извлекат стойностите от базата данни. Най-добре е вместо това да използвате статичен .css файл.
2. Във PHP файла кодът (CSS правила, смесени с PHP променливи и условни клаузи) ще бъде по-труден за четене от разработчиците, когато трябва да проверят нещо. Разбира се, файлът може да се стартира в браузъра (въпреки че съм сигурен, че когато е отпечатан, той дори няма да бъде с отстъпи или приятно изглеждащ), но ако имате локално копие на проекта и прегледате кода на темата и имате нужда за да се намери синтаксис на CSS или JavaScript (в случай, че бъде използван script.php), това би затруднило четимостта.

Решението: Запазете всеки потребителски CSS извън директорията на приставката. Пример: /wp-content/uploads/theme-name-custom-css/style-5.css. По този начин, в случай че темата или приставката се актуализират, потребителският файл няма да бъде загубен.

10. Неизползване на правилната архитектура (кодова организация) за WordPress приставки и теми

В зависимост от размера и естеството на приставката (например самостоятелен плъгин или разширение на приставка, което работи само ако е активиран основен плъгин като WooCommerce), трябва да се настрои правилната архитектура и кодова организация.

Ако трябва да изградите еднозначен WordPress плъгин за клиент и той има ограничено взаимодействие с WordPress ядро, теми и други плъгини, не е ефективно да проектирате сложни класове, освен ако не сте сигурни, че плъгинът ще се разшири значително по-късно На.

Ако приставката ще бъде представена богата с много код, тогава използването на подход за кодиране на обектно ориентирано програмиране (OOP) (с много класове) би имало смисъл. Например, ако имате много кратки кодове, можете да ги запазите в отделен файл на класа като class.shortcodes.php или ако има CSS и JavaScript файлове, които са предназначени да бъдат заредени в таблото за управление и изглед отпред, тогава един клас като class.scripts.php може да се използва и да се поставят в опашка предните файлове в метод като enqueue_public_scripts() докато поставяте в опашка файловете, предназначени за зареждане в административната област в рамките на enqueue_admin_scripts() метод.

Вместо да смесвате HTML с PHP кода, по-добре е да го разделите, като внедрите шаблона MVC в плъгините и темите. Добър пример е приставката WooCommerce. Той има шаблони за различни оформления, които също могат лесно да бъдат презаписани чрез темата или различни филтри, само защото логиката е отделена от дизайна. Шаблонът, съдържащ HTML оформлението, се използва най-вече за отпечатване на вече обработената информация. Наличието на HTML код в PHP методите обикновено е лоша практика (разбира се, има изключения за малки битове HTML код), особено за приставка, която се поддържа от повече от един разработчик, докато нараства.

Според наръчника на WordPress Plugin, въпреки че има редица възможни модели на архитектура, те могат да бъдат групирани в три вариации:

• Файл с един плъгин, съдържащ функции
• Файл с един плъгин, съдържащ клас, екземпляр на обект и, по желание, функции
• Основен файл на приставката, след това един или повече файлове от класа

11. Не се отнасяйте сериозно към WordPress Security, когато пишете код

Сигурността често не се приема сериозно при разработката на WordPress, тъй като много начинаещи разработчици се фокусират повече върху резултатите, които клиентът иска. Всичко е наред, докато уебсайтът на клиента не бъде хакнат или вашата приставка, публикувана на WordPress.org, има уязвимост, оставяйки засегнати хиляди уебсайтове. Тези неща се случват понякога и дори ядрото на WordPress се е справяло с доста голям брой уязвимости в сигурността още от ранните дни на CMS. Нашата отговорност е да го направим възможно най-сигурен и, в случай че нещо се случи, да действаме своевременно и да се уверим, че пускаме солидна, добре тествана лепенка.

Някои от най-важните съвети за сигурност са:

XSS уязвимости: За да се избегне това, трябва да се направят две неща: хигиенизиране на въведените данни и хигиенизиране на изходните данни. В зависимост от данните и контекста, в който се използва, в WordPress има няколко метода за дезинфекция на кода. Човек не трябва да вярва на никакви входни данни, нито на данни, които ще бъдат отпечатани. Една обща функция за саниране на въвеждането на данни е sanitize_text_field() . Проверява за невалидни UTF-8 символи, конвертира единичниesc_url() функция, която отхвърля невалидни URL адреси, премахва невалидни символи и премахва опасни символи.

Предотвратяване на директен достъп до вашите файлове: Файловете могат да бъдат директно достъпни, тъй като повечето хостове позволяват това. Ако обаче това се случи и кодът не е написан правилно, за да се справи с него, може да се отпечатат някои грешки (напр. Липсващи функции или променливи, които не са декларирани), които да съдържат информация, ценна за потенциалните нападатели. Един често срещан кодов фрагмент, който често виждате в приставки и теми, е:

// Exit if accessed directly if ( ! defined( 'ABSPATH' ) ) exit;

Ако константата ABSPATH не е дефиниран (което трябва да е за всяка инсталация на WordPress), тогава скриптът ще излезе и няма да отпечата нищо.

Използвайте Nonces: Както е посочено в WordPress документация , nonce е „число, използвано веднъж“, което помага да се защитят URL адресите и формулярите от определени видове злоупотреба, злонамерено или друго.

Например следният URL в таблото за управление ще бъде използван за кошче на публикация: img/back-end/16/12-worst-mistakes-advanced-wordpress-developers-make.jpg - При достъп до този URL, WordPress ще провери информацията за бисквитките за удостоверяване и ако имате правилното разрешение (например, вие сте администратор с всички привилегии), тази публикация ще бъде изтрита.

Това, което атакуващият би могъл да направи, е да накара браузъра ви да осъществи достъп до този URL адрес без ваше знание, като създаде връзка на страница на трета страна, както е в следния пример: Когато отправяте тази заявка към WordPress, браузърът автоматично ще прикачи вашата бисквитка за удостоверяване и WordPress ще счита заявката за валидна.

Тогава се появява nonce, тъй като нападателят няма да може да получи лесно стойността nonce (генерирана за администратора, който всъщност е влязъл в WordPress). Новият URL адрес на заявката ще изглежда така: img/back-end/16/12-worst-mistakes-advanced-wordpress-developers-make.jpg&_wpnonce=b192fc4204

Без валиден nonce, забранен отговор 403 ще бъде изпратен до браузъра от WordPress с добре познатото съобщение за грешка: „Наистина ли искате да направите това?“

Въпреки че повечето хора не приемат сериозно сигурността на WordPress, мислейки, че уебсайтът им никога няма да бъде хакнат, доверявайки се на хостинга (което може да бъде полезно, но само до определен момент) и факта, че са закупили търговски плъгини / теми (които често водят до до предположението, че те са много сигурни), ние винаги трябва да правим тестове за проникване на нашите уебсайтове, за да идентифицираме уязвимости, които могат да бъдат използвани, преди някой хакер да може да ги идентифицира и използва.

Имайте предвид, че голям брой хакове там дори не се правят от един човек с намерението да хакнат конкретно вашия уебсайт. Често има ботове, които сканират автоматично уебсайтове на WordPress последователно и в момента, в който се намери известна уязвимост, тя се експлоатира и сървърът се използва за спам, получаване на лична информация от базата данни, поставяне на скрити връзки в определени страници на уебсайта, които ще доведе до всякакъв вид измамен уебсайт (например порнография, незаконни наркотици). Понякога хаковете са скрити толкова добре, че се нуждаете от правилно сканиране на вашия уебсайт и виждате датата, на която са актуализирани конкретни файлове, за да откриете хакнатия код. Ето защо е добре дори да преинсталирате WordPress (да, същата версия, ако имате последната), така че всички хакнати файлове да бъдат заменени от оригиналните основни файлове на WordPress.

12. Използване на WordPress функции и кодови фрагменти, без да ги разбираме

Често, когато разработчиците заседнат и намерят решение на места като StackOverflow, те са просто доволни от факта, че са успели да направят нещо да работи, без да се притесняват да разберат логиката зад този код или ако този код може да бъде променен, за да се зареди по-бързо или да има по-малко редове код.

Виждал съм тази практика толкова много пъти, когато фрагменти от код се копират в PHP скриптове, когато всъщност се използва само една трета от този код.

Това може да има няколко недостатъка, включително:

1. Кодът не използва същия стил като съществуващия код на проекта. Да, удобно е просто да копирате и поставяте фрагменти, които работят извън кутията и, въпреки че са подходящи за малък личен проект (може някой ден да се превърне в голям проект, кой знае), тази практика често не е добра, когато дойде към търговска работа, при която трябва да се поддържа последователност в стила.
2. Въпреки че кодът си върши работата, той може да съдържа неефективни функции, които не се препоръчват за задачата, която трябва да бъде постигната. Ако кодът не е оптимизиран, тази практика „копиране и поставяне“ може да доведе до бавен и по-труден за поддръжка уебсайт, особено ако на различни места в проекта се използват повече от един фрагмент.
3. Кодът може да не бъде лицензиран за повторна употреба и включването на кода в проект на клиента може да им създаде много правни проблеми.

Постоянно подобрение

Всеки допуска грешки и всяка грешка е възможност да се усъвършенствате. Като Разработчици на WordPress , нашата индустрия се движи с много бързи темпове и никога няма един „правилен начин“ да правим нещата. Колкото повече обаче тренирате и научавате, толкова по-добри ще станете.

Несъгласни ли сте с някоя от грешките, които посочих, или смятате, че съм пропуснал една? Кажете ми в коментарите и ще обсъдим.

Свързани: Моите пет най-лоши грешки в развитието на WordPress