Хостинг пишет, что база данных переполнена, в phpMyAdmin таблица с постами пугает тысячами строк, а слово «ревизии» кажется чем-то для программистов. Марина ведёт блог: каждый текст правит по десять раз, нашла в форуме совет про wp-config, вставила строку не туда — лимит не сработал, а лишняя запятая на секунду выдала белый экран. Ниже — спокойный порядок: бэкап, одна строка с лимитом ревизий WordPress, проверка в редакторе и отдельный план, если старый «хвост» в базе уже накопился. К концу вы сможете настроить лимит и увидеть понятный результат в редакторе — без phpMyAdmin в первый вечер.
Лимит в wp-config ограничивает только новые версии записей: строка define( ‘WP_POST_REVISIONS’, 5 ); выше комментария «That’s all, stop editing» хранит примерно пять последних правок на пост. Автосохранение в редакторе — другое: на пользователя и запись остаётся одно актуальное автосохранение, база не пухнет каждые 60 секунд. Уже лежащие ревизии сами не исчезнут — их чистят отдельно, после резервной копии.
Ревизии — это история правок: WordPress кладёт каждую сохранённую версию записи в ту же таблицу, что и обычные посты, со служебным типом revision. Для владельца услуг или блога это удобно, пока правок мало; когда тексты переписывают месяцами, растёт размер базы, дольше идут бэкапы, хостинг начинает ругаться. Честно: главный выигрыш от лимита — размер БД и спокойствие при копировании, а не мгновенное ускорение страницы для посетителя.
- Разберите, откуда берётся «лишний вес» базы, не открывая SQL в первый же день
- Сравните: отключить ревизии, поставить число или оставить как есть
- Подготовьте бэкап и вставьте лимит ревизий в wp-config без белого экрана
- Проверьте, что лимит ревизий WordPress сработал, без phpMyAdmin
- Уберите старый хвост ревизий, если размер базы не упал сразу после лимита
- Как поймёте, что всё настроено правильно
- Что дальше
- Частые вопросы
- Сколько ревизий оставлять на WordPress-сайте?
- Можно ли ограничить ревизии без правки wp-config?
- Почему после лимита размер базы не уменьшился?
- Влияют ли ревизии на скорость сайта для посетителей?
- Чем лимит ревизий отличается от полного удаления старых версий?
- Можно ли полностью отключить ревизии значением false?
Разберите, откуда берётся «лишний вес» базы, не открывая SQL в первый же день
Представьте Google Docs с историей версий: каждый раз, когда вы жмёте «Обновить» в редакторе WordPress, ядро может сохранить ещё одну ревизию. По умолчанию лимита нет — версий копится сколько угодно. В справке WordPress это называют неограниченным хранением: константа WP_POST_REVISIONS по сути включена «на всё». Для салона с десятком страниц это терпимо; для блога с сотнями постов и десятками правок на текст — нет.
На практике проблему видят в письме хостинга или в размере MySQL в панели. Типичная ошибка — списать всё на картинки и не вспомнить про ревизии. Для старта не обязательно лезть в phpMyAdmin: сначала лимит на будущее, потом при необходимости смотрите таблицу wp_posts с типом revision.
| Что растёт в базе | Зачем нужно | Что делать новичку |
|---|---|---|
| Ревизии записей | Откат к прошлой версии текста | Ограничить число через wp-config (3-5 штук) |
| Автосохранение (autosave) | Не потерять черновик при сбое вкладки | Не отключать ради места — хранится одна копия на пользователя |
| Старый хвост ревизий | Накопилось до лимита | Очистка плагином после полного бэкапа |
Сравните: отключить ревизии, поставить число или оставить как есть
В файле wp-config.php одна строка define задаёт политику. Значение false или 0 отключает ревизии, но автосохранение в редакторе остаётся — это разные механизмы. Число 3, 5 или 10 говорит ядру: храни не больше N версий на запись; при следующем сохранении лишние старые удаляются. true или отсутствие строки — снова «без потолка».
Рекомендация для блога и сайта услуг: не ноль, а около 3-5 последних ревизий — так можно откатить вчерашний абзац, но база не раздувается бесконечно. Полное отключение — крайний случай, когда вы готовы потерять откат и жить только с автосохранением.
Вердикт: для Марины с частыми правками постов разумнее define( ‘WP_POST_REVISIONS’, 5 );, чем «вырубить всё» или надеяться на плагин без лимита в конфиге.
Подготовьте бэкап и вставьте лимит ревизий в wp-config без белого экрана
Страх «сломать сайт» при правке wp-config обычно снимается копией файла и базы. Скачайте wp-config.php через файловый менеджер хостинга или FTP, сохраните копию на компьютер. Сделайте резервную копию базы: кнопка в панели хостинга или плагин вроде UpdraftPlus — подробный разбор в гайде по автобэкапу WordPress. Только после этого открывайте конфиг на редактирование.
- Найдите в корне сайта файл wp-config.php и откройте его в редакторе хостинга (не в Word) — важны кавычки и точка с запятой в конце строки.
- Найдите комментарий That’s all, stop editing! Happy publishing — новую строку вставляйте выше этого блока, не под ним: иначе лимит часто «не видят».
- Добавьте одну строку: define( ‘WP_POST_REVISIONS’, 5 ); — число можно заменить на 3, если правок мало.
- Сохраните файл и откройте главную сайта в браузере: если видите белый экран, верните скачанную копию wp-config и проверьте, нет ли лишней запятой или опечатки в define.
- Зайдите в админку, откройте любую запись в черновике и сделайте пару мелких правок с обновлением — убедитесь, что сайт живой.
- Запишите в блокнот число N из define — при проверке ревизий вы будете сравнивать список версий с этим лимитом.
В реальном проекте ломают синтаксис: копируют define из форума с «умными» кавычками или ставят строку после stop editing. Типичная ошибка Марины — именно место вставки, а не сама идея лимита.
Строка для вставки (скопируйте как есть, латинские кавычки):
define( ‘WP_POST_REVISIONS’, 5 );
Проверьте, что лимит ревизий WordPress сработал, без phpMyAdmin
Официальная документация уточняет: при лимите N хранится N ревизий плюс служебное автосохранение на пользователя — не путайте счётчик в интерфейсе с «каждую минуту новая строка в базе». Проверка для новичка — в редакторе, а не в SQL.
- Создайте тестовую запись или откройте черновик, который не жалко.
- Сохраните одну и ту же запись 6-7 раз подряд с мелкими изменениями текста (добавьте слово, обновите).
- Откройте блок «Ревизии» в боковой панели редактора (в WordPress 7.0 экран обновлён — ищите пункт про версии записи; на 6.x — классический список).
- Убедитесь, что полный бесконечный хвост не копится: остаётся примерно ваше число N плюс автосохранение.
- Попробуйте откатиться на предыдущую ревизию и снова обновить — сайт должен открываться, текст меняется предсказуемо.
Если счётчик не меняется, проверьте wp-config: строка выше stop editing, без второго define с другим числом.
Уберите старый хвост ревизий, если размер базы не упал сразу после лимита
Это главная ловушка из обсуждений на wordpress.org: лимит влияет на будущие сохранения, а тысячи строк, накопленные годами, остаются, пока их не удалят. Марина после правки конфига справедливо удивилась: письмо хостинга всё ещё красное. Решение — не самодельный DELETE в phpMyAdmin для новичка, а плагин обслуживания базы после свежего бэкапа.
Установите плагин очистки ревизий из каталога wordpress.org, отметьте только revision, не трогайте черновики без понимания, запустите уборку после бэкапа. Подробнее — очистить ревизии WordPress. Цепочка: бэкап → define в wp-config → тест в редакторе → плагин → размер в панели хостинга.
Схема без паники: резервная копия → лимит в конфиге → 7 правок тестового поста → плагин чистит старые revision → размер MySQL в панели хостинга
Как поймёте, что всё настроено правильно
Практический результат за один вечер: в wp-config есть define( ‘WP_POST_REVISIONS’, N ); выше stop editing. После серии сохранений одной записи список версий не растёт бесконечно. Вы помните, что старый хвост чистится отдельно, а автосохранение в редакторе не отключаете ради места — оно одно на пользователя, не тысячи строк в минуту. Откат к недавней версии текста остаётся в пределах N — и вы сможете повторить цепочку на любом посте без страха «сломать базу».
Что дальше
- Очистить ревизии WordPress — когда лимит уже стоит, а база тяжёлая.
- Автоматический бэкап — до правки wp-config и чистки.
- Другие инструкции по сайту — в разделе статьи блога.
Если phpMyAdmin пугает, белый экран после правки конфига или хостинг уже в «красной зоне» по месту — поможем настроить лимит и безопасную чистку при создании и продвижении сайтов. Опишите хостинг и что видите в панели через форму на сайте или в Telegram — пишем в мессенджер, звонить не нужно.
Материал проверен: Андрей Дикий — создаёт сайты и продвигает их статьями (SEO/GEO).
На что опирается текст: документация WordPress.org (Revisions, wp_revisions_to_keep), русская справка editing wp-config.php и revisions, wp-kama.ru (revision), DreamHost (практика 3-5 ревизий и AUTOSAVE_INTERVAL), обсуждение limit-revisions на wordpress.org/support; LSI-кластер из SERP 2026-09-28 (Яндекс Вордстат MCP недоступен, точные показы не верифицированы).
Частые вопросы
Сколько ревизий оставлять на WordPress-сайте?
Для блога и сайта услуг обычно хватает 3-5 последних версий: можно откатить недавнюю правку, но база не копит десятки копий каждого поста. Ноль имеет смысл только если вы осознанно отказываетесь от отката.
Можно ли ограничить ревизии без правки wp-config?
Да, часть плагинов позволяет задать лимит в настройках, но строка define в конфиге — самый прямой и прозрачный способ, который не зависит от лишнего плагина. В любом случае сначала бэкап файла и базы.
Почему после лимита размер базы не уменьшился?
Константа действует на новые сохранения: старые ревизии остаются в таблице posts, пока вы их не удалите плагином или обслуживанием БД после резервной копии. Это ожидаемое поведение, а не «сломанный лимит».
Влияют ли ревизии на скорость сайта для посетителей?
Главный эффект — размер базы, время бэкапа и лимиты хостинга. Скорость открытия страницы для клиента от числа ревизий обычно страдает косвенно и слабее, чем от тяжёлых картинок или лишних плагинов.
Чем лимит ревизий отличается от полного удаления старых версий?
Лимит — правило на будущее: при каждом обновлении ядро держит не больше N версий. Удаление старого хвоста — разовая уборка уже накопленного. Нужны оба шага, если база раздута годами правок.
Можно ли полностью отключить ревизии значением false?
Технически да, define( ‘WP_POST_REVISIONS’, false ); отключает именованные ревизии, но автосохранение в редакторе остаётся. Вы теряете удобный откат к вчерашнему тексту — для контентного блога чаще выбирают число 3-5, а не false.
