Понятие пространства имен в системе хуков в WordPress


Содержание материала:

Хуки WordPress: примеры, как использовать

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

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

Концепция: что такое хуки WordPress и почему они используются?

За любым качественно написанным программным обеспечением кроется мощная концепция, которая отвечает на вопросы «что такое?» и «почему?». Хуки – не исключение. Говоря простыми словами, хук – это заполнитель для действия. Когда происходит определенное событие, такое как публикация записи, хук активируется, позволяя реализовать соответствующую реакцию. В терминах разработчиков хуки представляют собой пример системы, управляемой событиями.

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

Как применить хуки?

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

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

Работа с документацией

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

  • add_action( $hook, $function [, $priority [, $numArgs ] ] ) – задает обработчик функции $function, который вызывается в том случае, если определенный хук $hook активирован в результате возникновения события. $priority определяет, будет ли данный обработчик функции вызван до или после других обработчиков функций (по умолчанию переменная равна 10). Чем меньше этот показатель, тем раньше будет вызвана функция. $numArgs – количество аргументов, принимаемых обработчиком функции (по умолчанию 1).
  • do_action( $hook [, $arg1 [, $arg2 [, $arg3 [, … ] ] ] ] ) – активирует определенный хук $hook путем вызова всех обрабатываемых функций с необязательными аргументами $arg1, $arg2, $arg3 и т.д.

Теперь, когда у нас в одной руке находится документация, мы можем сделать некоторые выводы по поводу этих двух функций. add_action просто связывает функцию, приоритет и количество аргументов со строкой. Это напоминает идеальную задачу для PHP массивов, которые также работают как хэш-карты, хранящие пары ключ-значение. do_action более тривиальная функция – она обращается к этому массиву, разыскивает функциональные обработчики и вызывает их впоследствии. Держа в памяти нашу схему, самое время перейти к применению хуков.

Применяем полученные знания на практике

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

Перед тем как начать, давайте создадим план действий:

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

Код будет выглядеть следующим образом:

Отлично; мы создали универсальную систему хуков с помощью примерно 20 строк кода. Теперь, когда у нас есть идея того, как работают хуки, давайте погрузимся в код ядра WordPress, чтобы подтвердить наши гипотезы.

Быстро перемещаться по коду можно с помощью разных инструментов – таких как, к примеру, Yoast’s PHP Cross Reference of the WordPress Source.

Поиск по «add_action» выдает следующий код:

add_action вызывает add_filter, который, в свою очередь, добавляет заданную функцию в массив, связанный с хуком $tag. Несмотря на то, чтобы здесь мы также используем параметры $priority и $accepted_args, данная функция полностью отвечает нашим предположениям. do_action будет чуть длиннее и сложнее:

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

Примеры

Обладая пониманием работы хуков, давайте взглянем на два следующих примера. Первый пример – работа с RSS; вместо того чтобы рассылать уведомления через синдикацию, почему бы не использовать для этого электронную почту?

Система почтовых уведомлений

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

Все, что нам осталось сделать, – это отправить уведомление по электронной почте в обработчике функции notify_via_email. Обратите внимание, что хук publish_post передает ID записи как аргумент в нашу функцию. Это позволит нам получить информацию о записи с помощью функции get_post:

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

Плагин Google Analytics

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

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

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

Наша функция add_google_analytics_code, как и предполагает ее название, печатает код Google Analytics:

Обязательно измените UA-XXXXX-X на ваш личный ID, зависящий от сайта. В итоге все заработает. Просто добавьте указанный код в файл и загрузите его в вашу папку с плагинами. Убедитесь в том, что плагин содержит заголовок — к примеру, такой:

Поменяйте имя автора, URI, ну и не забудьте активировать плагин!

ez code

Просто о сложном.

Создание плагина для WordPress. Часть 2.

В предыдущем уроке мы создали фундамент для будущего плагина, который распознает система WordPress. Сегодня мы займемся непосредственно изменением базового функционала системы.

Поможет нам в этом система «хуков» (hooks), «событий» (actions) и фильтров (filters). Эти три понятия и есть основа каждого плагина для WordPress.

Hooks

В WordPress есть два типа хуков:

  • Action hook: помечает место в коде, которое выполняет определенное действие, например, необходимо внести какие-либо данные и сохранить в базе.
  • Filter hook: помечает фильтр, который будет изменять какое-либо значение (переменную), так что в дальнейшем код будет использовать модифицированное значение.

Actions

Работа с событиями (actions)

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

  1. Пометить место, где действие должно выполниться с помощью хука (action hook) с необходимыми параметрами.
  2. Создать функцию, которая будет выполнять нужные действия, используя параметры переданные хуком.
  3. Зарегистрировать событие, которое будет выполняться при срабатывании хука, с определенным приоритетом.
  4. Когда WordPress загружает страницу и находит hook, система выполнит все функции, которые зарегистрированы на этот хук.

Для выполнения первого пункта система предоставляет функцию ‘do_action’:

Она принимает следующие аргументы: $tag – название “хука”, $arg_1, $arg_2, … , $arg_n – параметры, с которыми будет вызвана функция. Аргументов может быть любое количество, либо 0.

Система сама по себе имеет много уже определенных хуков:

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

В этом примере хук срабатывает при сохранении записи с двумя аргументами post_id — идентификатор записи и post — сама запись.

Создание хуков доступно любому разработчику для создания собственного плагина (или темы). Благодаря этому мы имеем мощный инструмент для управления поведением системы.

Когда мы создали хук и написали функцию, нам необходимо зарегистрировать функцию с помощью «add_action»

Функция ‘add_action’ принимает два обязательных параметра : $tag: название соответствующего хука и $function_to_add: имя функции, которую необходимо вызвать. Другие два параметра дополнительные: $priority: целочисленная переменная, которая определяет порядок выполнения функции (по-умолчанию — 10), $accepted_args_number: количество аргументов, которое принимает функция (по-умолчанию — 1).

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

В этом примере мы создали функцию, которая просто выводит разметку для оповещения и зарегистрировали её в ‘wp_footer’. Как только мы добавим этот код в файл нашего плагина (см. предыдущий урок) мы увидим результат на странице:

Оповещение плагина WordPress

Работа с фильтрами (filters)

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

Функция-фильтр будет принимать это значение и преобразовывать его для дальнейшего использования. Хуки для фильтров немного отличаются от хуков для событий (action hooks).

Функция ‘apply_filter’ создает хук для фильтра с именем $tag и обязательным параметром $value_to_filter (он может быть пустым, но должен быть объявлен). Остальные аргументы необязательны работают так же как и для событий.

Это «скелет» фильтра, который демонстрирует, что фильтр должен:

  1. принимать хотя бы 1 аргумент;
  2. возвращать модифицированное значение.

Функция ‘add_filter’ регистрирует функцию с названием, содержащимся в $function_to_add для хука $tag. Остальные аргументы — $priority и $accepted_args — работают так же как и у хуков для событий.

Рассмотрим пример: обычная для плагина задача — добавить что-нибудь в конец поста. Если подробнее рассмотреть функцию ‘the_content’, которая используется для вывода содержимого записи, мы найдем такой хук:

Используя его мы можем легко добавить что-либо в конец поста.

Обратите внимание, что мы используем большое число для приоритета, что убедиться, что до выполнения ‘msp_helloworld_post_footer’ все стандартные фильтры отработают. После включения кода в наш плагин мы увидим результат:

Как найти хук


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

«Кодекс» WordPress предоставляет списки хуков для фильтров и событий Action Reference и Filter Reference.

Дополнительные действия с хуками

Так же как и добавить, хук можно удалить, используя похожий синтаксис.

Удалить события можно так:

Как вы догадались, ‘remove_action’ удаляет определенное событие, зарегистрированное для данного хука (необходимо правильно указать приоритет и количество аргументов, так как было указано при регистрации), и ‘remove_all_actions’ помогает удалить все события, зарегистрированные для хука (если приоритет опущен, функция удалит все события).

Топ-пост этого месяца:  Как правильно делать подключение шрифтов font face CSS для сайта

Фильтры можно удалять так же:

API для плагинов в WordPress также предоставляет функции для проверки зарегистрирована ли функция для данного хука:

Обе функции проверяют зарегистрирована ли данная функция для хука и возвращают true в случае успеха, иначе flase. Внутри функции у нас есть возможность проверить, что хук вызвал её:

Несмотря на название ‘current_filter’ работает не только с фильтрами но и с событиями.

Нетривиальный пример

Оживим «скелет» нашего плагина, который мы подготовили в прошлом уроке.

Заполним файл ‘core.php’ (главная часть нашего плагина, в которой сосредоточена основная часть функций) кодом, который решает задачу, которая реально может возникнуть в ходе работы. Для её решения мы будем использовать actions и filters.

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

Создадим собственную таксономию для обработки имя автора и его короткой биографии. Мы сможем использовать имя автора как другие термины таксономии (теги, например) в посте. Код:

Как видите, мы создали функцию для регистрации собственной таксономии и привязали её к хуку ‘init’. После мы создали шаблон, отвечающий за отображение блока автора, используя функцию WordPress ‘wp_get_object_terms’. После мы вставили блок с информацией об авторе в конец поста с помощью фильтра ‘the_content’. И, наконец, мы добавили собственный CSS класс. Результат работы:

Заключение

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

Хук публикации поста в WordPress

Одна из самых сильных сторон WordPress — это система хуков (фильтров и экшенов), которая позволяет добавлять свои колбеки на разные события, произошедшие в ядре системы.

Довольно распространенная практика — оповещение подписчиков по email или push о выходе нового поста.

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

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

Покопавшись более детально в документации по WordPress и поспрошая на форумах пришел к тому, что нужно использовать хук изменения статуса поста transition_post_status :

Событие transition_post_status возникает, когда пост переходит из одного статуса в другой. Внутри функции-зацепа мы проверяем, что тип поста post , запись переходит в состояние publish (опубликована) и предыдущий статус не был publish , иначе это свидетельствовало бы о том, что мы редактируем пост.

Добавление пользовательских хуков в WordPress: пользовательские действия

Russian (Pусский) translation by Sergey Zhuk (you can also view the original English article)

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

Но если вы хотите погрузиться в более продвинутую разработку WordPress, стоит знать, как реализовать свои собственные хуки.

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

Начинаем

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

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

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

Но в этом уроке мы концентрируемся на хуках и действиях. Итак, как только вы все настроили, давайте начнем.

Что такое хуки?

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

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

Независимо от того, как он определен в Википедии:

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

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

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

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

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

Во-первых, представьте, что вы работаете в интерфейсе разработки. У вас есть кнопка с атрибутом >command-button , и когда пользователь нажимает на нее, вы хотите отобразить диалоговое окно предупреждений.

Используя jQuery, вы можете реализовать эту функцию следующим образом:

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

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

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

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

В WordPress регистрация собственного кода с помощью события, которое срабатывает, немного отличается. Например, предположим, что вы работаете с страницами администрирования в WordPress, и вы хотите добавить новый элемент подменю в меню «Настройки». Мы назовем его Tuts + Options.

Для этого мы добавим следующий код в наш файл functions.php или в наш плагин или в любой тип проекта, на котором мы сосредоточены:

Вы можете посетить Codex, чтобы узнать больше о hook-файле admin_menu , а также о функции add_submenu_page .

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

Это два практических примера реализации шаблона проектирования, основанного на событиях.

Понимание действий WordPress

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

Настройка нашего файла

В этом уроке мы будем использовать стандартную тему twentysixteen, которая поставляется с WordPress.

В корне каталога темы создайте файл с именем tutsplus-actions.php . Затем в functions.php добавьте следующую строку кода:

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

Краткое определение действий

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

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

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

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

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

Работа с действиями

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

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

И одна из возможностей расширения WordPress — возможность вводить наши собственные типы сообщений. WordPress вызывает эти пользовательские типы сообщений, и они удобны, когда нам нужно создать тип контента, который нуждается в своих собственных типах атрибутов, и который нужно назвать чем-то более конкретным, чем «сообщения» или «страницы».

Чтобы создать свой собственный тип сообщения, нам нужно сделать две вещи:

  1. Определить функцию init , которая перехватывает хук, как это предусмотрено в WordPress
  2. Зарегистрируйте наш тип сообщения с одной из предоставленных функций API


Регистрация нашего действия

Чтобы зарегистрировать наше действие, мы воспользуемся функцией add_action , предоставляемой API WordPress. Она сообщает WordPress, что мы вводим действие и что ему необходимо запустить функцию, идентифицированную именем, которое мы предоставили в вызове функции.

Наш код должен выглядеть так:

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

Далее нам нужно определить функцию.

Ключ к пониманию сигнатуры этой функции прост: мы назвали ее tutsplus_register_post_type , так как это второй аргумент, который мы передали в вызов add_action .

Она буквально инструктирует WordPress сделать следующее: Во время init вызовите функцию tutsplus_register_post_type .

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

Давайте изменим это.

Создание пользовательского типа сообщения

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

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

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

Мы будем полагаться на остальную функциональность, предоставляемую значениями по умолчанию WordPress. Аргументы будут выглядеть так:

И окончательная полная версия кода для регистрации типа сообщения будет выглядеть так:

Когда вы обновляете область администрирования своей WordPress-установки, в пункте Comments, должен появиться новый пункт меню Time Travellers.

Когда вы нажимаете «Добавить новое», вы должны увидеть место для названия (или имени путешественника), редактора (для информации путешественника) и выдержки (возможно, для некоторых заметок о путешественнике). Вы также должны увидеть один мета-бокс для публикации информации.

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

Определение пользовательских действий

Когда дело доходит до создания наших собственных действий, мы должны сделать три вещи. На самом фундаментальном уровне, мы должны сделать следующее:

  1. определить хук
  2. Передать функциональность хуку
  3. Разрешить разработчикам вызвать хук

Самый простой пример, который я могу дать для этого, следующий:

Спокойно добавьте этот код примера в файл tutsplus-actions.php .

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

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

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

Пересмотр типа нашего сообщения

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

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

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

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

Обратите внимание, что в коде выше мы указываем два дополнительных параметра для do_action . Первый параметр — 10, указывающий приоритет, в котором этот крючок будет срабатывать.

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

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

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

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

Заключение

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

Топ-пост этого месяца:  Корректировка ставок по региону в Яндекс Директ - инструкция по настройке

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

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

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

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

Помните, что вы можете просмотреть все мои курсы и учебные материалы на моей странице в профиле, и вы можете следить за мной в моем блоге и/или Twitter в @tommcfarlin, где я рассказываю о различных практиках разработки программного обеспечения и о том, как мы можем использовать их в WordPress.

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

WordPress: собственные хуки

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

Создание хука

Я рекомендую использовать apply_filters(), если вы хотите изменить выводимый текст.

Конфликт имен

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

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

Примером нового название может стать — bologer_email_body , где bologer_ — это уникальный префикс, который поможет избежать проблемы.

Примеры

Расширяем действие: Форма настроек

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

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

Расширяем фильтр: собственный тип поста

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

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

Полезные хуки для WordPress

Список хуков для WordPress движка.

Привет, друзья! Решил с вами поделиться несколькими хуками для WordPress, которыми я систематически сам пользуюсь. Думаю, они вам будут тоже полезны. Так что, сегодня мы с вами будем «кавырять» код темы и оптимизировать его в плане seo. Но будем это делать так, чтобы при обновлении темы всё не затерлось. Давайте для начала разберемся что такое хуки для WordPress и для чего они вообще!?

Хук для ВордПресс – это специальная функция, которая помогает прицепиться «на лету» к основным функциям и изменить их поведения. Это что-то вроде вкраплений. Вы ловите нужную функцию, изменяете её данные как вам надо и воспроизводите её уже измененную. При этом, вы как бы не изменяете код темы или самого движка, а по факту изменения происходят. И любые обновления темы или движка WP, не смогут затронуть ваши изменения.

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

Я не зря обрамил фразу «сео ошибки» в кавычки. Для англоязычного интернета, это вовсе не считается ошибками. Но мы же, обязаны подстраиваться не только под поисковую систему Google, но и под Яндекс тоже. А как известно, Яндекс относиться к определенным стандартам по другому. И чтобы угодить и тому и другому, мы и будем сегодня колдовать. Давайте уже приступим, а то заболтался я что-то.

Отключение замены на «Умные кавычки».

Наверняка вы уже столкнулись с проблемой, что WordPress по умолчанию показывает вместо простых кавычек, так называемые «Умные кавычки». И всё бы ничего, только в тексте, если не поставить пробел перед кавычкой показывается только закрывающая. В итоге, выглядит это не очень красиво. Приведу пример.

Вы в тексте решили написать какой-то текст с кавычками, например: rel=«canonical«. Вроде написали с нормальными двойными кавычками. Но при публикации статьи, вы видите следующее: rel=»canonical». Как то не красиво, согласны?

Существует 2 способа избавиться от таких «Умных кавычек» (их ещё называют французскими кавычками):

  1. Ставить перед каждой открывающей кавычкой пробел (rel= «canonical»). Но это как-то не красиво всё равно выглядит.
  2. Отключить автоматическую замену кавычек специальным хуком. В этом случае, все кавычки будут именно такими, какими вы их хотите видеть.

Итак, хук который отключит автоматические «Умные кавычки» нужно поместить в файл функций functions.php вашей темы.

Выравнивание текста по ширине.


Эта опция изначально заложена в движок по умолчанию. Но по каким-то необъяснимым причинам, её посчитали не особо нужной и отключили. Если вы зайдете в редактор статей, то увидите 3 кнопки выравнивания текста, это:

  1. С левой стороны.
  2. По центру.
  3. С правой стороны.

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

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

Отключение Google шрифтов.

Обычно, темы подключают сторонние Google шрифты, на что даже сам Google ругается . Забавно получается. Так вот, зачастую отключая эти сторонние шрифты, сайт ни чуть не изменяется. Разве что шрифт становиться четче. Ну, конечно если у вас на сайте не подключен какой-нибудь «заковырестый» шрифт. В этом случае, он просто пропадет и будет показываться обычный, стандартный шрифт.

Плюс данного метода – Вы избавляетесь от стороннего подключения. Тем самым, уменьшая время загрузки страницы. Что безусловно будет плюсом для вашего сайта.

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

Чтобы отключить поддержку встроенных Гугл шрифтов, нужно добавить в тот же файл функций следующий код:

Удаление заголовков H2-H6 из сайдбаров.

Сначала прочитайте до конца, потом делайте.

Я уже упомянул, что Google в большинстве случаев относиться к множеству заголовков H2-6 на страницах, лояльно. А вот Яндекс не особо. Да и вообще, опытные сеошники, рекомендуют не увлекаться этими тегами в тех местах, где они не нужны. А заголовки в сайдбарах, это те места, где они не нужны точно.

Я активно пользуюсь всеми заголовками в разметке статей. Но вот в сайдбарах, я рекомендую убирать их, за ненадобностью. По умолчанию, разработчики тем выводят заголовки в сайдбарах с помощью тегов H2-6. В разных темах, теги могут быть разные. У меня были теги H4, у вас могут быть и H3 или даже H2. Выглядит код регистрации боковых колонок примерно вот так:

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

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

  1. Обязательно установить и настроить дочернюю тему.
  2. Отключить регистрацию старых сайдбаров и подключить новые.
  3. И всё это сделать в файле functions.php дочерней темы.

Итак, для начала надо отключить регистрацию старых сайдбаров в теме. Для этого в файле functions.php прописываем следующий хук:

Я специально даю вам код именно в виде функции, так как этой функцией можно отключить сразу несколько сайдбаров. Чтобы узнать точное название сайдбаров, нужно найти функцию подключения их в теме и подсмотреть там. Обычно, их регистрируют в файле functions.php родительской темы, либо в отдельном файле (он может называться либо widget, либо sidebar). Функция регистрации называется register_sidebar.

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

Не забудьте поменять XXX на название вашей темы. После сохранения в сайдбарах поменяются все заголовки на дивы. Но! Если вы откроете сайт сейчас, то сайдбаров вы не увидите. Вам нужно будет перейти в админку и заново добавить нужные виджеты в новый раздел сайдбара. После этого останется добавить стилей заголовкам, чтобы они выглядели прилично. О том, как добавлять стили нужным элементам, я писал в статье – Оформление текста на сайте.

Отключение ненужных виджетов.

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

  1. Избавитесь от возможных дублей страниц (обычно их генерирует виджет Календарь).
  2. Уменьшите число обращений к базе данных (обращается к БД каждый виджет).

Как я уже упомянул, каждый виджет по умолчанию, обращается к базе данных. При чем это происходит не зависимо от того, используется он на странице или нет. То есть, каждый раз, как загружается страница (любая на сайте), каждый виджет обращается по минимум одному разу к базе данных. Отключив не использующие, вы немного ускорите загрузку своего сайта. А теперь, давайте посмотрим как это делается:

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

Удаление файлов license.txt и readme.html.

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

Чтобы автоматически проверять наличие файлов license.txt и readme.html, а потом их сразу удалять, воспользуйтесь ниже представленным хуком. Он будет автоматически проверять на наличие этих файлов и если они присутствуют, хук удалит их. Код нужно поместить, в тот же файл functions.php:

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

Создание своих миниатюр и удаление лишних.

Вы наверняка уже знаете, что WordPress по умолчанию, создает для каждой загруженной картинки 3 версии миниатюр. Плюс к этому, каждая тема, создает ещё от трех, до 7 миниатюр в добавок. И того, для каждой картинки создается до 10 дополнительных. А если у вас на сайте картинок очень много, то в скором времени, ваш сайт разрастется до немыслимых размеров и вам придется увеличивать тариф хостинга.

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

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

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

Теперь, переходим к миниатюрам создаваемым самой темой. Для этого переходим в родительскую тему и ищем в файле functions.php регистрацию стандартных размеров. Функция регистрации называется add_image_size. Ищите эту функцию и скопируйте названия подключаемых миниатюр. После этого, вставьте эти названия в следующую функцию для их отключения:

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

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

Пересоздание миниатюр после отключения.

После того, как вы отключили лишние миниатюры и включили свою, вы не увидите разницы. Дело в том, что эти хуки отключают и подключают размеры в реальном времени. А все картинки загруженные ранее, так и остались в папке uploads. Но если у вас их там уже сотни или тысячи, то удалять их вручную, то ещё занятие. Поэтому, предлагаю установить плагин Force Regenerate Thumbnails и пересоздать миниатюры заново. Плагин автоматически удалит все лишние миниатюры и создаст только те размеры, которые вы включили.

Важно! После всех манипуляций с миниатюрами, обязательно сделайте две очень важные вещи:

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

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

Внимание! Могут полететь картинки в статьях. В этом случае, вам придется эти картинки передобавить. Сделать это можно кликнув на значок битой картинки в редакторе и просто передобавить. Искать заново их не надо, они уже есть, нужно будет просто нажать кнопку «Заменить».

Топ-пост этого месяца:  Основные принципы работы React setState обновление DOM приложения

Циклические ссылки в меню и категориях + rel= «canonical».

Ну, и закончить статью, можно хуками от циклических ссылок на сайте и хуком для «правильного» атрибута rel=canonical. В этой статье я их не буду дублировать (не хочу портить уникальность статей), так что, если нужно, переходите в соответствующие посты. Там по мимо этого море нужной для вас информации, раз уж решили оптимизировать WordPress, оптимизируйте его по полной!

На этом у меня сегодня всё. Как обычно, я с вами не прощаюсь и жду ваших комментариев к этой статье. До встречи, на страницах блога WPMaster.KZ

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

Хуки в WordPress или как вставить информацию в нужное место

Что такое хук в WordPress на примере вывода информации перед комментариями, без внесения изменения в шаблон сайта.

В WordPress есть готовая форма для комментариев, которая выводится с помощью php:

У этой формы есть следующие хуки функций:

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

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

В файл functions.php своей темы WordPress вставляем следующее:

add_action( ‘comment_form_top’, ‘action_add_text’ );
function action_add_text() <
?>

Заметка перед формой комментирования. Например, можно написать пожелания к формату оставленного комментария.

Что такое WordPress хуки и как их использовать?

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

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

Как использовать хук

Хуки используются либо в плагинах, или в functions.php. Чтобы вызвать хук нужно прописать:

publish_post – название хука, все хуки можно посмотреть на официальном сайте WordPress Codex.

add_point – Название функции, которую вы создаете.

Пример функции с хуком

В моем случае функция работает таким образом:

Пользователь добавляет запись, срабатывает хук который вызывает функцию, в которой происходит вся магия �� В функции я работаю с классом $wpdb->update, где обновляю таблицу с балами конкретного пользователя. В уроке insert» href=»https://wp-query.ru/chto-takoe-wpdb-insert-ili-sozdaem-obratnuyu-svyaz-na-primere-chast-1/» target=»_blank»>что такое $wpdb->insert, я рассказывал о классе $wpdb->insert на основе которого вы можете сделать свою функцию с использованием $wpdb->update, данный класс работает аналогичным образом.

Вот как примерно выглядит конструкция с использованием хука:

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

Вот функция с обновлением баллов:

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


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

10 полезных приемов по работе с hook’ами в WordPress

Механизм hook’ов (перехватчиков событий) — крайне полезная вещь в WordPress. Они позволяют «подцепить» к некоторым функциям свои собственные, а значит — откорректировать функции WordPress без редактирования базовых файлов. В этой статье мы собрали 10 действительно полезных hook’ов вместе с примерами и объяснениями кода.

Что такое Hook?

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

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

Hook’и — один из основных «строительных материалов» для программных модулей WordPress. Практически все модули переписывают базовые функции WordPress с помощью hook`ов.

Как использовать hook’и в блоге WordPress

Все hook`и прописываются в файле «functions.php» (если только речь не идет о создании программного модуля). Данный файл можно найти в папке «wp-content/themes/yourtheme».

Как мы уже говорили, hook`и-перехватчики переопределяют одни функции на другие. Так, например, создав собственную функцию, можно подключить ее к одной из базовых функций WordPress.

В нашем случае мы переопределяем собственную функцию на программную функцию публикации записей «publish-post». Каждый раз при выполнении «publish-post» WordPress будет выполнять и связанную с ней функцию.

Само собой, любые hook`и можно удалить посредством функции «remove_action()».

1. Отключение автоматического форматирования WordPress

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

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

Решение. Достаточно вставить в файл «functions.php» представленный ниже код:

После этого можно использовать в записях сокращение «[raw]».

Анализ кода. Первым шагом мы создаем функцию, с помощью обычного выражения ищущую в наполнении записей сокращение «[raw]».

После привязываем функцию «my_formatter()» к программной функции «the_content()». Соответственно, каждый раз при обращении к функции «the_content()» автоматически будет вызываться и «my_formatter()».

Для удаления автоматического форматирования воспользуемся функцией «remove_filter()», позволяющей избавиться от hook’а для конкретной функции.

2. Распознавание браузера посетителя с помощью hook’а

Проблема. Кросс-браузерная совместимость — едва ли не самая распространенная проблема веб-разработчиков. Возможность распознавать браузеры посетителей веб-сайта снимет массу вопросов — если после распознавания создать собственный класс, заключенный в тэг «body». Хотя об этом знают немногие, в WordPress уже реализована возможность распознавания браузеров плюс предусмотрено несколько глобальных переменных.

Решение. Ничего сложного: вставьте представленный ниже код в файл «functions.php». Теперь осталось его просто сохранить!

После сохранения файла функция будет автоматически добавлять класс таблиц стилей к тэгу «body», как в приведенном ниже примере:

Анализ кода. Глобальные переменные WordPress возвращают «true» при использовании посетителем определенного браузера. Если это Google Chrome, значение «true» вернет переменная «$is_chrome». Поэтому мы создаем функцию «browser_body_class()», возвращающую название браузера пользователя. После этого достаточно переопределить ее на программную функцию «body_class()».

3. Распознавание текста в редакторе TinyMCE

Проблема. Многие блоггеры почти во всех записях используют один и тот же стиль. Записи в моем собственном блоге WpRecipes.com всегда выводятся одинаково: часть текста, часть кода, потом еще текст.
Возможно, стоит сэкономить время, сделав так, что текст по умолчанию будет отображать tinyMCE (визуальный редактор WordPress).

Решение. И снова на помощь приходят hook’и. Откройте файл «functions.php», вставьте код — и предоставьте все остальное им!

Анализ кода. Несмотря на широкие возможности кода, сам метод достаточно просто. Просто создайте функцию, которая возвращает нужный текст (в нашем примере простой текст с предложением о подписке на RSS-ленту блога). Теперь достаточно «подцепить» ее к программной функции «default_content()».

4. Автоматическая вставка наполнения после каждой записи

Проблема. Для вставки после записи текста, изображений или рекламы в блогах чаще всего используется шаблон «single.php». Само собой, для этого можно открыть «single.php» и после функции «the_content()» внести нужный текст. Но что если текст не отображается в RSS-ленте? Решить проблему помогут hook’и и описанный ниже прием.

Решение. И снова просто вставьте код в относящийся к нужной теме файл «functions.php». Вот и все.

Анализ кода. Задача функции «insertFootNote()» предельно ясна: она сцепляет определенный текст с переменной «$content», включающей содержимое записи.

Затем наша функция «insertFootNote()» переопределяется на функцию «the_content()», автоматически вызываясь каждый раз при обращении к «the_content». Принцип работы с данной функцией аналогичен набору текста в конце каждой записи.

Обратите внимание на условие «(!is_feed)» в строке 2, препятствующее вставке текста в RSS-ленту. Чтобы снять это ограничение, замените строку 2 на следующий код:

5. Отключение сообщения «Please Update Now» на консоли WordPress

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

Решение. В файл «functions.php» достаточно добавить четыре строки кода.

После сохранения файла «functions.php» сообщения на консоли вы больше не увидите.

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

6. Отключение автосохранения записей в WordPress

Проблема. При наборе записи через консоль WordPress периодически сохраняет ее наполнение. Это полезная функция, но иногда возникает потребность ее отключить.

Решение. Для отключения автосохранения в WordPress откройте файл «functions.php» и вставьте следующую функцию:

Анализ кода. И вновь ничего сложного. Мы просто создаем действие (в строке 4) и переопределяем созданную в строке 1 функцию «disableAutoSave()» на программную «wp_print_scripts()».

В результате наша функция «disableAutoSave()» вызывается при каждом выполнении программой «wp_print_scripts()». Тем самым мы отключаем автосохранение в WordPress.

7. Борьба с дублированием наполнения на странице комментариев

Проблема. Дублирование наполнения — SEO-проблема многих сайтов. Она может стать актуальной и для вашего блога, если только не воспользоваться некоторыми хитростями.

Появившийся в версии 2.7 постраничный вывод комментариев (paged comments) стал ценным дополнением к WordPress, поскольку теперь блоггеры получили возможность разбивать массу комментариев на несколько страниц. Единственная проблема при этом, как уже упоминалось выше, — риск дублирования наполнения.

Чтобы избежать дублирования в постраничных комментариях, воспользуемся новым атрибутом rel=»canonical».

Решение. Просто вставьте представленный ниже код в файл «function.php».

Анализ кода. Первым шагом создаем функцию, добавляющую к комментариям страниц (за исключением страницы 1) атрибут rel=»canonical». После переориентируем ее на программную функцию «wp_head()». Только и всего!

8. Превращение записи или страницы в PHP-переменную

Проблема. Возможность превратить текущую запись или страницу в PHP-переменную определенно полезна. Среди прочего можно, например, заменить часть наполнения с помощью PHP-функции «str_replace()».

Решение. И снова ничего сложного. Просто вставьте код в файл «functions.php».

Анализ кода. Для этого приема нам понадобятся три функции:
— callback(): данная функция возвращает страницу целиком в виде переменной «$buffer». Перед этим можно модифицировать ее с помощью стандартных выражений.
— buffer_start(): данная функция просто запускает буфер, переопределяясь на программную функцию «wp_head()».
— buffer_end(): данная функция очищает буфер, переопределяясь на программную функцию «wp_footer()».
Как только наша функция будет готова, просто свяжем ее с программными функциями WordPress.

9. Планирование событий с помощью Cron и hook’ов

Проблема. Как вы, возможно, знаете, в WordPress есть возможность планировать события, например, публикуя записи в предварительно заданные дни и часы. С помощью hook’ов и «wp-cron» легко запланировать свои собственные события. В нашем примере блог WordPress раз в час будет отправлять нам электронное сообщение.

Решение. Вставьте блок с приведенным ниже кодом в относящийся к нужной теме файл «functions.php».

Анализ кода. Первым делом, мы, конечно же, создали функцию, выполняющую нужное действие. В данном примере это функция «my_task_function()», которая просто отправляет сообщение на указанный адрес электронной почты.

Чтобы запланировать событие, воспользуемся функцией «wp_schedule_event()». Последним аргументом должен быть hook, вот почему мы переопределяем функцию «my_task_function()» на «my_task_hook».

10. Вывод всех функций с hook’ами

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

Решение. Как и в предыдущих примерах, достаточно вставить предложенный код в файл «functions.php». По окончании отладки не забудьте удалить его из файла, иначе служебное сообщение будет появляться и дальше.

Сделав это, просто вызовите функцию «list_hooked_functions()», как показано ниже, для вывода на экран всех функций WordPress с hook’ами.

Анализ кода. Если в качестве аргумента функции не дается имя hook’а, то hook’и выводятся на экран посредством глобальной переменной «$wp_filter». Альтернативный вариант: отображение в списке конкретного hook’а при передаче его имени в качестве атрибута:

Как в wordpress обратиться к custom функции?

Как в wordpress правильно обращаться к кастомным функциям темы, например при отправки формы или ajax запросе, может есть возможность создать системную страницу вида /ajax.php?

  • Вопрос задан более трёх лет назад
  • 238 просмотров

Системная страница уже существует, admin-ajax.php
Читайте про хуки — actions and filters.

А вообще в мире WordPress есть 2 типа вызова функций. Один — использовать самым обычным образом в потоке (например, вставить в шаблоне какой-то страницы и в этом месте на страничке получить результат работы этой функции), другой — подключать функции с помощью хуков в определенные «опорные точки». Подключенные функции будут выполняться WordPress’ом по мере достижения этих точек.

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

Аякс в wordpress работает иным способом.

Сергей Цалоев: это само по себе решение с кривой архитектурой. Я бы вынес решение в подмешивание или даже в плагин (с шорткодом) — там уже можно реализовать mvc или простейшее разделение на шаблоны, helper с функциями и собственно обработку событий. А функции из functions.php убрать и инкапсулировать, т.к. этот файл не предназначен для реализации формы обратной связи. Тогда вы полностью избавитесь от логики в шаблоне, и будете выводить только шорткод вашего плагина.

Если делать все в functions.php без плагинов (хотя на мой взгляд это худшее решение, нежели выше), то можно:
— в шаблоне вывести просто форму, без логики
— проверять посланные данные в хуке template_include или wp_head (они для этого не предназначены, но зато срабатывают до всех прочих действий с выводом)
— далее, по условию, можно либо отправить письмо, либо сделать редирект, либо просто записать состояние в переменную и использовать ее в более позднем хуке, или по условию вывести сообщение в шаблон

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

Добавить комментарий