Обзор WordPress с точки зрения разработчика — лучшие практики разработки

Когда мы решили сменить среду разработки с CodeIgniter и Symfony на WordPress, то в первую очередь провели для себя ревью кода, среды разработки и начали искать лучшие практики для разработки.

Основные наши выводы, которые мы взяли для себя в ходе детального анализа, оформлены в данной статье.

WordPress Debugging

Основные существующие проблемы с отладкой на WordPress:

Debugging переменных через var_dump()

Когда надо просто вывести содержимое переменной, можно использовать var_dump() внутри тега <pre>:

Однако это очень не удобно, потому что часть данных не видно за версткой, и нереально отлаживать большие массивы данных, например:

Логирование через WP_DEBUG_LOG

Также можно включить логирование, определив константу WP_DEBUG_LOG в файле wp-config.php

и записывать данные в лог, используя error_log(). И хотя это удобно для логирования ajax запросов, проблема в том, что тяжело читать большие объемы данных и размер лог-файла быстро растет.

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

Также можно использовать xdebug, но это не всегда удобно, так как он слишком громоздкий для проверки значения одной переменной.

Наше решение проблемы

Мы решили создать свой отдельный плагин для облегчения разработки на WordPress: Premmerce Dev Tools!

Данную проблему решили, подключив symfony/var-dumper в Premmerce Dev Tools , это дало возможность быстро отлаживать массивы и объекты.

dump($var); — вывести значение;
dd($var);  — вывести значение и закончить работу скрипта;

Для легкой проверки быстродействия подключили symfony/stopwatch плагин Premmerce Dev Tools, что позволяет отслеживать время выполнения и использование памяти для отдельных частей кода.

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

Работа с тестовыми данными

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

Написали свой генератор в плагине Premmerce Dev Tools, использовали fzaninotto/faker для генерации данных и расширения bruceheller/images-generator для генерации изображений.

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

Структура плагина и стандарты написания кода WordPress

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

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

При написании наших плагинов, мы используем следующие стандарты:

• Basic Coding Standard PSR-1
• Coding Style Guide PSR-2
• Autoloader PSR-4

Для проверки соблюдения стандартов в наших плагинах, используем PHP Coding Standards Fixer и SensioLabs Insight для анализа кода.

Недостатки использования глобальных переменных

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

Но очень много размещенных плагинов также используют глобальные изменения для своей логики, что вызывает следующие проблемы:

1. Уменьшается читабельность кода — он становится трудным для понимания.
2. Увеличивается связанность кода.
3. Код с глобальными переменными трудно поддерживать, так как при изменении значения глобальной переменной нужно проверить все места ее использования.
4. Трудно отлаживать, так как нет механизма контроля доступа и невозможно отследить изменения в значении переменной в течение работы кода.
5. Существует вероятность переопределения переменной в другом плагине, библиотеке. Чтобы этого избежать, нужно добавлять префиксы, что уменьшает читабельность кода.

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

Для загрузки классов мы написали автолоадер для плагина и оставили возможность быстро переключить на composer autoloader на случай, когда в плагине будут использоваться библиотеки, подключенные через composer.

Также мы написали генератор плагина, который создает исходные файлы плагина, на основе составленного нами boilerplate. Вы можете его найти в нашем Premmerce Dev Tools.

Чистка базы данных

Часто плагины оставляют за собой данные и связи в базе не используются.

Мы написали скрипты, которые чистят базу, и также добавили к Premmerce Dev Tools.

Дальнейшая работа

Мы планируем работу над дополнительными инструментами и инструкциями для разработчиков на WordPress и WooCommerce. Основные наши инструменты мы будем выкладывать в нашем Premmerce Dev Tools, а также писать подробные обзоры и рекомендации в нашем блоге.

Читайте также: Complete WooCommerce Tutorial Step By Step.