Использование хуков WordPress для очистки кода, активации и удаления

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

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

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

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

• Крюк активации
  • Последовательность установки
  • Сброс правил перезаписи
  • Создание таблиц базы данных
  • Проверки зависимостей
• Крюк деактивации
• Крюк удаления
• Дополнительная безопасность
• Пришло время очистить

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

Крюк активации

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

Ключом ко всему этому является функция register_activation_hook() . Первый параметр — это путь к основному файлу плагина; второй параметр определяет функцию для запуска. Внутренне функция register_activation_hook() является оболочкой для действия «activate_[plugin_name]», но, поскольку ее немного проще использовать, необычно видеть ловушку в плагинах.

Последовательность установки

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

Давайте посмотрим на пример, чтобы понять, почему это огромный облом:

Сброс правил перезаписи

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

Приведенный ниже код кажется логичным, но не сработает.

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

Вот как выглядит ход процесса:

1. Пользователь устанавливает плагин.
2. Пользователь нажимает ссылку активации.
3. Промежуточная страница запускает только хук активации, ничего больше. Это сбрасывает правила перезаписи.
4. Плагин активен, и код работает как обычно. Пользовательский тип записи регистрируется.

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

Если эта опция существует, мы делаем активацию, а затем удаляем ее.

Что-то вроде этого:

Лично мне такое решение не очень нравится. Проблема в том, что проверка в восьмой строке запускается при каждой загрузке страницы. Не о чем беспокоиться, так как это не создаст большой нагрузки на ваши серверы и не замедлит работу сайта для ваших пользователей. Это очень быстрая проверка с незначительным влиянием на производительность. Однако в 99,9% случаев это не нужно.

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

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

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

Создание таблиц базы данных

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

Этот пример из статьи Кодекса о создании таблиц показывает, как можно использовать несколько вызовов активации:

Первая функция jal_install() создает новую таблицу базы данных. Вторая функция, jal_install_data , добавляет в таблицу исходные данные. Вместо использования register_activation_hook() для добавления одной функции, содержащей весь этот код, мы можем использовать register_activation_hook несколько раз.

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

Проверки зависимостей

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

Код ниже проверяет минимальную версию WP и PHP и при необходимости перенаправляет пользователя (без активации плагина):

Крюк деактивации

Хуки деактивации запускаются, когда пользователь деактивировал плагин, но до его деинсталляции (удаления). Хуки деактивации используются так же, как и хуки активации:

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

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

Кодекс рекомендует делать их, как показано ниже, но это не работает :

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

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

Хотя это работало для меня в прошлом, я бы не рекомендовал это. Это вносит большую неопределенность, чем проблема наличия нескольких дополнительных правил перезаписи. Я бы предпочел показать пользователям примечание с просьбой посетить настройки постоянной ссылки после деактивации, что сбросит правила перезаписи. Пока не будет реализовано лучшее решение, мы застряли с этим… извините!

Крюк удаления

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

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

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

Как уже говорилось, это не лучшее решение. Гораздо лучший способ справиться с удалением — использовать файл uninstall.php . Все, что вам нужно сделать, это создать его, и он будет использоваться, если он доступен.

Как видите, это на самом деле более простое решение. Лучше всего то, что он автономен.

Дополнительная безопасность

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

Используйте следующий фрагмент кода для активации и деактивации:

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

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

Пришло время очистить

Если ваш плагин добавляет что-то в WordPress, то ваша обязанность как разработчика — удалить его, когда пользователь решит удалить ваш плагин.

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

Если вы еще не являетесь участником WPMU DEV, зарегистрируйтесь сегодня, чтобы получить бесплатную пробную версию, совершенно без риска. Став участником, вы получите доступ ко всем нашим замечательным плагинам и невероятно быстрому хостингу, а также экспертную поддержку 24/7 по всем вашим вопросам и проблемам, связанным с WordPress.

• WordPress разработчики
• Хуки WordPress