Самый безопасный способ массового удаления ревизий постов

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

Я уже установил конфигурацию Wordpress, чтобы ограничить количество ревизий в будущем двумя:

define('WP_POST_REVISIONS', 2);

Но я хочу удалить все существующие ревизии.

Вопрос 1 : Безопасно ли напрямую удалять все строки в таблице wp_posts, которые имеют ревизию post_type? (Я видел противоречивые ответы на этот вопрос - но я бы хотел просто сделать это таким образом, если это безопасно).

Вопрос 2 : … и это только уместно, если я НЕ должен просто сделать прямое удаление из вопроса один:

Я нашел этот ответ, где songdogtech предоставляет запрос к базе данных для безопасного удаления, но (1) он специально предназначен для ответа на многосайтовый вопрос (это отдельный сайт) и (2) я только что обновил сайт до 3.6, который включал изменения базы данных , (Итак, я не достаточно опытен в чтении запросов к базе данных, чтобы точно знать, что там происходит, и будет ли это работать для одного сайта в WP 3.6

Безопасно ли напрямую удалять все строки в таблице wp_posts, которые имеют ревизию post_type? (Я видел противоречивые ответы на этот вопрос - но я бы хотел просто сделать это таким образом, если это безопасно)

Безопасно, это безопасно .

Если есть только один пользователь (вы), который может редактировать сообщения на сайте, это безопасно и не вызывает никаких других проблем.

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

Что абсолютно небезопасно, так это запускать SQL-запрос к базе данных WP без создания одной (или лучше, более) доступной резервной копии (ей) и предварительного тестирования запроса в локальной среде / dev.

Давайте представим, что вы случайно напечатали «post» вместо «revision» , если у вас нет резервных копий и вы выполняете запрос на производственном сайте, что происходит?

Что касается второго вопроса, то просто удалите {id}_везде появляется в запросе Написал так wp_{id}_postsбудет wp_postsи так далее.

Предупреждение , то wp_часть стандартного префикса таблицы, что крутые парни изменить на что - то другое во время установки WP.

Если вы изменили его и wp_config.phpвы видите$table_prefix = 'something_else_than_wp_';

Ваш запрос становится:

DELETE a,b,c
FROM something_else_than_wp_posts a
LEFT JOIN something_else_than_wp_term_relationships b ON (a.ID = b.object_id)
LEFT JOIN something_else_than_wp_postmeta c ON (a.ID = c.post_id)
WHERE a.post_type = 'revision'

Я предлагаю действовать так:

1. Резервное копирование базы данных
2. Сделайте резервную копию базы данных снова
3. Проверьте резервную копию, восстановив базу данных в другой базе данных.
4. Измените ваш wp_config, чтобы использовать эту новую базу данных
5. Запустите запрос к новой базе данных и убедитесь, что что-то идет не так
6. Если нет, то вы закончили. Если это так, измените wp_config еще раз, и пусть он использует старую базу данных и попытается исследовать проблему.

Детали, представленные к настоящему моменту, в лучшем случае неполные, и запрос a, b, c не является хорошим - потенциально даже опасным. Он забывает учитывать множество потенциальных зависимостей. Существует полное обсуждение и лучше запросов здесь

Также есть пересмотренная версия запроса, которая должна быть намного лучше, но тестировать в среде разработчиков с низким уровнем риска и резервном копировании:

В частности:

DELETE a,b,c
FROM wp_posts a
LEFT JOIN wp_term_relationships b ON ( a.ID = b.object_id)
LEFT JOIN wp_postmeta c ON ( a.ID = c.post_id )
LEFT JOIN wp_term_taxonomy d ON ( b.term_taxonomy_id = d.term_taxonomy_id)
WHERE a.post_type = 'revision'
AND d.taxonomy != 'link_category';

Этот запрос обрабатывает более старые данные, где WordPress может использовать один и тот же object_id в таблице wp_term_relationships как для публикации, так и для ссылки. Запустив другие версии этого запроса a, b, c, вы также можете непреднамеренно удалить данные ссылки. Это не такая большая проблема с более новыми установками WordPress.

Если вы запускаете эту версию запроса и получаете 0 удалений, это просто означает, что в вашей таблице wp_term_taxonomy нет записей 'link_category'. Вы можете проверить, проверив эту таблицу, а затем просто удалите последнюю строку и снова выполните запрос.

Но убедитесь, что вы выполняете резервное копирование, тестирование и проверку результатов, прежде чем использовать их на рабочих данных. Этот запрос занял одну из моих раздутых таблиц wp_posts с 300 МБ до 5 МБ после оптимизации.

Запустите SQL-запрос:

DELETE FROM wp_posts WHERE post_type = "revision" // for "wptest" DB, note the table name

ПРИМЕЧАНИЕ. Приведенный выше запрос «просто удаляет сообщение, помеченное как ревизия. Если по какой-то причине вы связали ревизию с тегом или категорией, которая была удалена при публикации окончательной публикации, у вас будут дополнительные записи в других таблицах, таких как термины ». Правильный запрос для безопасного удаления всех ваших ревизий выглядит следующим образом (при необходимости измените префикс таблицы):

DELETE a,b,c FROM wp_posts a LEFT JOIN wp_term_relationships b ON (a.ID = b.object_id) LEFT JOIN wp_postmeta c ON (a.ID = c.post_id) WHERE a.post_type = 'revision'