WordPress не сохраняет настройки: причины и способы исправления

Почему настройки не сохраняются

Сохранение в админке — это короткая цепочка: браузер отправляет POST-запрос в админку WordPress, ядро проверяет nonce и права пользователя, затем вызывает update_option() или обработчик конкретного плагина, который пишет значение в таблицу wp_options. Ломается любое из этих звеньев.

Частые причины, в порядке вероятности:

• max_input_vars. PHP по умолчанию принимает максимум 1000 переменных в одном POST-запросе. На больших страницах настроек запрос обрезается — молча, без ошибки.
• Ошибки AJAX/REST при сохранении. Блокируется неверный запрос: 403 — nonce или права, 500 — фатальная ошибка PHP, 413 — превышен размер тела. Браузер показывает «сохранено», а данные не доезжают.
• Web Application Firewall и ModSecurity. На shared-хостингах фаервол режет большие формы (WooCommerce, Elementor, ACF) без явной ошибки WordPress.
• Кэш. Некорректно работающий объектный кэш (Redis, Memcached) отдаёт старые значения из памяти. Full-page кэш влияет на фронтенд и редко мешает сохранять в админке.
• Плагин или тема перехватывает сохранение. cron-задача, синхронизация с внешним сервисом или security-плагин откатывают изменённое.
• Права на файлы. Некоторые инструменты пишут настройки в wp-config.php или .htaccess — без прав на запись ничего не меняется.

Как исправить

Шаг 1. Проверьте ошибки AJAX/REST в консоли браузера

Откройте страницу настроек и нажмите «Сохранить», не закрывая DevTools (F12 → вкладка Network). Посмотрите статус POST-запросов:

• 403 — неверный или просроченный nonce. Помогает: обновить страницу (сгенерировать свежий nonce), отключить security-плагины, проверить кэш WP Rocket и других оптимизаторов, которые генерируют страницу с чужим nonce.
• 401 — проблема с авторизацией: не передаются cookies, истекла авторизация или есть конфликт домена/HTTPS.
• 500 — фатальная ошибка PHP. Посмотрите журнал ошибок хостинга: файл обычно public_html/wp-content/debug.log или лог в панели.
• 413 — превышен лимит тела запроса на сервере (например, client_max_body_size в Nginx, LimitRequestBody в Apache или post_max_size в PHP).

Шаг 2. Поднимите max_input_vars

Если теряются поля в конце большой формы — это лимит переменных. Порог 1000 исчерпывается на страницах с большим набором полей: SEO-плагины (Yoast, Rank Math), конструкторы страниц (Elementor), кастомные поля (ACF), страницы тем и WooCommerce с большим числом атрибутов.

# Проверка текущего лимита
php -r 'echo ini_get("max_input_vars");'

Увеличьте в php.ini или в панели хостинга:

max_input_vars = 5000

После изменения перезапустите PHP-FPM и повторите сохранение.

Отдельно проверьте лимиты размера POST на уровне сервера: post_max_size в PHP, client_max_body_size в Nginx и LimitRequestBody в Apache. Если какой-то из них меньше объёма формы — запрос режется до обработки WordPress. Это не путать с max_input_vars: он ограничивает количество переменных, а не размер.

Шаг 3. Проверьте WAF и ModSecurity

Web Application Firewall (Cloudflare, панель хостинга, cPanel ModSecurity) может блокировать POST-запросы с большими данными — часто без видимой ошибки в WordPress. Признак: сохранение проходит на локальной копии сайта, а на проде — нет, а в Network виден 403 от фаервола.

Что сделать: временно отключите WAF на страницу настроек или добавьте сайт в исключение, проверьте логи WAF на время блокировки. На время диагностики достаточно переключить правила на observe-режим у хоста.

Шаг 4. Исключите кэш

Объектный кэш (Redis, Memcached) может хранить значения опций в памяти — не все обязательно кэшируются, WordPress сам решает, что класть в object cache. При нормальной настройке кэш инвалидируется после update_option(). Проблема возникает при неправильном drop-in object-cache.php, нескольких серверах без общего кэша или повреждённых данных.

# WP-CLI: сброс объектного кэша
wp cache flush

Full-page кэш редко мешает сохранить настройки, но может показывать старый фронтенд после изменения. Для проверки фронтенда после изменения настроек используйте окно инкогнито: оно исключает сохранённые cookies и локальный кэш браузера, хотя HTTP-кэш на стороне сервера может действовать. Для самой страницы настроек важнее проверить значение через базу или WP-CLI.

Шаг 5. Проверьте права на файлы

Сам WordPress хранит настройки в wp_options, но в wp-config.php и .htaccess могут писать отдельные инструменты: плагины кэша (например, через константу WP_CACHE), хостинговые панели, мастера установки, конфигураторы Redis и другие инструменты. Если файл неперезаписываем — правки не проходят. Для стандартных настроек WordPress права на wp-config.php обычно не имеют значения, так как они хранятся в базе.

# Проверка владельца и прав
ls -la wp-config.php

На shared-хостинге чаще всего встречается 644. Для WordPress хостинговых панелей это норма. Более строгий вариант безопасности — 600 или 640, если сервер позволяет. Не ставьте 777 ради фикса: это дыра в безопасности.

Шаг 6. Проверьте таблицу wp_options

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

# WP-CLI: проверка таблиц
wp db check
# ремонт при ошибках (эквивалент WP_ALLOW_REPAIR в браузерном режиме)
wp db repair

wp db repair через WP-CLI доступен без конфигурации. Для браузерного ремонта (/wp-admin/maint/repair.php) в wp-config.php нужна константа define('WP_ALLOW_REPAIR', true);.

Редкий случай — автозагрузка опций. Большой объём autoload-данных (десятки тысяч строк autoload = yes) в редких случаях может привести к ошибкам памяти или таймаутам во время загрузки страниц настроек — не к прямому отказу сохранения.

Проверка результата

После каждого шага повторяйте тест: измените любую тестовую настройку (например, название сайта), сохраните и проверьте результат через базу данных или WP-CLI:

# Значение из wp_options напрямую
wp option get blogname

Значение в БД новое, а на странице старое — кэш. Значение в БД старое — проблема с записью, двигайтесь дальше по шагам.

Когда эти способы не сработают

• Конфликт плагинов. Один из плагинов перехватывает update_option или откатывает значения. Проверка: отключите все плагины, сохраните, включайте по одному, пока не найдёте виновника.
• Тема блокирует сохранение. Бывает с конструкторами. Проверьте на актуальной стандартной теме WordPress (например, Twenty Twenty-Four): сохранилось — дело в вашей теме.
• Кастомный код. Хуки pre_update_option и sanitize_option могут переписывать значения. Без чтения кода не обойтись.
• Синхронизация с внешним сервисом. Плагин получает настройки из CRM, агрегатора или конфигуратора и затирает локальные значения. Обычно это видно в логах плагина.
• Ограничения хостинга. Некоторые провайдеры блокируют POST-запросы правилами безопасности или лимитами PHP/Apache/Nginx. Симптом: проблема проявляется только на конкретном сервере — локальная копия работает, прод не сохраняет. Прямая дорога — лог ошибок хостинга или тикет поддержке.

Сопровождение и поддержка сайта

Исправлю ошибки WordPress, восстановлю сайт.

от 5.400 ₽/мес

Подробнее

Техническая оптимизация

Ускорю сайт, настрою кэш, устраню узкие места.

7.200

Подробнее