Статьи

Распространенные ошибки разработки WordPress и как их исправить

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

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


Если вы выполните поиск в Google по запросу «WordPress», он вернет 1,9 миллиарда результатов. Существуют миллионы сайтов с примерами кода, учебными пособиями и фрагментами, которые очень полезны в качестве разработчика WordPress. Беда в 2 раза:

  1. Люди не следуют стандартам кодирования WordPress
  2. Люди просто копируют и вставляют

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

Давайте начнем с того, как вы можете избежать некоторых распространенных ошибок!


Сами WordPress признают, что некоторые части структуры кода WordPress для разметки PHP несовместимы по своему стилю (точные слова). Они работают над тем, чтобы очистить код и сделать его согласованным, и установили стандарт для ВСЕГО кода WordPress. Неважно, плагин это или тема, все они должны следовать одним и тем же стандартам.

Стандарты кодирования WordPress

Если вы никогда не читали эту страницу, прежде чем читать ее ! Это должно быть одним из первых мест, где любой разработчик работает с посещениями WordPress. Я не собираюсь подробно останавливаться на этом, но вы должны уделить время и прочитать его.

Я сам виновен в нарушении пары этих правил, но реальный ключ — последовательность. Одно правило, которое я нарушаю, я нарушаю все время. Лично при работе с операторами if я предпочитаю использовать альтернативный синтаксис для структур управления . Для меня их легче читать. Будучи последовательными в моем коде, по крайней мере, люди могут сразу увидеть, что я делаю что-то другое, и следовать за мной через мой код.

Помните: стандарты согласованности и кодирования действительно способствуют тому, чтобы ваш код выглядел и читался лучше!


В предыдущем разделе мы рассмотрели стандарты кодирования WordPress, этот документ находится в единственном наиболее полезном ресурсе разработки для разработчиков WordPress. Кодекс WordPress. Кодекс, доступный почти на 50 языках, является библией разработчиков. Он содержит документацию почти по каждой функции, классу и переменной в WordPress, как их использовать и примеры кода. У меня обычно есть 3 или 4 вкладки, открытые в кодексе в любое время, фактически у меня есть 4 открытых! Неважно, если вы новичок в WordPress или работали с ним годами, документация здесь неоценима.

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

Мой самый большой совет для Кодекса — искать! Как и на любом вики-сайте, навигация немного сложна и поначалу не обязательно имеет смысл. Встроенный поиск должен помочь вам найти то, что вы ищете. Если вы изо всех сил пытаетесь найти то, что ищете, а затем переходите на IRC-канал #WordPress , обычно там есть несколько человек, которые укажут вам на нужную страницу Кодекса.


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

1
2
3
4
5
6
<head>
    <link rel=’stylesheet’ href=’style.css’ type=’text/css’ media=’screen’ />
    <script type=’text/javascript’ src=’js/mysite.js’></script>
 
    <title>Hello</title>
</head>

Вышеприведенный фрагмент — это типичные первые несколько строк большинства тем WordPress, однако это не должно быть. Сценарии и стили могут быть намного лучше обработаны с помощью WordPress, и они дают нам несколько замечательных функций для работы с ними. Сейчас я говорю о темах, но любой плагин, которому нужны скрипты или стили, должен делать вещи точно так же. Представляем wp_enqueue_style() и wp_enqueue_script() ! Если вы не знаете, что делают эти функции, мы должны это исправить! Давайте пройдемся по тому, что вам нужно сделать.

Независимо от того, является ли это сценарием или стилем, лучше всего сообщить WordPress об этом. Мы делаем это с помощью wp_register_script() или wp_register_style() . Это оба безопасные способы регистрации скрипта или стиля в WordPress, чтобы вы могли использовать их позже. Теперь эта функция ничего не выводит на вашу тему или сайт, она просто готовит WordPress для их использования.

1
2
3
4
5
<?php
wp_register_script( $handle, $src, $deps, $ver, $in_footer );
 
wp_register_style( $handle, $src, $deps, $ver, $media );
?>

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

$src (обязательно) Это URL-адрес таблицы стилей или сценария. Он может быть внешним или внутренним для вашего сайта, в зависимости от того, что вы делаете. Внешний полезен, если вы используете стороннюю службу шрифтов, такую ​​как Type Kit или Google Fonts или для Javascript в социальных сетях. Вы никогда не должны жестко задавать URL для локальных таблиц стилей или скриптов, для этого есть подходящие функции, о которых мы поговорим позже.

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

$ver (Необязательно) Здесь вы можете указать номер версии скрипта или стиля, если он есть. Это полезно, чтобы гарантировать, что правильная версия отправляется в браузер пользователя независимо от кэширования. Конечно, вы можете установить свои собственные номера версий для своих собственных сценариев и стилей, или вы можете использовать небольшую хитрость для получения динамических номеров версий.

$in_footer (Необязательно, только для сценариев ) Обычно сценарии помещаются в <head> однако, если для этого параметра установлено значение true, сценарий будет размещаться в нижней части <body> . Если вы хотите выводить в нижний колонтитул, вам нужно убедиться, что ваша тема имеет wp_footer() в нужном месте.

$media (Необязательно, только стиль). Это может быть строка для указания носителя, для которого определена таблица стилей. (Например, 'all' , 'screen' , 'handheld' , 'print' ).

Давайте соберем все это в хороший пример:

1
2
3
4
5
6
7
8
9
<?php
function tuts_register_stuff() {
    wp_register_script( ‘my-script’, get_template_directory_uri() . ‘/js/my-script.js’, array( ‘jquery’ ), 1.0, true );
 
    wp_register_style( ‘my-style’, get_template_directory_uri() . ‘/style.css’, array(), 1.0, ‘screen’ );
}
 
add_action( ‘wp_enqueue_scripts’, ‘tuts_register_stuff’ );
?>

Вкратце, у нас есть JavaScript, который мы вызываем из папки темы, он зависит от jQuery, установленного на версию 1, и мы хотим вывести его в конце нашей страницы. Также у нас есть файл style.css, который мы вызываем из папки темы, он не имеет зависимостей, имеет версию 1.0 и предназначен для экрана. Также важно помнить, что нам нужно на самом деле выполнить эти сценарии с помощью ловушки действий. В этом случае мы используем wp_enqueue_scripts качестве нашей ловушки действий, как рекомендовано Кодексом.

Это все очень легко, когда вы овладеете этим и привыкнете делать это!

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

1
2
3
4
5
6
7
8
<?php
function tuts_enqueue_stuff() {
    wp_enqueue_script( ‘my-script’ );
    wp_enqueue_style( ‘my-style’ );
}
 
add_action( ‘wp_enqueue_scripts’, ‘tuts_enqueue_stuff’ );
?>

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

01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
<?php
function tuts_scripts_and_styles() {
    wp_register_script( ‘global’, get_template_directory_uri() . ‘/js/global.js’, array( ‘jquery’ ), 1.0, true );
    wp_register_script( ‘home-page’, get_template_directory_uri() . ‘/js/home-page.js’, array( ‘jquery’ ), 1.0, true );
 
    wp_register_style( ‘global’, get_template_directory_uri() . ‘/style.css’, null, 1.0, ‘screen’ );
    wp_register_style( ‘sliders’, get_template_directory_uri() . ‘/css/sliders.css’, null, 1.0, ‘screen’ );
 
    if ( is_home() ) {
        wp_enqueue_script( ‘home-page’ );
        wp_enqueue_style( ‘sliders’ );
    }
 
    wp_enqueue_script( ‘global’ );
    wp_enqueue_style( ‘global’ );
}
 
add_action( ‘wp_enqueue_scripts’, ‘tuts_scripts_and_styles’ );
?>

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

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

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


1
<script src=»//ajax.googleapis.com/ajax/libs/jquery/1.8.2/jquery.min.js»></script>

Если вы когда-либо помещали это в свою тему, плагин или что-то связанное с WordPress, вы просто убили котенка. Мы уже обсуждали важность регистрации и постановки в очередь ваших сценариев и стилей, так почему бы отменить всю вашу тяжелую работу. WordPress поставляется с множеством сценариев, которые вы можете использовать, просто ставя их в очередь. Конечно, вы можете, даже если все делаете правильно, вы можете отменить регистрацию связанной версии скрипта и зарегистрировать свою собственную версию. Как и выше, возможно, мы хотим использовать версию Google CDN. Это хорошо, если вы работаете над собственным сайтом, собственной темой или плагином и не собираетесь его выпускать. Однако, если вы публикуете свой код, придерживайтесь включенных библиотек . Другие плагины могут сломаться, темы могут перестать работать, потому что никто не следует правилам. Я часто нахожу сайты с 3 или 4 различными версиями jQuery, загруженными просто потому, что люди не регистрируются и не ставят в очередь правильно, или какой-то автор плагина хочет использовать другую версию чего-либо.

Давайте сделаем друг другу одолжение и будем следовать некоторым стандартам!

Предупреждение: плагины или темы, которые используют не входящую в комплект библиотеку, будут отклонены, если они будут отправлены как в ThemeForest, так и в репозиторий WordPress.org!

Теперь также важно кратко рассказать о jQuery. Он массивный, его используют все, темы любят, плагины любят. Однако это может вызвать проблемы, если он не используется правильно. Библиотека jQuery в комплекте с WordPress загружается в режиме «без конфликтов» . Это позволяет ему работать вместе с другими библиотеками, которые может использовать WordPress. Однако в бесконфликтном режиме ярлык $ не работает и был заменен на более длинный jQuery .

1
2
3
$(document).ready(function() {
    $(#myfuntion) …
});

Вышесказанное необходимо переписать для работы, самый простой способ — использовать следующую обертку:

1
2
3
jQuery(document).ready(function($) {
    $(#myfunction) //Now $() works as an alias for jQuery() inside this function!
});

Проблема с загрузкой внешней версии jQuery заключается в том, что она может не загружаться в бесконфликтном режиме, она может сломать другие сценарии, и автор может написать JavaScript, не следуя приведенным выше правилам. Это означает, что все ломается, когда вы пытаетесь использовать прилагаемую версию jQuery! Всегда старайтесь использовать связанные библиотеки и всегда пишите свой JavaScript / jQuery в бесконфликтном режиме!

Вы можете получить больше информации о WordPress и jQuery на странице Кодекса.


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

  1. Получение местоположения темы: Если вы используете TEMPLATEPATH или bloginfo( 'template_directory' ) . Стоп! Вы должны использовать очень полезную get_template_directory() как показано в моих примерах выше.

    На самом деле есть 4 варианта этой функции:

    1. get_template_directory() возвращает get_template_directory() к папке вашей темы. Полезно для использования внутри функций PHP или включает.
    2. get_template_directory_uri() возвращает URL-адрес вашей папки темы. Полезно для постановки в очередь и регистрации ваших сценариев и стилей, а также, если вы хотите включить и изображение.
    3. get_stylesheet_directory() возвращает PATH в папку таблиц стилей. Это всегда будет указывать на get_template_directory() тему, если она используется, тогда как get_template_directory() всегда будет указывать на родительскую тему.
    4. get_stylesheet_directory_uri() возвращает URL-адрес папки стилей. Как и в случае выше, это всегда будет указывать на тему ребенка, если он используется.

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

  2. Получение местоположения плагина: С плагинами есть 2 различные функции для использования:
    1. plugin_dir_url() возвращает URL переданного файла плагина.
    2. plugin_dir_path() возвращает путь к каталогу переданного файла плагина.

    С плагинами мне всегда легче определить константу в самом начале и использовать ее в моем плагине.

    01
    02
    03
    04
    05
    06
    07
    08
    09
    10
    11
    <?php
     
    if ( ! defined( ‘MY_PlUGIN_URL’ ) )
        define( ‘MY_PLUGIN_URL’, plugin_dir_url( __FILE__ ) );
     
    if ( ! defined( ‘MY_PLUGIN_PATH’ ) )
        define( ‘MY_PLUGIN_PATH’, plugin_dir_path( __FILE__ ) );
     
    require_once( MY_PLUGIN_PATH . ‘/my-file.php’ );
     
    ?>
  3. Получение URL вашего сайта: Это довольно распространенное требование, может быть, вы хотите просто добавить ссылку на свою домашнюю страницу? Как получить каталог темы прекратить использование bloginfo() . Пример ниже дает очень простой пример того, как сделать это правильно.
    1
    <a href=»<?php echo home_url( ‘/’ ); ?>»>This is a link to our home page</a>

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


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

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


Это еще один момент, который я хотел бы затронуть очень кратко, поскольку я знаю, что есть несколько хороших руководств по действиям и фильтрам (один из них связан для вас внизу). Независимо от того, какую разработку WordPress вы делаете, узнайте о действиях и фильтрах. Это одна из самых больших ошибок, которые я вижу, люди делают. WordPress имеет отличный API для разработки тем и плагинов, и вы можете сделать свою разработку намного лучше, используя инструменты, которые WordPress предлагает для вас. Лучшие плагины широко используют Действия и Фильтры, так что если вы хотите настроить, как это работает для вас, это просто.

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

Действия и фильтры — это одна из самых важных вещей, которые вы должны узнать о разработке WordPress, потратить некоторое время, и вы попадете туда!


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

  1. Следуйте стандартам кодирования WordPress
  2. Будьте согласны с вашим кодом
  3. Используйте документацию! Кодекс — это ваша Библия
  4. Используйте функции, которые есть по правильным причинам
  5. Подумайте, куда вы положили свой код
  6. Используйте действия и фильтры

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