Здравствуйте, уважаемые читатели блога www.сайт. Если тексты статей на сайте, работающем на CMS WordPress, то очень скоро объем базы данных сайта увеличится многократно.

Дело в том, что начиная с версии 2.6 в WordPress был добавлен очень полезный и нужный механизм ревизий (редакций) записей.

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

Ревизии в WordPress позволяют избежать потери данных за счет того, что все предыдущие версии записей не удаляются из базе данных, а лишь получают другой статус — «revision »

В слове “все” предыдущего абзаца как раз и кроется причина неограниченного роста размера базы данных. Каждая редакция (ревизия) записи содержит ее полное содержание. А это значит, что если в процессе подготовки какой-либо статьи вы исправили и перезаписали ее, скажем, 10 раз, то в базе данных будет сохранено 10 копий. Если вы исправите всего один знак, в базу еще раз добавится текст целиком.

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

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

Управление количеством ревизий записей в WordPress

Для управления механизмом сохранения редакций записей в WordPress в файл конфигурации “wp-config.php ” после:
/** The Database Collate type. Don"t change this if in doubt. */
define("DB_COLLATE", ""); необходимо добавить всего лишь одну запись.
Для ограничения количества редакций тремя экземплярами:
define("WP_POST_REVISIONS", 3); Вместо “3” может быть любое нужное вам значение. “0” отключит сохранение ревизий. Такой же результат будет достигнут, если вместо цифры написать “false”:
define("WP_POST_REVISIONS", false);
Если по какой-либо причине нужно вновь разрешить сохранение всех редакций без удаления данной строки из “wp-config.php ”, то можно написать:
define("WP_POST_REVISIONS", true);

Тип ревизий записей в WordPress

В свою очередь редакции делятся на две категории:

1. редакторские ревизии — предыдущие версии текстов, появившиеся после публикации или сохранения редактором (автором) обновленной записи;
2. автосохраненные ревизии — автоматически создаются через определенные временные интервалы.

Как интересно. Пока писал этот пост заметил интересную особенность. Если запись находится в статусе «Черновик», то автосохраненные редакции у нее отсутствуют. Выходит, что на черновик автосохранение не распространяется. Стало быть, забывать нажимать на «Сохранить» при работе с черновиком в редакторе WordPress не стоит.

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

Автосохранение позволяет не потерять недавно набранные данные в том случае, если автор забыл сохранить их принудительно (получается, что на черновик это не распространяется).

Изменить интервал автосохранения можно добавив в файле конфигурации WordPress “wp-config.php ” строку:
define("AUTOSAVE_INTERVAL", 60); где 60 – интервал в секундах, соответствующий установленному по умолчанию. Его можно скорректировать в любую нужную сторону.

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

Если надо удалить все релизы, то сделать это можно без установки плагинов непосредственно в базе MySQL через phpMyAdmin.

Заходим в phpMyAdmin и выбираем нужную базу в левом столбце интерфейса. Начинаем, естественно, с .

Бекап базы данных

Переходим на вкладку “Экспорт”:

В открывшемся окне оставляем настройки без изменений. Нажимаем “ОК” в правой нижней части экрана и ждем завершения операции сохранения бекапа базы данных.

Запросы к базе данных на удаление ревизий и оптимизацию таблицы wp_posts

Переходим на вкладку “SQL”. В поле запросов к базе данных пишем:
DELETE FROM wp_posts WHERE post_type = "revision";
OPTIMIZE TABLE wp_posts;

Нажимаем “OK”, подтверждаем желание выполнить запросы к базе.

После успешного завершения запросов должно появиться сообщение такого вида:

При желании можно писать и выполнять запросы последовательно.

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

Лично я на этом бы уже и остановился – максимальное число сохраняемых релизов настроено, база данных очищена и оптимизирована. При желании, по прошествии некоторого периода времени, определяемого объемом сделанных на сайте изменений текстов, очистку базы описанным способом можно повторить.

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

Как удалить WordPress плагин через консоль

Перед тем, как рассмотреть грамотное удаление плагина WordPress, давайте сначала обсудим типичные способы удаления плагинов пользователями в WordPress. Первый способ – удаление через консоль. Выполните следующие действия, чтобы удалить плагин WordPress обычным способом (с сохранением данных).

1. Перейдите в «Installed Plugins» в вашей консоли, после чего щелкните по кнопке «Deactivate» рядом с названием плагина. В нашем примере мы удалим плагин
2. Теперь можно просто щелкнуть по Delete.

Как удалить плагин WordPress через FTP

Второй распространенный способ удаления плагинов пользователями – удаление через FTP (с сохранением данных). Выполните следующие действия.

1. Подключитесь к своему WordPress сайту через SFTP.
2. Перейдите в папку /wp-content/plugins/. Удалите папку с требуемым плагином с вашего сервера.

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

Проблема с удалением плагинов WordPress

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

Многочисленные плагины также оставляют дополнительные файлы и папки. Как показывает практика, это нередко происходит в случае с плагинами безопасности и кэширования, которые создают дополнительные каталоги для ведения журналов. К примеру, после того как плагин Wordfence был удален, у нас на сервере осталась папка wflogs в каталоге wp-content. Мы не пытаемся обвинить именно Wordfence – этим грешат многие плагины.

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

Почему разработчики не очищают базу данных?

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

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

Если вы считаете, что вы можете позднее вернуться к плагину, то в таком случае простое удаление плагина с использованием одного из вышеперечисленных методов – лучший путь.

Они не заботятся о производительности

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

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

Они допустили ошибку

Справочник по плагинам WordPress создан для разработчиков. В нем содержатся лучшие практики и рекомендации по деактивации плагинов и деинсталляции плагинов (удалению данных). В справочнике говорится:

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

Если эта ошибка допущена разработчиком, это означает, что деинсталляция, которая должна очищать все данные, просто запускает процесс деактивации, оставляя все данные.

Как удалить WordPress плагин (правильный способ)

В нашем примере мы снова обратимся к плагину Wordfence. Одной из проблем с удалением WordPress плагина надлежащим образом является то, что каждый разработчик рассматривает это по-своему. Вам, скорее всего, понадобится выполнить поиск в Google, чтобы посмотреть документацию разработчиков на их сайтах или написать им на электронную почту. Как вы можете видеть, если искать в Google “how to uninstall Wordfence”, первый же результат является официальной документацией, в которой рассказывается, как полностью удалить Wordfence.

Хорошо разработанный плагин должен включать в себя опцию для полного удаления. Вы можете видеть пример ниже с плагином Gravity Forms. Быстрый клик по кнопке Uninstall Gravity Forms, и все таблицы и данные удалены. Еще один хороший пример: плагин Polylang. В разделе Tools у него есть опция для полного удаления данных при щелчке по ссылке Delete. Но для этого данную опцию нужно сначала включить.

Если вы не деинсталлируете мультиязычные плагины корректным способом, то они будут обновлять данные переводов для разных сторонних плагинов даже после своего удаления. Wordfence рекомендует установить еще один плагин, Wordfence Assistant, который позволяет полностью удалить сам плагин, все его данные и его настройки. Как вы можете видеть ниже, после установки этого плагина появляются опции для удаления данных и таблиц Wordfence, очистки всех заблокированных IP-адресов, а также данных трафика в реальном времени.

Другие плагины WordPress могут требовать более сложного процесса деинсталляции. Пример: WooCommerce, для которого вы должны поместить следующий код в ваш файл wp-config.php для полного удаления всех данных.

define("WC_REMOVE_ALL_DATA", true);

Удаление неиспользуемых шорткодов

Если вы используете плагин со своими шорткодами, и вы удалите этот плагин, ваш сайт может выглядеть странно, пока вы их не замените. Чтобы временно отключить шорткоды из старого плагина, просто используйте следующий код в своем файле functions.php. Вместо pluginshortcode задайте актуальный тег плагина.

add_shortcode("pluginshortcode", "__return_false");

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

Как вручную очистить оставшиеся таблицы

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

Очистка таблиц с помощью плагинов

Лучший плагин для этого – Advanced Database Cleaner. Плагин премиальный; он позволяет просканировать вашу установку WordPress и удалить «осиротевшие» таблицы. Как вы можете видеть ниже, он нашел таблицы EDD (wp_edd*), Gravity Forms (wp_gf*) и Bloom (et_bloom*, et_social*) от плагинов, которые уже не используются.

Очистка таблиц с помощью phpMyAdmin

Вы также можете очистить таблицы вручную с помощью phpMyAdmin. Этот метод является предпочтительным. Многие плагины именуют свои таблицы чем-то подобным своему названию. В данном примере мы полностью удалим Yoast SEO в соответствии с их документацией. На самом деле Yoast SEO не имеет такой опции, потому, если вы хотите полностью удалить плагин и все его данные, сделать это можно с помощью phpMyAdmin. В своей документации они пишут:

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

Для этого просто войдите в phpMyAdmin. Во вкладке Search введите wpseo, выберите все таблицы, после чего щелкните по Go.

На нашем сайте были найдены совпадения в таблице wp_options, wp_postmeta и wp_usermeta. Вы можете затем щелкнуть по каждой таблице и удалить строки, содержащие wpseo.

Ниже представлена таблица wp_options. Сначала отфильтруйте строки по wpseo, поскольку есть и другие строки WordPress, которые могут содержать wpseo в option_value, как строки WordPress cron задач. Это очень важно. После фильтрации вы можете выбрать строки и удалить.

Ниже представлена таблица wp_postmeta. Удалите строки, содержащие wpseo.

Наконец, ниже представлена таблица wp_usermeta. Опять же, что очень важно, вам нужно сначала отфильтровать строки по wpseo. Затем выберите строки и удалите их.

Если вы используете новую возможность счетчика текстовых ссылок, вам также придется убрать две дополнительные таблицы Yoast SEO: wp_yoast_seo_links и wp_yoast_seo_meta.

И последнее, что нужно сделать – очистить задачи Cron, если есть те, которые работают с плагином. Вы можете, конечно, отредактировать строку задачи cron в таблице wp_options, однако самый простой способ гарантировать, что ничего лишнего не удалено – воспользоваться плагином WP Crontrol . В случае с Yoast SEO используется Cron задача, названная wpseo_onpage_fetch, которую можно легко удалить.

Заключение

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

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