На такой отзыв можно было бы закрыть глаза, однако Джастин Сэйнтон, один из основателей WP eCommerce, дал на него развернутый ответ. Он подтвердил, что жалоба пользователя соответствует истине, и они работают над тем, чтобы лучше задокументировать этот аспект.
«Мы приняли намеренное решение не удалять таблицы из базы данных, когда люди деинсталлируют или деактивируют WP eCommerce», отметил Сэйнтон.
«Нас подтолкнул к этому тот опыт, который мы получили за годы работы с пользователями, которые деактивировали и удаляли плагин. Даже при том, что WordPress явно сигнализирует об удалении данных, это уведомление очень легко проигнорировать, когда вы находитесь в своих мыслях».
«По этим причинам мы приняли решение не удалять какие-либо из данных (непредумышленное удаление большинства из которых привело бы к огромным проблемам для бизнеса) после деинсталляции».
Что представляют собой такие «осиротевшие» таблицы в базе данных?
«Осиротевшие» таблицы – это такие таблицы, которые оставляются плагинами в базе данных после своей деинсталляции. Эти таблицы зачастую содержат данные, включая формы, записи, настройки и т.д. К примеру, когда я устанавливал GravityForms 2.0 на тестовом сайте Tavern, я обнаружил, что формы, которые я создавал шесть лет назад, до сих пор остались в базе данных. Я был не только удивлен, но и благодарен GravityForms, что они не удалили эти данные за столько лет.
Деактивация плагина не должна удалять данные
Есть явные отличия между деактивацией плагина и его удалением. Процесс деактивации плагина происходит гораздо чаще, чем удаление, что связано с поиском и устранением неисправностей. Деактивация плагина не должна приводить к удалению информации из базы данных. Подумайте о том, насколько ужасно было бы, если бы после деактивации плагинов их пришлось бы заново настраивать с нуля.
Удаление данных должно быть явным
Удаление данных должно быть явным, подтвержденным действием пользователя. Разработчики плагинов, которые хотят дать возможность своим пользователям удалять данные, могут зарегистрировать хук для деинсталляции и добавить файл Uninstall.php. Вот выдержка из статьи, посвященной Uninstall.php:
«Если плагин не может быть написан, не выполняя определенного кода внутри себя, то в таком случае этот плагин должен создавать файл uninstall.php в своей базовой папке. Этот файл будет вызываться в процессе удаления плагина. Плагин, использующий uninstall.php, должен обязательно проверять константу WP_UNINSTALL_PLUGIN перед выполнением.
Разработчики, использующие этот метод, должны предоставить пользователям ясное окно с подтверждением действия, в котором было бы указано о том, что данные будут удалены. Яркий пример плагина, который великолепно реализует этот подход – GravityForms. Процесс удаления плагина отделен от процесса деактивации. Из предупреждения становится ясно, что все данные будут потеряны.
Оставшиеся в базе данных таблицы обычно не влияют на производительность сайта
Некоторые люди считают, что большое количество таких «осиротевших» таблиц может негативно сказаться на производительности сайта. Я узнал у Сэйнтона, верно ли это, на что он ответил следующее: «Вообще говоря, нет».
«Бывают, конечно, случаи, когда количество таблиц, имеющихся в вашей базе данных, может потенциально повлиять на производительность некоторых запросов. Однако эти типы запросов в действительности не должны выполняться в большинстве контекстов – в частности, не в тех контекстах, в которых были бы заинтересованы разработчики WordPress».
Большинство обычных пользователей WordPress редко касаются вопроса оставшихся в базе данных таблиц. Многие, вероятнее всего, просто не знают об этих данных и таблицах, занимающих байты пространства. В большинстве случаев эти таблицы никоим образом не влияют на производительность сайта, поэтому можно просто не беспокоиться о них.
Очистка оставшихся таблиц
Есть много плагинов, которые позволяют оптимизировать и очистить неиспользуемые таблицы в базе данных. Вот лишь некоторые примеры таких плагинов:
Перед тем как использовать какой бы то ни было из плагинов по очистке базы данных обязательно создайте полный бэкап сайта.
У меня уже был негативный опыт использования плагина для очистки БД, когда он вроде бы сделал все, как положено, но при этом удалил лишнее – произвольные статусы записей, созданные Edit Flow.
Должен ли процесс деинсталляции быть прописан в требованиях каталога плагинов?
Многие плагины в каталоге не используют Uninstall.php и не регистрируют хук для деинсталляции. Я считаю, что любой плагин, который добавляет свои данные в базу данных, должен обеспечивать простой путь для их удаления.
Наличие инструкции значительно упростило бы жизнь многим пользователям, позволив сохранить их базы данных чистыми.
Вопрос к разработчикам: предлагаете ли вы какие-либо способы удаления данных, которые были добавлены вашими плагинами в пользовательскую базу данных?
