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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• WP-Optimize
• P3 (Plugin Performance Profiler)
• WP-DBManager
• WP Performance Pack

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

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

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

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

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

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