EL-Script

General IT knowledge base

WordPress не сохраняет настройки или записи: кеш, права файлов и REST API

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

Коротко: WordPress не сохраняет настройки: Очистите кеш браузера и плагинов кеширования, проверьте права папок (755) и файлов (644), убедитесь, что REST API отвечает по адресу /wp-json/ без ошибок. Если сохранение всё ещё не работает, временно отключите все плагины и включите стандартную тему — это выявит конфликтующие расширения.

WordPress не сохраняет настройки или записи — ситуация, которая ставит в тупик даже опытных владельцев сайтов. Обычно корень проблемы прячется в кеше, неверных правах доступа к файлам или сбоях REST API. Разберём, как быстро локализовать и устранить каждый из этих факторов.

Основные причины

Причина Что это значит
Кеш браузера и плагинов кеширования Кешированные версии страниц подменяют актуальные данные при сохранении, возвращая старые значения. Плагины вроде WP Super Cache или W3 Total Cache агрессивно сохраняют копии, мешая обновлению.
Неправильные права файлов и папок Слишком строгие или слишком открытые права CHMOD препятствуют записи. Для WordPress оптимальны 755 для директорий и 644 для файлов.
Блокировка REST API WordPress использует REST API для сохранения через AJAX; если /wp-json/ недоступен или возвращает ошибку 403/404, сохранение прерывается. Блокировка может идти от .htaccess, фаервола или модулей безопасности.
Конфликт плагинов безопасности Плагины Wordfence, iThemes Security, All In One WP Security могут блокировать легитимные AJAX-запросы сохранения, особенно при активных настройках защиты от CSRF.
Ошибки в файле .htaccess Некорректные правила редиректа или блокировки доступа к wp-admin обрывают AJAX-запросы до завершения операции.
Недостаток PHP-памяти WordPress требуется достаточный объём памяти для обработки сохранения; при урезанном лимите процесс обрывается молча, без сообщения об ошибке.
Блокировка на уровне хостинга (mod_security) Правила mod_security на стороне сервера могут ошибочно считать JSON-тело запроса вредоносным и блокировать его.
Повреждение базы данных Сбои в таблицах wp_options или wp_posts препятствуют записи изменений. Часто требуют восстановления через phpMyAdmin или инструменты хостинга.

Что проверить сначала

  • Откройте консоль браузера (F12) и посмотрите ошибки JavaScript при попытке сохранить запись или настройки.
  • Проверьте доступность REST API: перейдите по адресу ваш-сайт.ру/wp-json/ — в ответе должен быть валидный JSON без ошибок.
  • Включите режим отладки WordPress: добавьте в wp-config.php строки define('WP_DEBUG', true); define('WP_DEBUG_LOG', true); и изучите лог /wp-content/debug.log.
  • Проверьте права доступа на папки (755) и файлы (644) через файловый менеджер хостинга или FTP-клиент.
  • Очистите кеш всех активных плагинов кеширования и браузера, затем попробуйте сохранить в режиме инкогнито.
  • Деактивируйте плагины безопасности на время теста и повторите сохранение.
  • Переключите тему на стандартную (Twenty Twenty-Three) и проверьте, сохраняются ли настройки с полностью отключенными плагинами.
  • Проверьте, не блокирует ли CDN или облачный WAF (например, Cloudflare) запросы к REST API через правила кеширования.

Пошаговое решение

  1. Очистите кеш браузера полностью и перезапустите его, либо протестируйте сохранение в приватном окне.
  2. В админке WordPress перейдите в настройки плагина кеширования и выполните его полную очистку; если эффекта нет — временно отключите плагин.
  3. Исправьте права через терминал или FTP: папки — chmod 755, файлы — chmod 644, особые файлы вроде wp-config.php — 600.
  4. Проверьте REST API: откройте в браузере https://ваш-сайт/wp-json/wp/v2/settings — вы должны увидеть JSON без сообщений об ошибке; если доступа нет, пересмотрите .htaccess.
  5. Восстановите стандартный .htaccess: удалите всё между # BEGIN WordPress и # END WordPress, затем перейдите в Настройки > Постоянные ссылки и нажмите «Сохранить изменения» для пересоздания файла.
  6. Увеличьте лимит памяти PHP: в wp-config.php перед строкой «/* That's all, stop editing! */» добавьте define('WP_MEMORY_LIMIT', '256M');.
  7. Деактивируйте все плагины и переключитесь на тему Twenty Twenty-Three; если сохранение заработало, включайте плагины по одному, чтобы выявить конфликт.
  8. При использовании Cloudflare создайте правило для пути */wp-json/* с уровнем кеша Bypass (пропуск кеширования).
  9. Проверьте mod_security на хостинге: временно добавьте в .htaccess строку SecFilterEngine Off (работает не на всех серверах, предпочтительно обратиться в поддержку).
  10. Через phpMyAdmin выполните проверку и восстановление таблиц WordPress (всех с префиксом wp_): выберите их и примените операцию «Восстановить таблицу».
  11. Обновите nonce-значения: обновите страницу настроек несколько раз или выйдите и снова войдите в админку.
  12. Если ничего не помогло, сделайте резервную копию и переустановите WordPress через меню «Обновления» без удаления данных.
AI-инструмент

Проверить ошибку WordPress

Введите ошибку WordPress, PHP, плагина, темы, REST API или кратко опишите проблему сайта.

FAQ

Почему WordPress не сохраняет только определённые настройки (например, URL-адрес сайта)?

Часто причина в кеше браузера или строгих правах на wp-config.php. Проверьте права доступа к файлам и очистите кеш браузера, затем повторите попытку в режиме инкогнито.

Может ли плагин кеширования полностью заблокировать сохранение записей?

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

Как быстро понять, проблема на моей стороне или на сервере?

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

После смены прав файлов WordPress выдал ошибку 500. Что делать?

Вероятно, вы установили слишком жёсткие права. Верните 755 для папок и 644 для файлов, проверьте владельца файлов через панель хостинга — он должен совпадать с серверным пользователем.

Нужно ли менять права на папку wp-content/uploads?

Обычно папка uploads уже имеет права 755, что достаточно для записи. В редких случаях может потребоваться 775, но сначала проверьте совпадение владельца файлов и корректность прав через хостинг.

Итог

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *