12 худших ошибок при разработке в WordPress

Опубликовано: 01.09.2018

WordPress очень популярен из-за легкости запуска сайта на нем. Однако в спешке, многие разработчики допускают ужаснейшие ошибки.

БАГИ, ИЗМЕНИВШИЕ ИГРЫ

Некоторые ошибки, такие как оставить WP_DEBUG в true. Другие, такие как собрать все JavaScript в одно файле, также распространены, как и ленивые программисты.

Давайте познакомимся с 12-ю самыми распространенными ошибками при разработке в WordPress, которые делают новички и опытные разработчики.

Если вы обнаружите, что совершаете одну из этих ошибок, не отчаивайтесь. Каждая ошибка — это возможность учиться.

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

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

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

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

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

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

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

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

В зависимости от проекта, вполне вероятно, что вам придется придерживаться существующего стиля кодирования. В случае, если вы дорабатываете существующий плагин или тему код которых уже соответствует стандартам кодирования PHP для WordPress , то лучше продолжать придерживаться этого стиля, чтобы код был легко читаемым. Обратите внимание, что некоторые правила универсальны для повышения производительности, не считая стиля кодирования. Например, всегда лучше использовать одинарные кавычки (вместо двойных). Также в коде должны присутствовать отступы, если есть такие блоки как IF, FOREACH, FOR.

3. Не полное использование существующего функционала WordPress

Поскольку WordPress поставляется с набором регулярно обновляемых библиотек, которые можно просто вызвать в наших плагинах и темах, лучше всего использовать как можно больше существующих функциональных возможностей ядра. Я видел темы и плагины WordPress с файлами в их каталоге ресурсов, которые поставляются с WordPress из коробки(например, jQuery или Color Picker). Помимо того, что пакет библиотек станет больше и займет больше времени для загрузки, вы также должны регулярно обновлять все сторонние библиотеки для вашей темы или плагина.

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

4. Создание плагина или темы без использования Actions и Filters

Редактирование плагина или темы WordPress напрямую — плохая идея, если, конечно, вы не участвуете в разработке этого пакета и не вносите свой вклад в его код. Если для плагина или темы выполняется автоматическое обновление, любые прямые изменения в пакете будут потеряны, и вам придется редактировать файлы снова и снова.

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

5. Разработка с WP_DEBUG false

По умолчанию константа WP_DEBUG имеет значение ‘false‘ для подавления вывода любых PHP errors, warnings, notices. В Product версии это необходимо, чтобы скрыть огрехи, недочеты разработчика. Но в режиме разработки эту константу необходимо включить в ‘true‘, чтобы отлавливать все предупреждения и ошибки в вашем коде. Это также гарантирует, что плагин или тема, которую вы разрабатываете, не сгенерируют ошибок PHP в любой версии WordPress.

Хотя это делают большинство опытных разработчиков, тем не менее, эта ошибка происходит, особенно в спешке. Независимо от срочности работы разработчики всегда должны стараться поддерживать стандарты кодирования WordPress.

6. Написание PHP-кода без учета того, что страница может быть кэширована на один день

Это распространенная ошибка PHP и, как и предыдущая, которую довольно легко предотвратить, если вы придерживаетесь стандартов кодирования PHP. У некоторых разработчиков есть привычка внедрять PHP-фрагменты в темы и плагины, которые актуальны только в том случае, если код PHP запускается все время. Например, следует использовать функцию PHP, которая реагирует на HTTP-агент(браузер) с определенными действиями (например, enqueuing скрипты, предназначенные только для мобильных пользователей).

Если ваш клиент установит плагин, который кэширует страницу (например, W3 Total Cache или WP Rocket) без запуска соответствующих условий в вашей теме или плагинах, ваш PHP-код будет бесполезен(неактуален).

Если цель состоит в том, чтобы сделать страницы responsive, то это должно быть сделано на стороне клиента(браузера) через медиа-запросы и JavaScript. В идеале лучше избежать использования JavaScript, чтобы сделать ваш сайт responsive.

7. Пренебрежение к использованию системы контроля версий, такую как Git

Файлы, с кастомным кодом, например дочерняя тема или пользовательский плагин, в идеале должны находиться под контролем версий. Git создает запись о том, что было изменено, и позволяет разработчикам работать вместе в одном проекте WordPress или легко вернуться к предыдущей версии, когда что-то пойдет не так с веб-сайтом. Кроме того, клиенты могут использовать Git для отслеживания всей истории работы, которая была сделана всеми разработчиками, которые были наняты для этого конкретного проекта, особенно если это был большой, долгосрочный проект веб-сайта WordPress.

Хотя это может быть пугающим в начале, особенно для Junior разработчиков, понимание Git будет стоить потраченного времени, а программное обеспечение Git GUI, такое как SourceTree, будет просто инструментом взаимодействия с вашими хранилищами Git.

8. Запуск файлов CSS и JavaScript, когда они не нужны

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

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

Я видел темы и даже плагины WordPress, в которых были такие файлы, как style.php, которые использовались только для создания собственного CSS-кода и его вывода.

Это действительно плохая практика с точки зрения производительности WordPress. Вот основные недостатки применения такого способа:

Поскольку файл CSS загружается в тег head (что является нормальным), есть проблема с производительностью, которая приходит с тем, что браузер должен полностью загрузить файл перед отображением страницы. Если среда WordPress замедленна из-за некоторых плагинов, это значительно замедлит время загрузки. Даже если используются методы кэширования или загружается только часть среды WordPress для извлечения значений из базы данных. Лучше всего использовать статический файл .css. В PHP-файле код (правила CSS, смешанные с переменными PHP и условными предложениями) будет сложнее читать разработчиками, когда им нужно что-то проверить. Конечно, файл можно запустить в браузере (хотя я уверен, что когда он будет выведен, в нем не будет отступов, что будет выглядеть безобразно).

Решение: Сохраните любой кастомный файл CSS или JS вне каталога темы или плагина.

Пример: /wp-content/uploads/theme-name-custom-css/style-5.css.

Таким образом, во время обновления он не удалиться.

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

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

Если вам нужен единично кастомный плагин для WordPress для клиента, и он имеет ограниченное взаимодействие с ядром WordPress, темами и другими плагинами, то неэффективно создавать сложные классы, если вы не уверены, что плагин будет расширяться в будущем.

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

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

11. Не уделяя безопасности должного внимания при написании кода.

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

Немного важных советов по безопасности:

Уязвимости XSS

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

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

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

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

Использование Nonces

Nonce расшифровывается как «число, используемое один раз» ( number used once ). Эти числа или «токены» состоят из цифр и букв, являются уникальными для каждого пользователя и для каждого действия, и имеют ограниченное «время жизни», после которого становятся недействительными.

Несмотря на говорящую фразу «число, используемое один раз», в действительности это не совсем так. Nonce генерируется для конкретного пользователя и действия, поэтому будет неизменной до тех пор, пока жизненный цикл не будет закончен (примеры генерации и описание жизненного цикла будут рассмотрены ниже).

Одноразовыми же они называются, потому что предназначены для тех же целей, что и настоящие одноразовые токены. Например, nonce помогают защититься от некоторых типов атак, включая межсайтовую подделку запросов (CSRF), но не защищают от атак повторного воспроизведения (replay atack), потому что nonce не проверяются на использование лишь единожды.

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

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

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

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

Это может повлечь за собой неприятные последствия:

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

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

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

Однако чем больше вы тренируетесь и учитесь, тем лучше вы станете.

Оригинал статьи The 12 Worst Mistakes Advanced WordPress Developers Make