Параметры объекта поста WP_Post в базе данных MySQL

Архитектура базы данных Вордпресс

База данных стандартной установки Вордпресс состоит из 11 неудаляемых таблиц, которые используются Вордпресс для своей работы.

• wp_commentmeta — метаданные всех комментариев на Постах и Страницах и в кастомных видах записей.
• wp_comments — все комментарии на сайте, включая Опубликованные, Ожидающие проверки, Одобренные и Спам.
• wp_links — информация о ссылках в менеджере ссылок; эта функция сейчас редко используется, после версии 3.5 скрыта по умолчанию.
• wp_options – самая большая таблица Вордпресс, в которой хранится множество настроек, от адреса сайта до настроек Чтения и Обсуждения. В этой таблице хранят свои записи темы и плагины.
• wp_postsmeta – в этой таблице хранятся метаданные постов и страниц.
• wp_posts – хранит контент постов и страниц и данные меню и навигации.
• wp_terms – эта таблица хранит категории постов, ссылок и тегов.
• wp_term_relationships – сообщения связаны с категориями и тегами в таблице wp_terms, эти ассоциации хранятся в таблице wp_term_relationships.
• wp_term_taxonomy – хранит таксономию категорий, ссылок и тегов для записей в таблице wp_terms.
• wp_usermeta – хранит метаданные всех пользователей из таблицы wp_users.
• wp_users – в этой таблице хранятся данные о всех пользователях сайта.

В базе данных мультисайт установки Вордпресс находится еще несколько таблиц:

• wp_blogs – каждый сайт Мультисайт сети хранится здесь.
• wp_blog_versions  – хранит текущую версию базы данных каждого сайта в сети, и используется в основном для обновления Мультисайт сети. Обновляется когда обновляется каждый сайт.
• wp_registration_log – хранит информацию о пользователях на каждом сайте.
• wp_site – содержит адрес сайта.
• wp_sitemeta – эта таблица хранит разные настройки сайтов.
• wp_users – содержит данные о всех пользователях. Такая же таблица есть в одиночной установке Вордпресс, но в этой таблице есть 2 дополнительные строки: Спам и Удаленные.
• wp_usermeta – содержит метаданные каждого пользователя каждого сайта.

Кроме этих таблиц добавляются таблицы каждого подсайта в мультисайт установке, например, wp_2_commentmeta, wp_2_comments, wp_2_links и так далее. Данные основного сайта хранятся в своих основных ненумерованных таблицах.

Параметры объекта поста WP_Post в базе данных MySQL

Движки MySQL

MySQL использует разные движки для хранения и извлечения информации из таблиц базы данных. MySQL поддерживает несколько движков, самые популярные из них — MyISAM и InnoDB.

В большинстве случаев в конфигурационном файле MySQL по умолчанию установлен движок MyISAM.

Вы можете заменить движок MyISAM на InnoDB. MyISAM быстро считывает информацию. InnoDB тоже быстро считывает информацию, но записывает информацию быстрее с помощью механизма блокировки строк. Так как Вордпресс и считывает, и записывает информацию в базу данных, InnoDB будет лучшим выбором.

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

SET default_storage_engine=InnoDB;

Чтобы изменить движок только одной таблицы, используйте этот запрос:

ALTER TABLE table_name ENGINE=InnoDB;

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

Оптимизация базы данных

Одна из причин медленного сайта — неочищенная и неоптимизированная база данных.

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

Перед очисткой / оптимизацией сделайте бэкап базы данных.

Устанавливайте только те плагины, которые будете использовать

Хороший способ оптимизировать базу данных — не устанавливать плагины для тестирования на сайте. Тестируйте плагины на отдельном сайте.

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

Существует 5 видов плагинов, которые создают большое количество информации в базе данных:

• Плагины безопасности. Большинство плагинов безопасности хранят большое количество информации об атаках на ваш сайт для защиты его от будущих атак, о спаме, попытках доступа и так далее.
• Плагины статистики. Эти плагины хранят информацию о страницах, визитах, браузерах, ключевых словах и так далее.
• Анти-спам плагины. Так же как плагины безопасности, эти плагины хранят большое количество данных об IP-адресах, емейл адресах, странах и так далее.
• Плагины вывода контента. Вывод контента в тех или иных местах по тому или иному признаку, лайки и визиты страниц, и так далее. Эти плагины создают большое количество информации, лучше использовать их по минимуму.
• Мультиязычные плагины. Плагин WPML создает большое количество таблиц и записей в БД.

Старайтесь использовать плагины статистики и вывода контента как можно меньше.

Спам

Спам — еще один источник наполнения базы данных мусором. Вы можете удалить весь спам в базе данных при помощи SQL запроса:

DELETE FROM wp_comments WHERE comment_approved = ‘spam’

Или из админки Вордпресс. Зайдите в Комментарии — Спам, нажмите кнопку «Очистить спам». Перед удалением всех комментариев проверьте их, в спам могли попасть нужные комментарии.

Удаление неиспользуемых таблиц

Некоторые плагины после своего удаления не удаляют свои таблицы из базы данных. Если вы удалили плагин и не планируете снова его использовать, вы можете удалить его таблицы из БД. Для этого вы можете использовать плагин Advanced Database Cleaner или Advanced Database Cleaner Pro, или сделать это вручную.

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

Оптимизация БД вручную

У MySQL есть стандартная функция оптимизации базы данных OPTIMIZE, которая «реорганизует физическое хранилище табличных данных и связанных с ними индексных данных, чтобы уменьшить пространство для хранения и повысить эффективность ввода-вывода при доступе к таблице». В разных движках запрос optimize работает по-разному.

Вы можете оптимизировать базу данных запросом optimize в phpMyAdmin. Подробнее здесь.

Оптимизация БД при помощи плагинов

Если вы хотите, чтобы эту работу делал плагин, попробуйте WP-Optimize, это простой и популярный плагин, более 600.000 установок. Он удаляет ревизии постов, старые метаданные, черновики постов и удаленные комментарии.

13 лайфхаков для базы данных WordPress

1. Создание бэкапа вашей базы

Проблема. Хотя советы в этой статье были проверены, вам не стоит их применять на практике до создания резервной копии вашей базы MySQL (мало ли что…)

Решение. Чтобы создать вручную резервную копию вашей базы, следуйте за этими простыми шагами:

1. Для начала надо залогиниться в phpMyAdmin и выбрать там свою базу WordPress.

2. Кликните на кнопке «Экспорт» (Export), которая находится в горизонтальном меню.

3. Выберите метод сжатия данных (лично я использую gzip) и нажмите на кнопочку «Пошёл» (Execute).

4. Ваш браузер спросит хотите ли вы скачать бэкап. Разумеется скажите ему твёрдое Да и сохраните файл куда-нибудь на свой компьютер.

Примечание. Учтите, что создание резервных копий базы WordPress гораздо удобнее делать с помощью специального плагина WP-DB-Backup. Пользователи WordPress могут не задумываясь, прямо сейчас установить себе этот плагин если по каким-то причинам всё ещё этого не сделали.

2. Пакетное удаление ревизий записей

Проблема. Ревизии записей — это новая фишка WordPress начиная с версии 2.6. Она может быть очень полезной, а может также увеличить размер базы MySQL. Разумеется, вы можете вручную удалять ревизии постов с админки. Но это очень долго и нудно. Есть решение получше.

Решение. А решение проблемы очень простое: мы пакетно, то бишь всё одним махом, удаляем ревизии постов используя простой SQL-запрос. Результат может быть потрясающим, если у вас много записей. Ваша база данных может похудеть вдвое!

1. Надо залогиниться в phpMyAdmin и выбрать там свою базу WordPress.

2. Потом нажать на кнопочку «SQL». Появится окошко, в которое надо вставить следующий запрос:

DELETE FROM wp_posts WHERE post_type = "revision"

3. Вот и всё! В зависимости от количества записей, вы сэкономили кучу драгоценного времени и почистили базу.

Объяснение кода. В таблице wp_posts есть поле под названием post_type. Это поле может иметь множество значений, таких как post, page или revision. Когда мы хотим избавиться от ревизий записей, то просто запускаем команду, чтобы та удалила все значения в таблице wp_posts, в поле post_type которой стоит значение revision. Вот как.

Продвинутый вариант

Удаляем ревизии записей

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

В таблице wp_posts есть поле с названием post_type. В этом поле может встречаться один из таких параметров, как «post», «page» или «revision». Если мы хотим избавиться от редакций записей, то нужно выполнить команду удаления всех записей в таблице wp_posts, в которых поле post_type имеет параметр «revision». Ниже SQL запрос, который удалит все ревизии записей в БД и всякие связи с ними:

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'

3. Удаляем 5000 спаммерских комментариев за одну секунду

Проблема. Правдивая история: мой друг недавно открыл свой собственный блог и начал активно его пиарить по всему интернету. Через несколько недель интенсивной работы он провёл пару дней в отпуске, без сети.

Когда он вернулся домой и заглянул в свой блог… то увидел больше 5000 сообщений, которые ожидали модерации! Как быть?

Решение. К своему счастью, мой друг рассказал мне о своей проблеме с долбаными спамерами. Он уже успел потратить 45 минут на ручную проверку и удаление спама, как я показал ему очень полезный трюк:

1. Логинимся в phpMyAdmin и выбираем там свою базу WordPress.

2. Нажимаем на кнопочку «SQL». Появится окошко, в которое надо вставить следующий запрос:

DELETE from wp_comments WHERE comment_approved = '0';

3. И прощайте спамеры! Наслаждаемся чистотой и уютом…

Объяснение. В таблице wp_comments содержится поле comment_approved, в котором хранится булевое значение (1 или 0). Утверждённые комментарии имеют значение 1, а комментарии, которые ожидают модерации — 0. Вышеуказанная команда просто удаляет неутверждённые комментарии. Всё просто.

Но будьте осторожными! Хотя это решение офигенно удобное для автоматического удаления миллионов спамерских комментариев, но оно также удаляет и нормальные неутверждённые комментарии. Если вы всё ещё не используете плагин вроде Akismet, то самое время начать, чтобы предотвратить заспамление блога.

Управление комментированием

Частенько бывает нужно массово закрыть или открыть комментарии или сделать что-то еще с комментариями. Для таких манипуляций можно использовать следующие SQL запросы:

Закрыть комментарии для всех записей:

UPDATE wp_posts SET comment_status = 'closed'

Открыть комментарии для всех записей:

UPDATE wp_posts SET comment_status = 'open'

Комментирование только для зарегистрированных пользователей:

UPDATE wp_posts SET comment_status = 'registered_only'

Удаление спам комментариев

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

DELETE FROM wp_comments WHERE comment_approved = 'spam'

Если нужно удалить все не одобренные комментарии, используйте:

DELETE FROM wp_comments WHERE comment_approved = 0

Закрыть комментарии в рубрике

Вы можете закрыть комментарии для записей определенной рубрики:

UPDATE wp_posts p
    LEFT JOIN wp_term_relationships rel ON ( p.ID = rel.object_id )
    LEFT JOIN wp_term_taxonomy tax ON ( tax.term_taxonomy_id = rel.term_taxonomy_id  )
    LEFT JOIN wp_terms tm ON ( tm.term_id = tax.term_id )
SET p.comment_status = 'closed'
WHERE tm.slug = 'stat'

stat – название рубрики.

Закрыть комментирование в старых постах

Чтобы закрыть возможность оставлять комментарии для старых постов, например, опубликованных до 1 января 2010 года, используйте SQL запрос:

UPDATE wp_posts SET comment_status = 'closed'
WHERE post_date < '2010-01-01' AND post_status = 'publish'

Вы закроете все комментарии старше 2010-01-01

4. Как изменить атрибут записи

Проблема. Когда вы устанавливаете WordPress, создаётся аккаунт «admin» по-умолчанию. Некоторые блоггеры делают ошибку, используя этот аккаунт для создания своих записей, пока они не понимают, что это как-то безлико.

Решение. Модификация атрибута автора для каждой записи занимает туеву хучу времени. К счастью, SQL может нам помочь:

1. Логинимся в phpMyAdmin и выбираем там свою базу WordPress.

2. Для начала нам надо определить правильные ID пользователей. Так что нажимаем на кнопочку «SQL». Появится окошко, в которое надо вставить следующий запрос:

SELECT ID, display_name FROM wp_users;

3. phpMyAdmin отобразит список «айдишников», которые привязаны к пользователям WordPress. К слову, NEW_AUTHOR_ID это ID самого свежесозданного автора, а OLD_AUTHOR_ID это ID оригинального админского аккаунта.

4. После того как вы определили «айдишники» NEW_AUTHOR_ID и OLD_AUTHOR_ID, выполните следующую команду:

UPDATE wp_posts SET post_author=NEW_AUTHOR_ID WHERE post_author=OLD_AUTHOR_ID

5. Это всё. Все записи, которые были привязаны к аккаунту admin теперь будут собственностью того пользователя, которого вы выбрали.

5. Сброс пароля

Проблема. Чтобы защитить свои блоги, люди часто выбирают сильные пароли, такие как 7*KoF5i8_. Это, конечно, похвально, но все слышали множество историй о том как админы забывают свои пароли 🙂

Решение. Когда вы забываете свой пароль, WordPress может отправить вам ссылку для его сброса на email. Но если у вас нет доступа к мылу, которое указано в базе WordPress, или если вы считаете, что вопрос можно решить как-то иначе, то вот вам способ «взлома»:

1. Логинимся в phpMyAdmin, выбираем там свою базу WordPress и открываем окно SQL.

2. Вводим следующую команду (с учётом, что вашим логином был «admin»):

UPDATE 'wp_users' SET 'user_pass' = MD5('PASSWORD') WHERE 'wp_users'.'user_login' = 'admin' LIMIT 1;

3. Ну вот, собственно, и всё. Ваш пароль успешно обновится на тот, что вы указали в месте, помеченном как «PASSWORD».

Объяснение. Пароли пользователей хранятся в таблице wp_users. Разумеется используется хэш MD5, чтобы защитить их от просмотра.

Мы отправили SQL-запрос «UPDATE» и использовали встроенную функцию MySQL — MD5(), чтобы конвертировать наш пароль в MD5 и обновить его. Использование «WHERE» гарантирует, что мы обновили только пароль администратора. Тот же запрос, но без использования параметра «WHERE» обновит все пароли в базе!

Управление логином/паролем

Смена пароля

Иногда жизненно необходимо восстановить пароль или просто поменять его, а доступа к админ части сайта нет. Для смены пароля можно использовать такой SQL запрос:

UPDATE wp_users SET user_pass = MD5('newpass') WHERE user_login = 'admin'

newpass – новый пароль, admin – логин пользователя у которого мы изменяем пароль.

Если вдруг вы забыли логин, но точно помните, что вы были первым юзером на блоге, а значит ваш ID равен 1, то можно идентифицировать юзера для смены пароля по ID (WHERE ID=1):

UPDATE wp_users SET user_pass = MD5('newpass') WHERE ID=1;

Смена логина

По умолчанию WordPress создает 1 логин для пользователя и в дальнейшем его невозможно изменить. Это не совсем так. Логин можно поменять, используя такой SQL запрос:

UPDATE wp_users SET user_login='shef' WHERE user_login='admin'

Здесь мы меняем логин admin на shef.

6. Изменение вашего доменного имени

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

Решение.

1. Как вы уже могли догадаться: логинимся в phpMyAdmin, выбираем там свою базу WordPress и открываем окно SQL

2. Чтобы изменить URL Вордпресса, запускаем вот такую команду:

UPDATE wp_options SET option_value = replace(option_value, 'http://www.oldsite.com', 'http://www.newsite.com') WHERE option_name = 'home' OR option_name = 'siteurl';

3. Потом нам нужно заменить относительный URL (GUID) для каждой записи. Следующая команда сделает это за вас:

UPDATE wp_posts SET guid = replace(guid, 'http://www.oldsite.com','http://www.newsite.com');

4. Это почти конец. Осталось только найти и заменить абсолютные URL в таблице wp_posts table для убедительного финала:

UPDATE wp_posts SET post_content = replace(post_content, 'http://www.oldsite.com', 'http://www.newsite.com');

5. А вот это уже конец. Можете зайти в админку своего блога используя новый урл.

Меняем домен в произвольных полях

В произвольных полях также могут быть записи хранящие какие-либо url’ы на старый домен, поэтому при смене домена возможно нужно заменить домен и в произвольных полях:

UPDATE wp_postmeta SET meta_value = REPLACE (meta_value,'http://www.oldsite.com', 'http://www.newsite.com');

7. Обновить путь к изображению

Возможно, вы слышали об использовании Amazon CloudFront в качестве сети доставки контента (CDN) для разгрузки доставки изображений. После создания записи CNAME используйте приведенный ниже запрос, чтобы обновить пути к изображениям в WordPress для загрузки из Amazon CloudFront.

UPDATE wp_posts SET post_content = REPLACE (post_content, 'src = "http://www.myoldurl.com', 'src =" http://yourcdn.mynewurl.com');

Вам также необходимо обновить GUID для прикрепления изображения:

UPDATE wp_posts SET guid = REPLACE (guid, 'http://www.myoldurl.com', 'http://yourcdn.mynewurl.com') WHERE post_type = 'attachment';

8. Превратите сообщения WordPress в страницы (или страницы в сообщения)

Менять сообщения на страницы достаточно просто:

UPDATE wp_posts SET post_type = 'page' WHERE post_type = 'post'

… И если вы хотите снова изменить их:

UPDATE wp_posts SET post_type = 'post' WHERE post_type = 'page'

Чтобы изменить отдельные сообщения (страницы), вам нужно будет включить правильное поле ID в предложение WHERE.

9. Замена любого текста или ссылки в записях

Можно заменить текст в постах и сделать это прямо в Базе Данных. Например, добавить атрибут target=”blank” ко всем ссылкам с атрибутом rel=”nofollow”:

UPDATE wp_posts SET post_content = REPLACE (post_content, 'rel="nofollow"', 'target="blank" rel="nofollow"')

Вы можете изменять названия таблицы и поля соответственно на свое усмотрение:

wp_posts – таблица, post_content – поле таблицы.

Еще можно проставить внутренние ссылки с определенным анкором, например, из слова “WordPress” сделать ссылку на какую-нибудь релевантную страницу, чтобы поднять её значимость. В прочем, для этого существуют специальные плагины, которые не трогают текст в БД, а создают ссылки на лету:

UPDATE wp_posts SET post_content = REPLACE (post_content, ' WordPress ', ' <a href="http://site.ru/статья-о-wordpress">WordPress</a> ')

10. Управление произвольными полями (postmeta)

Удаляем ненужные произвольные поля

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

DELETE pm FROM wp_postmeta pm WHERE pm.meta_key = 'meta_name'

Если название произвольного поля (meta_name) в кириллице, то убедитесь, чтобы кодировка файла из которого будет производиться SQL запрос соответствовала кодировке блога (обычно UTF-8 без BOM).

Получим все произвольные поля с пустым значением

Несмотря на то, что в админке создать произвольное поле не задав ему никакое значение не получится, по крайней мере стандартными средствами, такие “пустые” произвольные поля все же могут быть в вашей Базе Данных. Например, их могут оставить там плагины или кривые руки. Чтобы посмотреть есть ли подобные поля и затем решить их судьбу, воспользуетесь SQL запросом:

SELECT *
FROM wp_postmeta pm
LEFT JOIN wp_posts wp ON wp.ID = pm.post_id
WHERE wp.ID IS NULL

или

select * from wp_postmeta where meta_value = ''

Удаляем все произвольные поля с пустым значением

DELETE pm FROM wp_postmeta pm WHERE pm.meta_value = '';

11. Деактивация всех плагинов

Бывают ситуации, когда невозможно зайти в админку сайта или сам сайт из-за одного некорректно работающего плагина. Такой плагин можно переименовать или удалить по FTP или просто деактивировать все плагины SQL запросом, что даст возможность войти в админ часть и на страницу списка плагинов:

UPDATE wp_options SET option_value = '' WHERE option_name = 'active_plugins'

12. Отображение количества SQL-запросов вашего блога.

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

Решение. Прикол: нам не надо заходить в phpMyAdmin 🙂 Надо только открыть на редактирование файл footer.php (он точно есть в вашей теме) и добавить туда вот такие строки кода:

<?php if (is_user_logged_in()) { ?>
<?php echo get_num_queries(); ?> запросов за <?php timer_stop(1); ?> секунд.
<?php } ?>

Сохраните файл и посетите свой блог. В «подвале» вы увидите количество запросов к базе Вордпресса и время, затраченное на их создание.

Примечание. Сложилось впечатление, что многие пользователи WordPress не в курсе это чудесной возможности. Функция get_num_queries() возвращает количество созданных запросов во время загрузки страницы.

Учтите, что код, приведённый выше, отображает количество запросов только залогиненым пользователям, так как гости блога и поисковые боты не обязаны знать эту информацию. Но вы можете сделать отображение публичным, просто убрав условный оператор if (is_user_logged_in()) с кода.

13. Восстановление вашей базы данных

Проблема. Скажем… по некоторым причинам, таким как взлом или проблема с обновлением, вы можете потерять данные вашего блога или обнаружить их безнадёжно испорченными. Так что если у вас есть резервная копия (правда же есть, да?), вам необходимо импортировать её в свою базу Вордпресса. И тогда всё будет хорошо. Скорее всего.

Решение.

1. Логинимся в phpMyAdmin, выбираем там свою базу WordPress.

2. Жмём на кнопку «Импорт» (Import) в горизонтальном меню.

3. Нажмите кнопку «Открыть» (Browse) и выберите самую свежую копию базы со своего диска.

4. Жмём на кнопку «Пошёл» (Execute). Если всё пройдёт удачно и боги на вашей стороне, база данных будет снова полностью функциональна.

Как отключить ревизии WordPress (Дополнительный вариант)

Последний вариант ― это просто отключить ревизии (редакции) WordPress. Наиболее часто используемым методом обычно является второй вариант, о котором упоминалось выше. Однако, если вы являетесь единственным автором, то вы можете просто полностью избавиться от ревизий.

Помните, что система все равно сохранит черновик, просто у вас уже не будет точек для восстановления редакции.

Шаг 1
Откройте файл wp-config.php. Вам нужно будет добавить код. Обычно он находится в основной папке вашего сайта WordPress, и вы можете получить к нему доступ через FTP.

Шаг 2
Строчку кода необходимо вставить над «ABSPATH».

define('WP_POST_REVISIONS', false)

Как ограничить количество ревизий WordPress

Возможно, вы хотите сохранить 3 ревизии.

WordPress сохранит этот номер и удалит все предыдущие. Вы также можете использовать wp-revisions-cli для очистки последующих ревизий на основе номера, указанного вами ниже.

Шаг 1
Алгоритм действий такой же, как и при ограничении количества ревизий (см. выше). Откройте файл wp-config.php.

Шаг 2
Строчку кода необходимо вставить так же над «ABSPATH».

define ('WP_POST_REVISIONS', 3);

Замените 3 на нужное количество, -1 если вы хотите сохранять все ревизии и 0, если хотите выключить ревизии вообще, кроме автосохранения.