10 самых распространенных ошибок, которые допускают разработчики WordPress

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

Распространенная ошибка № 1: Отключение отладки

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

Чтобы включить эту функцию, вам нужно отредактировать файл wp-config.php в корневом каталоге вашей установки WordPress. Вот фрагмент типичного файла:

 // Enable debugging define('WP_DEBUG', true); // Log all errors to a text file located at /wp-content/debug.log define('WP_DEBUG_LOG', true); // Don't display error messages write them to the log file /wp-content/debug.log define('WP_DEBUG_DISPLAY', false); // Ensure all PHP errors are written to the log file and not displayed on screen @ini_set('display_errors', 0);

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

Распространенная ошибка №2: добавление скриптов и стилей с помощью wp_head

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

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

 wp_register_script( $handle, $src, $deps = array(), $ver = false, $in_footer = false ) wp_enqueue_script( $handle, $src = false, $deps = array(), $ver = false, $in_footer = false ) wp_register_style( $handle, $src, $deps = array(), $ver = false, $media = 'all' ) wp_enqueue_style( $handle, $src = false, $deps = array(), $ver = false, $media = 'all' )

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

Распространенная ошибка № 3: избегание дочерних тем и изменение основных файлов WordPress

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

Чтобы создать дочернюю тему, поместите файл style.css в подкаталог папки дочерней темы со следующим содержимым:

 /* Theme Name: Twenty Sixteen Child Theme URI: http://example.com/twenty-fifteen-child/ Description: Twenty Fifteen Child Theme Author: John Doe Author URI: http://example.com Template: twentysixteen Version: 1.0.0 License: GNU General Public License v2 or later License URI: http://www.gnu.org/licenses/gpl-2.0.html Tags: light, dark, two-columns, right-sidebar, responsive-layout, accessibility-ready Text Domain: twenty-sixteen-child */

В приведенном выше примере создается дочерняя тема на основе темы WordPress по умолчанию Twenty Sixteen . Самая важная строка этого кода содержит слово «Шаблон», которое должно соответствовать имени каталога родительской темы, из которой вы клонируете дочернюю тему.

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

Распространенная ошибка № 4: жесткое кодирование значений

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

 // Get child theme directory uri stylesheet_directory_uri(); // Get parent theme directory get_template_directory_uri(); // Retrieves url for the current site site_url();

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

 global $wpdb; $user_count = $wpdb->get_var( "SELECT COUNT(*) FROM $wpdb->users" );

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

Распространенная ошибка № 5: не остановить индексацию вашего сайта

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

Как показано ниже, в настройках чтения WordPress есть флажок «Запретить поисковым системам индексировать этот сайт», хотя под ним есть важное замечание, в котором говорится, что «Поисковые системы должны выполнить этот запрос».

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

 Header set X-Robots-Tag "noindex, nofollow"

Распространенная ошибка № 6: не проверять, активен ли плагин

Зачем мне проверять, существует ли функция плагина, если мой плагин всегда включен? Наверняка 99% времени ваш плагин будет активен. Однако как насчет того 1% времени, когда по какой-то причине он был деактивирован? Если и когда это произойдет, ваш веб-сайт, вероятно, будет отображать некоторые уродливые ошибки PHP. Чтобы предотвратить это, мы можем проверить, активен ли плагин, прежде чем вызывать его функции. Если функция плагина вызывается через внешний интерфейс, нам нужно включить библиотеку plugin.php , чтобы вызвать функцию is_plugin_active() :

 include_once( ABSPATH . 'wp-admin/includes/plugin.php' ); if ( is_plugin_active( 'plugin-folder/plugin-main-file.php' ) ) { // Run plugin code }

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

 if( class_exists( 'WooCommerce' ) ) { // The plugin WooCommerce is turned on }

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

Распространенная ошибка № 7: загрузка слишком большого количества ресурсов

Почему мы должны избирательно подходить к загрузке ресурсов плагинов для страниц? Нет веской причины загружать стили и скрипты для подключаемого модуля, если этот подключаемый модуль не используется на странице, на которую перешел пользователь. Загружая файлы плагинов только при необходимости, мы можем сократить время загрузки нашей страницы, что приведет к улучшению взаимодействия с конечным пользователем. Возьмем, к примеру, сайт WooCommerce, где мы хотим, чтобы плагин загружался только на наши страницы покупок. В таком случае мы можем выборочно удалить любые файлы из загрузки на всех страницах других сайтов, чтобы уменьшить раздувание. Мы можем добавить следующий код в файл functions.php темы или плагина:

 function load_woo_scripts_styles(){ if( function_exists( 'is_woocommerce' ) ){ // Only load styles/scripts on Woocommerce pages if(! is_woocommerce() && ! is_cart() && ! is_checkout() ) { // Dequeue scripts. wp_dequeue_script('woocommerce'); wp_dequeue_script('wc-add-to-cart'); wp_dequeue_script('wc-cart-fragments'); // Dequeue styles. wp_dequeue_style('woocommerce-general'); wp_dequeue_style('woocommerce-layout'); wp_dequeue_style('woocommerce-smallscreen'); } } } add_action( 'wp_enqueue_scripts', 'load_woo_scripts_styles');

Скрипты можно удалить с помощью функции wp_dequeue_script($handle) через дескриптор, с которым они были зарегистрированы. Точно так же wp_dequeue_style($handle) предотвратит загрузку таблиц стилей. Однако, если это слишком сложно для вас, вы можете установить Организатор плагинов, который предоставляет возможность выборочной загрузки плагинов на основе определенных критериев, таких как тип сообщения или имя страницы. Рекомендуется отключить все подключаемые модули кэширования, такие как W3Cache, которые вы, возможно, включили, чтобы вам не приходилось постоянно обновлять кеш для отражения любых сделанных вами изменений.

Распространенная ошибка № 8: сохранение панели администратора

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

 add_action('after_setup_theme', 'remove_admin_bar'); function remove_admin_bar() { if (!current_user_can('administrator') && !is_admin()) { show_admin_bar(false); } }

Приведенный выше код при копировании в файл functions.php вашей темы будет отображать панель администратора только для администраторов сайта. Вы можете добавить любые роли или возможности пользователей WordPress в функцию current_user_can($capability) , чтобы пользователи не могли видеть панель администратора.

Распространенная ошибка № 9: не использовать фильтр GetText

Я могу использовать CSS или JavaScript, чтобы изменить метку кнопки, что в этом не так? Ну да, можешь. Тем не менее, вы добавляете лишний код и дополнительное время для отображения кнопки, когда вместо этого вы можете использовать один из самых удобных фильтров в WordPress, который называется gettext . В сочетании с textdomain плагина, уникальным идентификатором, который гарантирует, что WordPress может различать все загруженные переводы, мы можем использовать фильтр gettext для изменения текста перед отображением страницы. Если вы ищете в исходном коде функцию load_plugin_textdomain($domain) , она даст вам доменное имя, которое нам нужно для переопределения рассматриваемого текста. Любой авторитетный плагин гарантирует, что textdomain для плагина установлен при инициализации плагина. Если вы хотите изменить текст в теме, найдите строку кода load_theme_textdomain($domain) . Используя WooCommerce еще раз в качестве примера, мы можем изменить текст, который появляется для заголовка «Сопутствующие товары». Вставьте следующий код в файл functions.php вашей темы:

 function translate_string( $translated_text, $untranslated_text, $domain ) { if ( $translated_text == 'Related Products') { $translated_text = __( 'Other Great Products', 'woocommerce' ); } return $translated_text; } add_filter( 'gettext', 'translate_string', 15, 3 );

Этот хук-фильтр применяется к переведенному тексту с помощью функций интернационализации __() и _e() , если textdomain установлен с помощью вышеупомянутых функций.

 _e( 'Related Products', 'woocommerce' );

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

Распространенная ошибка № 10: сохранение постоянных ссылок по умолчанию

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

Заключение

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