Почему некоторые плагины оставляют неиспользуемые таблицы в базе данных после своей деинсталляции?

Дата публикации:Июнь 28, 2016

Отзывы о WordPress плагинах в каталоге поступают от пользователей в разных видах и формах. Одни являются действительно полезными, в то время как другие представляют собой просто короткий текст, сводящийся к сути работы плагина. К примеру, вот недавний отзыв о WP eCommerce от одного из пользователей: «Я удалил плагин, и он оставил после себя неиспользуемые таблицы, которые мне пришлось очищать вручную. Ужасно написанный плагин».

unins

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

«Мы приняли намеренное решение не удалять таблицы из базы данных, когда люди деинсталлируют или деактивируют WP eCommerce», отметил Сэйнтон.

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

«По этим причинам мы приняли решение не удалять какие-либо из данных (непредумышленное удаление большинства из которых привело бы к огромным проблемам для бизнеса) после деинсталляции».

Что представляют собой такие «осиротевшие» таблицы в базе данных?

«Осиротевшие» таблицы – это такие таблицы, которые оставляются плагинами в базе данных после своей деинсталляции. Эти таблицы зачастую содержат данные, включая формы, записи, настройки и т.д. К примеру, когда я устанавливал GravityForms 2.0 на тестовом сайте Tavern, я обнаружил, что формы, которые я создавал шесть лет назад, до сих пор остались в базе данных. Я был не только удивлен, но и благодарен GravityForms, что они не удалили эти данные за столько лет.

Деактивация плагина не должна удалять данные

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

Удаление данных должно быть явным

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

«Если плагин не может быть написан, не выполняя определенного кода внутри себя, то в таком случае этот плагин должен создавать файл uninstall.php в своей базовой папке. Этот файл будет вызываться в процессе удаления плагина. Плагин, использующий uninstall.php, должен обязательно проверять константу WP_UNINSTALL_PLUGIN перед выполнением.

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

GFormsUninstallProcess

Оставшиеся в базе данных таблицы обычно не влияют на производительность сайта

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

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

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

Очистка оставшихся таблиц

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

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

У меня уже был негативный опыт использования плагина для очистки БД, когда он вроде бы сделал все, как положено, но при этом удалил лишнее – произвольные статусы записей, созданные Edit Flow.

Должен ли процесс деинсталляции быть прописан в требованиях каталога плагинов?

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

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

Вопрос к разработчикам: предлагаете ли вы какие-либо способы удаления данных, которые были добавлены вашими плагинами в пользовательскую базу данных?

Поделиться

10 комментариев

  1. Спасибо статья хорошая. то что удаленные плагины оставляют в БД после себя «мусор» думаю многим кто немного понимает в сайтостроени понятно но вот о плагинах которые чистят базы данных для wordpress я признаться слышу в первый раз. И кстати отчасти согласен что при переустановке плагина его настраивать заново это нудно поэтому полезно что по определенному плагину таблицы могут автоматом подрубится и все норм. — при этом какой смысл ставить плагины не осознано, думаю надо иметь необходимый перечень плагинов обязательных к установке иэто более прагматично чем засорять БД. Спасибо за статью.

  2. Статья очень полезная

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

  4. bersy says:

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

  5. bersy says:

    Или хотя бы упоминания в каком-нибудь виде?

    • Дмитрий says:

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

  6. Обычно пользуюсь плагинами для чистки и оптимизации БД. Статью эту дочитал и вспомнил, что было бы неплохо зайти в phpmyadmin и проверить их качество их работы с базой данных.

  7. Да многие плагины, оставляют свои базы, это проблема криворуких программистов

  8. Юрий says:

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

    • Юрий, когда плагин или тема используют в настройках (wp_options) флаг autoload — а потом сам плагин удаляется — все его оставшиеся опции загружаются вместе с движком при каждом запросе страницы. Отсюда проблемы со скоростью и памятью.

Оставить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

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