Вопрос или проблема
Я бы хотел предотвратить обработку плагина при его активации / деактивации, поэтому я использую следующий код:
$get = map_deep( wp_unslash( $_GET ), 'sanitize_text_field' );
if ( isset( $get['action'] ) && ( $get['action'] === 'activate' || $get['action'] === 'deactivate' ) ) {
return;
}
if ( isset( $get['activate'] ) && $get['activate'] === 'true' ) {
return;
}
if ( isset( $get['deactivate'] ) && $get['deactivate'] === 'true' ) {
return;
}
Покрывает ли это все возможности или существуют более элегантные функции, фильтры, хуки и так далее?
Большое спасибо.
Ответ или решение
Чтобы ответить на ваш вопрос о предотвращении обработки плагина при его активации или деактивации, важно учесть весь контекст, предоставленный в вашей архитектуре кода и рассмотреть, насколько надёжно и полно текущая реализация выполняет эту задачу в пределах WordPress. Ваша текущая стратегия, как представлено, основывается на проверке параметров, передаваемых через URL-адрес, а именно $_GET для определения того, производится ли активация или деактивация. Давайте рассмотрим это более подробно.
Теория:
Функционал активации и деактивации плагинов в WordPress управляется через использование специальных хуков, таких как register_activation_hook и register_deactivation_hook. Эти хуки предназначены для выполнения определённых действий, когда плагин активируется или деактивируется. Ваша попытка предотвратить выполнение каких-либо действий при активации или деактивации, основываясь на параметрах GET-запроса, может быть ограниченной и уязвимой, поскольку она полагается на параметры, которые могут не всегда обеспечивать надёжный способ определения, инициирует ли текущее действие именно активацию или деактивацию плагина.
Пример:
Представим сценарий, в котором вызовите активацию плагина непосредственно через интерфейс администрирования WordPress. В этом случае взаимодействие идёт через методы WordPress, и передача параметров может обходиться без явных указаний в $_GET, тем более могут быть учтены и другие параметры или даже контексты, через которые плагин может быть программно активирован.
Ваш код защищает лишь наиболее тривиальные случаи, когда присутствует ?action=activate или ?activate=true, что явно недостаточно. Рекомендованные хуки для управления активацией и деактивацией плагина реализуются без необходимости процедуры, подобной проверке $_GET.
Применение:
Для надёжного конструкта рекомендуется использовать существующие механизмы активации через хук register_activation_hook и register_deactivation_hook при этом, если вы хотите вообще размещаться вне стандартных скриптов активации и деактивации, стандартной практикой является использование хука plugins_loaded:
add_action('plugins_loaded', 'skip_activation_and_deactivation');
function skip_activation_and_deactivation() {
if (is_admin() && isset($_GET['action']) ) {
if ($_GET['action'] === 'activate' || $_GET['action'] === 'deactivate') {
return false;
}
}
}Это гарантирует, что ваш код не будет запускать дополнительные процессы, исходя из условий активации или деактивации, тем самым позволяя избежать некорректных рекурсий или побочных эффектов.
Таким образом, вы можете избежать сложностей путём более чёткого разграничения функционала и полагания на встроенные возможности WordPress, что делает систему более устойчивой и безопасной.
Также важно учитывать, что у вас есть возможность видеть более детальное управление процессами через AJAX-запросы, что может предотвратить ненужные изменения статусов плагина через манипуляцию URL без вмешательства административной панели.
В конечном итоге, лучшая практика сводится к тому, чтобы полагаться на профильную активность платформы и интегрировать проверки без непосредственного вмешательства в общий интерфейс управления плагинами, а не на обходные манёвры манипуляции параметрами URL.