О типичных ошибках в разработке под WordPress и о том, как их исправить

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

Что не так с вашим кодом?

Вбейте в поиск Google запрос WordPress — и получите 1,9 млрд результатов. Это — миллионы сайтов с примерами кода, настольными руководствами и сниппетами, которые пригодятся любому WordPress-разработчику. Но есть 2 проблемы:

• Люди не придерживаются стандартов написания кода для WordPress
• Люди занимаются бездумным "копипейстом".

И по этим 2 причинам новичок в разработке под WordPress, проводящий поиск ответов на интересующие его / ее вопросы в Google, находит статью, копирует из нее код, вставляет в свою тему или сайт — и все работает! На радостях можно еще сделать закладку на данный сайт. Но проблема в том, что приведенный текст может быть далек от совершенства, но вы — новичок, и проблем в этом коде вы не заметите. Он просто работает, и вы его можете вечность использовать в неизменном виде.

Давайте разберем, как избежать такой ошибки.

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

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

• wordpress-стандарты для кодера

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

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

И помните: единство стиля и сохранение стандартов создания кода — один из длительных, но эффективных путей к созданию "чистого" и удобного в использовании кода для данной платформы!

Codex, Codex и еще раз Codex

Все стандарты и требования к коду собраны в удобном виде в формате единого ресурса для разработчиков под названием The WordPress Codex. Он доступен более чем на 50 языках, и его можно назвать своего рода "библией разработчика" для данной платформы. Здесь задокументированы возможности, описание и требования практически к каждой функции, классу, переменной в WordPress, пути их использования и практические примеры кода. При работе с новыми темами, постами, сайтами советуем держать открытыми хотя бы несколько вкладок со статьями из "Кодекса".

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

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

Выберите подходящие инструменты для работы

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

<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

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

<?php 
wp_register_script( $handle, $src, $deps, $ver, $in_footer );
 
wp_register_style( $handle, $src, $deps, $ver, $media );
?>

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

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

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

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

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

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

Сведем все перечисленные параметры в один практический пример:

<?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, что рекомендовано стандартами Codex.

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

Оставьте сложную работу для WordPress

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

<?php
function tuts_enqueue_stuff() {
    wp_enqueue_script( 'my-script' );
    wp_enqueue_style( 'my-style' );
}
 
add_action( 'wp_enqueue_scripts', 'tuts_enqueue_stuff' );
?>

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

<?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 в свою тему, заново зарегистрировать другой стиль оформления и использовать код на своем сайте!

Каждый раз, когда вы используете свою библиотеку JavaScript, в мире погибает 1 котенок

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

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

WordPress поставляется с тонной скриптов, использовать которые можно, просто создав целевые запросы к ним. Вы конечно можете снять регистрацию с поставляющегося "из коробки" скрипта и зарегистрировать собственный скрипт. Может, вам нужна для работы версия под Google CDN. Но если вы используете такое решение не для своего собственного сайта, а на стороннем сайте, то придерживайтесь тех библиотек, которые у вас уже есть в установленном движке. Сторонние плагины могут выйти из строя, работать некорректно, а темы могут "сломаться", если никто не будет соблюдать правил работы с кодом и его интеграции.

Не так давно мы обнаружили 3-4 разных версии jQuery на различных сайтах просто потому, что люди неправильно регистрируют и запрашивают плагины, создают авторские версии стандартных плагинов и т.д. Окажите услугу себе и другим: следуйте же определенным стандартам!

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

И кратко отметим пару важных моментов в отношении jQuery. Эти скрипты массово использует множество людей, многие темы и плагины построены на данном коде. НО проблема в том, что очень часто он используется некорректно. Библиотека jQuery поставляется в составе WordPress в режиме no conflict. Это позволяет данной библиотеке работать нормально параллельно с другими библиотеками при использовании их в WordPress. Но режим no-conflict не поддерживает работу ярлыков $, и потому его заменили несколько более длинным jQuery.

$(document).ready(function() {
    $(#myfuntion) ...
});

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

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

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

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

Разберитесь в путях и адресах

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

Адрес к местоположению темы

Если вы используете TEMPLATEPATH или bloginfo( 'template_directory'), то хватит уже это делать! Вам стоит использовать крайне полезный параметр get_template_directory(). Всего есть 4 варианта данной функции:

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

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

Местоположение плагинов

Здесь можно использовать 2 разных функции:

1. plugin_dir_url() — выдает URL самого плагина.
2. plugin_dir_path() — выдает путь к папке, содержащей плагин.

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

<?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' );
 
?>

Получение адреса вашего сайта

Вы хотите задать простую ссылку на вашу домашнюю страницу? Перестаньте для этой цели использовать bloginfo(). Ниже — пример того, как это сделать правильно:

<a href="<?php echo home_url( '/' ); ?>">This is a link to our home page</a>

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

Плагин или тема?

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

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

Фильтры кода для действий и готовые коды — почему вы до сих пор их не используете?

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

Пример — WooCommerce от WooThemes. Почти все в данной теме можно отключить или настроить под свои потребности, просто применив фильтры к действиям или отключив определенные действия. Их подход Action and Filter Reference довольно прогрессивен и позволяет вам делать с темой практически все, что угодно. Конечно, от вас не требуется собственные проекты делать такими же гибкими и прогрессивными в плане пользовательских сценариев и возможных действий по настройке темы сайта, но если ваш код можно легко кастомизировать без необходимости быть "блогохакером", то люди охотнее будут использовать вашу тему оформления и рекомендовать ее другим. Пользовательские сценарии действий и фильтры — одна из наиболее важных "штук", которым стоит поучиться в работе с WordPress, и затраченное время окупится — вот увидите!

Заключение

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

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

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

Источник: WP.tutsplus.com

Алексей Шевченко

редактор wpcafe

Изучает сайтостроение с 2008 года. Практикующий вебмастер, специализирующий на создание сайтов на WordPress. Задать вопрос Алексею можно на https://profiles.wordpress.org/wpthemeus/