register_uninstall_hook () vs uninstall.php - какой из них лучше справиться с скриптом удаления плагина?

сегодня, просматривая WP Codex, я видел два способа обработки сценариев удаления плагинов (например, удаление, параметры, данные, таблицы и т. д.). Один из способов - использовать register_uninstall_hook(), а другой - с помощью простого uninstall.php

Хотя страница codex дает много информации об обоих из них, но он не говорит, в чем преимущество использования одного над другим.

Поскольку здесь так много гуру WP, я думал, что должен задать этот вопрос о том, какой вариант является лучшим способом обработки сценария удаления? Использование register_uninstall_hook() или uninstall.php?

Надеюсь, что кто-то разъяснит. Спасибо заранее.

7 голосов | спросил iSaumya 8 +03002016-10-08T17:45:11+03:00312016bEurope/MoscowSat, 08 Oct 2016 17:45:11 +0300 2016, 17:45:11

2 ответа


4

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

Из документов, включенных в original commit :

  

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

     

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

TL; DR: . Ваш плагин должен быть действительно структурирован таким образом, чтобы не использовать unisntall.php, но использование этого в любом случае добавляет дополнительную защиту от случайного запуска во время удаления.

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

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


Обратите внимание, что uninstall_plugin() будет запускать pre_uninstall_plugin и uninstall_{$plugin_file} [edit: uninstall_{$plugin_file} будет работать, только если register_uninstall_hook()] , независимо от того, какой метод вы используете. (См. Билет # 34569 .)

ответил J.D. 8 +03002016-10-08T23:51:44+03:00312016bEurope/MoscowSat, 08 Oct 2016 23:51:44 +0300 2016, 23:51:44
1

Ну, это зависит от того, чего вы хотите. register_uninstall_hook() создает крючки, и он выполняется, когда uninstall ссылка нажата. Это означает, что на самом деле создается крючок, который будет вызываться при нажатии ссылки удаления. Предположим, вы разработали плагин и на основе этого плагина хотите создать другие плагины, а те, которые добавляются в плагины, должны выполнить операцию на основе деинсталляции плагинов, тогда этот крючок будет полезен. здесь вы получите полный обзор.

И uninstall.php - это общий деинсталлятор для вашего плагина. Он отключит ваш плагин. Но по умолчанию он не обеспечивает никаких привязок.

Посмотрите здесь для получения дополнительной информации.

ответил CodeMascot 8 +03002016-10-08T19:21:31+03:00312016bEurope/MoscowSat, 08 Oct 2016 19:21:31 +0300 2016, 19:21:31

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132