12 худших ошибок, которые совершают продвинутые разработчики WordPress

WordPress — очень популярный способ быстро запустить сайт. Однако в спешке многие разработчики принимают ужасные решения. Некоторые ошибки, например, оставить WP_DEBUG true , легко допустить. Другие, такие как объединение всего вашего JavaScript в один файл, так же распространены, как и ленивые инженеры. Какую бы ошибку вы ни совершили, читайте дальше, чтобы узнать о 12 самых распространенных ошибках WordPress, которые совершают новички и опытные разработчики. Если вы обнаружите, что совершаете одну из этих ошибок, не отчаивайтесь. Каждая ошибка — это возможность учиться.

1. Размещение кода JavaScript темы WordPress в одном основном файле

Однажды, выполняя оптимизацию скорости страницы для веб-сайтов клиента, я заметил, что они используют тему премиум-класса, в которой все библиотеки, которые они используют, включая пользовательский код, находятся в одном файле с именем main.js , theme.js или custom.js . Эта практика плоха по следующим причинам:

1. Файл со временем может стать действительно большим, так как активно развиваемая тема будет расширяться в функциях, и иногда вы увидите файлы размером до 1 МБ. Файл будет загружен для всего сайта, даже если на некоторых страницах требуется только 10% кода из файла. Это приведет к тому, что страницы будут загружаться дольше и медленнее отображаться, особенно если код блокировки рендеринга находится в разделе заголовка страницы.
2. Это усложняет управление кодом внутри файла, поскольку вы не можете использовать такие функции, как wp_dequeue_script() , для выгрузки части кода на некоторых страницах, чтобы повысить скорость страницы или предотвратить конфликт с другим кодом JavaScript, который может быть загружается одним из активных плагинов. Конечно, файл можно разделить на несколько и поставить в очередь в WordPress, но если в какой-то момент администратор веб-сайта выполнит обновление файла main.js темы, то весь процесс придется начинать сначала.

2. Использование имен, которые слишком распространены для переменных, функций, констант или классов

При разработке плагина лучше использовать соглашение об именах, которое предотвращает конфликты кода в случае, если другие плагины используют то же имя. Вот почему многие разработчики добавляют к своим переменным и именам функций префикс чего-то уникального и связанного с самим плагином. Помимо устранения конфликта кода, это также упрощает поиск, когда у вас включено множество плагинов.

С другой стороны, есть разработчики, которые предпочитают использовать пространства имен PHP для инкапсуляции элементов и решения двух проблем, с которыми сталкиваются авторы библиотек и приложений при создании повторно используемых элементов кода, таких как классы или функции:

1. Коллизии имен между кодом, который они создают, и внутренним PHP или сторонними классами, функциями или константами
2. Возможность использовать псевдонимы (или сокращать) Extra_Long_Names предназначенные для устранения первой проблемы или улучшения читаемости исходного кода. Это мой любимый, так как я часто разрабатываю темы или плагины с большим количеством кода. Благодаря этому я могу легко читать код и управлять им, не беспокоясь о длинных уникальных именах.

Я бы порекомендовал хорошо разобраться в пространствах имен, прежде чем использовать их, поскольку их часто можно использовать неправильно.

В зависимости от проекта, который вы возьмете на вооружение, вполне вероятно, что вам придется придерживаться существующего стиля кодирования, если только ваша работа в основном не отличается от существующего. Если вам нужно расширить существующий плагин или тему, которая уже соответствует стандартам кодирования PHP для WordPress, лучше придерживаться их, чтобы иметь согласованный стиль, чтобы код стал чистым и легко читаемым. Обратите внимание, что некоторые правила применяются повсеместно для повышения производительности, независимо от стиля кодирования. Например, всегда лучше использовать одинарные кавычки (вместо двойных), если вы ничего не оцениваете в строке. Кроме того, код должен иметь отступ, чтобы его можно было прочитать, особенно если он имеет вложенный код (например, IF внутри IF , вложенные FOREACH и 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 с графическим интерфейсом, такое как SourceTree (один из моих любимых), будет просто способом взаимодействия с вашими репозиториями Git, делая весь кривая обучения более приятная. Как только вы поймете, как это работает, подумайте о том, чтобы ознакомиться с Git Best Practices and Tips by Toptal Developers, в которых более подробно объясняется несколько способов использования Git.

8. Постановка файлов CSS и JavaScript в очередь, когда они не нужны

Наличие большого количества HTTP-запросов замедлит загрузку веб-сайта, что приведет к более низкому баллу в Google PageSpeed, что, вероятно, повлияет на ранжирование в поиске. Это также может привести к ошибкам JavaScript из-за конфликтов между плагинами. Например, могут быть два плагина, использующие общую библиотеку jQuery, которая может загружаться дважды и вызывать проблемы. И действительно, это лучший пример, поскольку jQuery очень часто загружается на живые веб-сайты несколько раз. Вероятно, это происходит из-за плохо написанных плагинов или тем.

9. Использование файлов .php для вывода кода CSS или JavaScript вместо статических файлов .css и .js

Я видел темы и даже плагины WordPress, в которых были такие файлы, как style.php , которые использовались только для создания пользовательского кода CSS и его печати. Такие вещи, как цвета, размеры шрифта и расстояние между элементами, задавались в настройках темы, а затем сохранялись в базе данных. Затем читается style.php (например, <link rel='stylesheet' type='text/css' href='css/style.php?ver=1' /> ) и генерируется код 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, темами и другими плагинами, неэффективно создавать сложные классы, если вы не уверены, что плагин будет значительно расширяться позже. на.

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

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

Согласно Руководству по плагинам WordPress, хотя существует ряд возможных архитектурных шаблонов, их можно в целом сгруппировать в три варианта:

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

11. Не относиться серьезно к безопасности WordPress при написании кода

Безопасность часто не воспринимается всерьез при разработке WordPress, так как многие начинающие разработчики больше сосредотачиваются на результатах, которых хочет клиент. Все в порядке, пока веб-сайт клиента не будет взломан или ваш плагин, опубликованный на WordPress.org, не будет иметь уязвимости, в результате чего затронуты тысячи веб-сайтов. Такое иногда случается, и даже ядро ​​WordPress имело дело с большим количеством уязвимостей безопасности с первых дней существования CMS. Мы несем ответственность за то, чтобы сделать его максимально безопасным и, если что-то случится, действовать быстро и убедиться, что мы выпустили надежный, хорошо протестированный патч.

Некоторые из наиболее важных советов по безопасности:

Уязвимости XSS. Чтобы избежать этого, необходимо сделать две вещи: очистить ввод данных и очистить выходные данные. В зависимости от данных и контекста, в котором они используются, в WordPress существует несколько методов очистки кода. Не следует доверять ни входным данным, ни данным, которые будут напечатаны. Одной из распространенных функций очистки ввода данных является sanitize_text_field() . Он проверяет наличие недопустимых символов UTF-8, преобразует одиночные символы < в объекты HTML, удаляет все теги, удаляет разрывы строк, символы табуляции и лишние пробелы, а также удаляет октеты. Что касается вывода данных, хорошим примером вывода ссылок является esc_url() , которая отклоняет недопустимые URL-адреса, удаляет недопустимые символы и удаляет опасные символы.

Предотвратите прямой доступ к вашим файлам: к файлам можно получить прямой доступ, поскольку большинство хостов это разрешают. Однако, если это произойдет, и код не будет правильно написан для решения этой проблемы, могут быть напечатаны некоторые ошибки (например, отсутствующие функции или переменные, которые не объявлены), которые могут содержать информацию, ценную для потенциальных злоумышленников. Один общий фрагмент кода, который вы часто видите в плагинах и темах:

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

Если константа ABSPATH не определена (что должно быть для любой установки WordPress), то скрипт завершится и ничего не напечатает.

Используйте одноразовые номера: как указано в документации WordPress, одноразовый номер — это «число, используемое один раз», чтобы помочь защитить URL-адреса и формы от определенных типов неправомерного использования, злонамеренного или иного.

Например, следующий URL-адрес на панели инструментов будет использоваться для удаления сообщения в корзину: http://example.com/wp-admin/post.php?post=123&action=trash — при доступе к этому URL-адресу WordPress проверит информацию о файлах cookie для аутентификации. и если у вас есть соответствующие права (например, вы администратор со всеми правами), этот пост будет удален.

Злоумышленник может заставить ваш браузер получить доступ к этому URL-адресу без вашего ведома, создав ссылку на сторонней странице, как в следующем примере: <img src="http://example.com/wp-admin/post.php?post=123&action=trash" /> При отправке этого запроса к WordPress браузер автоматически прикрепит ваш файл cookie для аутентификации, и WordPress будет считать запрос действительным.

Именно тогда на место вступает одноразовый номер, поскольку злоумышленник не сможет так легко получить значение одноразового номера (сгенерированное для администратора, который фактически вошел в WordPress). Новый URL-адрес запроса будет выглядеть так: http://example.com/wp-admin/post.php?post=123&action=trash&_wpnonce=b192fc4204 .

Без действительного одноразового номера WordPress отправит ответ 403 Forbidden в браузер с хорошо известным сообщением об ошибке: «Вы уверены, что хотите это сделать?»

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

Обратите внимание, что большое количество взломов совершается даже не одним человеком с намерением специально взломать ваш сайт. Часто существуют боты, которые автоматически сканируют веб-сайты WordPress на постоянной основе, и в момент обнаружения известной уязвимости она эксплуатируется, а сервер используется для рассылки спама, получения личной информации из базы данных, размещения скрытых ссылок на определенных страницах веб-сайта. приведет к всевозможным сомнительным веб-сайтам (например, с порнографией, незаконными наркотиками). Иногда взломы настолько хорошо скрыты, что вам нужно тщательно отсканировать ваш веб-сайт и увидеть дату обновления определенных файлов, чтобы обнаружить взломанный код. Вот почему хорошо даже переустановить WordPress (да, ту же версию, если у вас последняя), чтобы любые взломанные файлы были перезаписаны подлинными файлами ядра WordPress.

12. Использование функций WordPress и фрагментов кода без их понимания

Часто, когда разработчики застревают и находят решение в таких местах, как StackOverflow, они просто довольны тем фактом, что им удалось заставить что-то работать, не утруждая себя пониманием логики этого кода или того, можно ли изменить этот код, чтобы он загружался быстрее или меньше. строки кода.

Я видел эту практику много раз, когда фрагменты кода копируются в PHP-скрипты, когда на самом деле используется только треть этого кода.

Это может иметь несколько недостатков, в том числе:

1. Код не использует тот же стиль, что и существующий код проекта. Да, удобно просто копировать и вставлять сниппеты, которые работают из коробки, и, хотя они подходят для небольшого личного проекта (он может когда-нибудь превратиться в большой проект, кто знает), эта практика часто не годится, когда дело доходит до для коммерческой работы, где необходимо соблюдать последовательность стиля.
2. Хотя код выполняет свою работу, он может содержать неэффективные функции, которые не рекомендуются для выполнения поставленной задачи. Если код не оптимизирован, эта практика «копировать и вставить» может привести к медленному и сложному обслуживанию веб-сайта, особенно если в разных местах проекта используется более одного фрагмента.
3. Код не может быть лицензирован для повторного использования, и включение кода в проект клиента может привести к большим юридическим проблемам.

Постоянное улучшение

Все совершают ошибки, и каждая ошибка — это возможность улучшить себя. Как разработчики WordPress, наша индустрия движется очень быстро, и никогда не существует одного «правильного способа» делать что-то. Однако чем больше вы практикуетесь и учитесь, тем лучше вы становитесь.

Вы не согласны с какой-либо из ошибок, которые я указал, или думаете, что я пропустил одну? Дайте мне знать в комментариях, и мы обсудим.