Самые распространенные ошибки разработки темы WordPress (и как их исправить)

Опубликовано: 2019-05-14

Отправка темы в каталог тем WordPress.org — отличный способ поделиться своей работой и внести свой вклад в сообщество WordPress. На данный момент в каталоге более 7000 тем, самая популярная из которых превышает 300 000 активных установок. (Не включая темы Twenty____, которые входят в состав WordPress и имеют миллионы установок.)

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

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

https://make.wordpress.org/themes/handbook/review/required/

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

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

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

Загрузка вашей темы

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

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

Примечание. Авторы тем, у которых есть послужной список отправки беспроблемных тем, могут подать заявку, чтобы стать «доверенными авторами».

Проблемы с именами

Когда вы загружаете тему, первая выполняемая проверка заключается в том, чтобы убедиться, что имя уже занято. Часто вам сообщают, что выбранное вами имя уже занято, даже если вы не видите темы с таким именем в каталоге.

Как это могло быть? Причина в том, что тест проверяет не только каталог, но и всю экосистему WordPress. Если тема была выпущена где-либо (Github, ThemeForest и т. д.) и имеет более 50 активных установок, это имя будет недоступно для использования.

Примечание: если вы выпустили свою тему в другом месте и накопили более 50 установок, вы все равно можете использовать это имя в каталоге.

Неэкранированный вывод

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

Неэкранированный вывод подвергает риску пользователей вашей темы. Вот пример неэкранированного значения ($title):

 $title = get_option('my_custom_title');
эхо '<h2>' . $название . '</h2>';

Проблема с вышеизложенным заключается в том, что, хотя мы знаем, каким типом значения $title должно быть, строкой, мы не проверяли, так ли это.

Если хакеру удалось изменить значение my_custom_title в базе данных, ваша тема выведет это значение. Это представляет огромный риск, поскольку они могут заменить предполагаемый вывод встроенным Javascript:

 Сообщить('Это опасно');

Решение состоит в том, чтобы избежать всего вывода, чтобы гарантировать, что он включает только тот тип данных, который мы ожидаем.

Наш пример можно исправить так:

 $title = get_option('my_custom_title');
эхо '<h2>' . esc_html($название). '</h2>';

Недостатком использования esc_html является то, что он удаляет все теги HTML. Если $title выделен жирным шрифтом или курсивом, например:

 $title = 'Эта статья <strong>очень</strong> полезна';
эхо esc_html($название);

Слово «очень» не будет выделено жирным шрифтом во внешнем интерфейсе; вместо этого будет выводиться код <strong>very</strong>.

Это показывает, почему важно использовать правильные экранирующие функции для контекста. Если бы мы ожидали какой-то HTML в выводе, нам было бы лучше использовать wp_kses_post() или wp_kses() и установить параметр $allowed_html.

Функции, которые выводят, также должны быть экранированы:

 <a href="<?php echo esc_url(get_permalink()); ?>">

Исключением являются основные функции WordPress, в названии которых есть «the_», обычно они уже экранированы.

 функция the_permalink($post = 0) {
    /**
     * Фильтрует отображение постоянной ссылки для текущего поста.
     *
     * @с 1.5.0
     * @с версии 4.4.0 Добавлен параметр `$post`.
     *
     * @param string $permalink Постоянная ссылка на текущий пост.
     * @param int|WP_Post $post Идентификатор сообщения, объект WP_Post или 0. По умолчанию 0.
     */
    echo esc_url(apply_filters('the_permalink', get_permalink($post), $post));
}

Непереводимый текст

Чтобы быть принятыми в каталог, все темы должны быть на 100% готовы к переводу. Это означает, что каждая текстовая строка, которую выводит ваша тема, должна быть переводимой.

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

Несмотря на простоту реализации, это часто упускают из виду, поскольку это идет вразрез с тем, как люди пишут HTML.

Обычно вы можете сделать что-то вроде этого:

 <h1>404 — Не найдено</h1>

Чтобы сделать его переводимым, вам нужно добавить немного PHP:

 // __ функции — основа локализации.
<h1><?php echo __('404', 'текстовый домен'); ?>

// Функции _e повторяют значение.
<h1><?php _e('404', 'текстовый домен'); ?>

// Экранируем и повторяем строку.
<h1><?php esc_html_e('404', 'текстовый-домен'); ?>

// локализация и переменные.
<h1><?php _n('Один пост', '%s постов', $count, 'text-domain' ); ?>

Строки, выводимые функциями, также должны быть готовы к переводу:

 // не готов к переводу :-(
<?php next_posts_link('Старые записи'); ?>

// перевод готов :-)
<?php next_posts_link(esc_html__('Старые записи', 'текстовый-домен')); ?>

Совет. Во многих примерах кода на codex.wordpress.org не используются функции перевода, поэтому будьте осторожны при их копировании и вставке.

Неправильная постановка ресурсов в очередь

Файлы .css и .js, которые использует ваша тема, должны быть поставлены в очередь с использованием правильных функций: wp_enqueue_style() для CSS и wp_enqueue_script() для Javascript.

Распространенной ошибкой является жесткое кодирование скриптов и стилей непосредственно в <head> или перед </body>. У этого подхода есть две проблемы:

1. Невозможно удалить

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

 /**
 * Удалите из очереди javascript темы.
 *
 * Подключено к действию wp_enqueue_scripts с поздним приоритетом (100),
 * так, чтобы это было после того, как скрипт был поставлен в очередь.
 */
функция wptavern_dequeue_script() {
   wp_dequeue_script('тема-скрипты');
}
add_action('wp_enqueue_scripts', 'wptavern_dequeue_script', 100);

2. Двойная загрузка

Если вы ставите в очередь ресурс, например, jQuery, и плагин также ставит его в очередь, WordPress достаточно умен, чтобы загрузить его только один раз.

 /**
 * Поставить в очередь jQuery
 *
 * jQuery будет загружен только один раз, несмотря на две очереди.
 * jQuery входит в состав WordPress, поэтому нам не нужно указывать src. 
 */
функция wptavern_enqueue_script() {
   wp_enqueue_script('jquery');
   wp_enqueue_script('jquery');
}
add_action('wp_enqueue_scripts', 'wptavern_enqueue_script');

Если бы вместо этого вы жестко запрограммировали jQuery в свой <head>, тогда WordPress не мог бы узнать об этом, и он был бы загружен дважды.

Функциональность плагинов

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

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

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

Некоторые примеры функциональности плагин-территории:

Аналитика/Отслеживание
SEO-контроль
Контактные формы
Шорткоды
Блоки Гутенберга

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

Без префикса

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

Джастин Тэдлок поделился списком общих вещей, которые должны иметь префикс:

Имена функций PHP.
Имена классов PHP.
Глобальные переменные PHP.
Хуки действий/фильтров.
Ручки скрипта.
Стильные ручки.
Названия размеров изображений.

Источник: https://themereview.co/prefix-all-the-things/

 // пример функции.
мой_префикс_пример();

// пример класса.
класс My_Prefix_Example { … }

// пример действия и фильтра.
do_action('my_prefix_action');
apply_filters('my_prefix_filter', $значения);

// поставить в очередь примеры.
wp_enqueue_script('my_prefix_script', get_template_directory_uri(). '/js/custom-script.js');
wp_enqueue_style('my_prefix_style', get_template_directory_uri(). '/css/styles.css');

// пример размера изображения.
add_image_size('my_prefix_image_size', 220, 180); // 220 пикселей в ширину и 180 пикселей в высоту.

Исключение: при постановке в очередь сторонних ресурсов не добавляйте префикс:

 // постановка в очередь стороннего скрипта (chosen.js).
 wp_enqueue_script('выбранный', get_template_directory_uri(). '/js/chosen.js');

Проблемы с лицензированием

Ваша тема и все ее файлы должны быть на 100% совместимы с GPL. Сюда входят изображения, библиотеки, скрипты и шрифты.

Все сторонние ресурсы должны указывать информацию об источнике и лицензии.

Это требование может быть особенно сложным, поскольку не все лицензии совместимы с GPL. Лицензия Unsplash имеет только одно ограничение:

«Эта лицензия не включает право компилировать фотографии из Unsplash для воспроизведения аналогичного или конкурирующего сервиса».

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

Список лицензий, совместимых с GPL, доступен здесь — https://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses.

В последнее время, stocksnap.io был наиболее распространенным источником изображений в каталоге, поскольку все изображения, которые они перечисляют, имеют лицензию CC0 (совместимую с GPL).

Ошибки скриншота

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

Изображения также должны соответствовать тем же требованиям лицензирования, которые мы рассмотрели выше.

Бонус: используйте стандарт кодирования

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

Хотя требований к стандартам кодирования нет, следование одному из них упрощает чтение, понимание и поддержку вашего кода. Я лично использую и рекомендую «Стандарты кодирования WordPress», хотя есть и другие.

Использование PHP_CodeSniffer и набора правил WordPress в редакторе кода может значительно упростить соблюдение стандарта — https://github.com/WordPress-Coding-Standards/WordPress-Coding-Standards.

Вывод

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