Удаляет ли плагин удаление WordPress обратно в исходное состояние?

Каково время жизни плагина в развернутом экземпляре WordPress?

А именно:

  • плагины модифицируют существующие файлы или используют только определенные точки расширения в WordPress?
  • плагинам разрешено изменять схему базы данных (например, добавлять новые столбцы)?
  • как WordPress гарантирует, что удаление плагинов всегда оставляет WP в исходном состоянии? (Имеет ли это?)

Короткий ответ:

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

Крючки для плагинов

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

http://codex.wordpress.org/Plugin_API

В качестве примера функция get_option() считывает параметр сайта из базы данных. Перед выполнением любых реальных действий внутри этой функции WordPress вызывает apply_filters( 'pre_option_' . $option, false ) . Учитывая опцию foobar , плагин может переопределить истинное значение этой опции с помощью следующего кода:

 function override_foobar( $unused ) { return 'My custom value.'; } add_filter( 'pre_option_foobar', 'override_foobar' ); // add_filter(hook, function) 

См. Также http://adambrown.info/p/wp_hooks/ .

Плагины, изменяющие базу данных

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

Это должно быть рассмотрено на основе плагина.

Удаление плагинов

Функция deactivate_plugins() вызывает действие do_action( 'deactivate_' . trim( $plugin ) ) . Плагин должен подключаться к этому действию, если определенные вещи должны произойти, когда плагин отключен. По моему опыту, несколько плагинов делают большую очистку от дезактивации, т.е. помещая их настройки в холодное хранение, если они снова активируются.

Плагины в WordPress делают то, что говорит код. Чтобы конкретно ответить на ваши вопросы,

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

Таким образом, это оставляет вопрос, что можно сделать, если автор плагина предает ваше доверие и делает что-то злое на вашем сайте? Наличие регулярных резервных копий вашего каталога wp-контента, а также всей вашей базы данных – лучший способ убедиться, что вы сможете восстановить в случае, если что-то случится с вашим сайтом (например, потеря данных, взломать атаку, плохой плагин и т. Д.), ,

Прямой ответ: НЕТ

Плагины могут делать все, что вы можете сделать с PHP-кодом.

Это зависит полностью от плагина.

  • Плагины модифицируют существующие файлы или используют только определенные точки расширения в wordpress?

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

  • плагинам разрешено изменять схему базы данных (например, добавлять новые столбцы)?

Разрешено кем? WordPress? Тогда да. Но, как и выше, они обычно этого не делают. Самым резким, как правило, является добавление собственной таблицы.

  • как WordPress гарантирует, что удаление плагинов всегда оставляет WordPress в исходном состоянии? (Имеет ли это?)

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

Суть в том, что вы не можете полагаться на разработчиков плагинов, чтобы всегда следовать лучшим практикам, но вы можете положиться на себя. Лучшее, что вы можете сделать, – никогда не устанавливать на своем производственном сайте неизвестный / непроверенный (по вашему) плагин. Всегда выполняйте тестирование в промежуточной среде, пока вам не станет удобно, что делает плагин (или не делает). И сохраните чистую резервную копию, с которой вы можете вернуться назад, прежде чем делать какие-либо изменения. Следуя передовым методам – ​​лучший способ избежать проблемы – просто потому, что некоторые разработчики плагинов не следуют передовым методам (например, очистка их беспорядка), это не значит, что вы тоже этого не должны делать.