WordPress не сохраняет запись: ошибка допустимого JSON

Сообщение WordPress «Обновление не удалось. Ответ не является допустимым JSON» при сохранении записи требует проверки конкретного ответа на запрос редактора. Сначала сохраните набранный текст отдельно, затем посмотрите URL, статус и тело ответа. Отключение всех плагинов на рабочем сайте не должно быть первым действием.

Не потеряйте материал, пока ищете причину

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

Не обновляйте вкладку с единственной несохранённой версией ради исчезновения ошибки. Сначала зафиксируйте, что было изменено и какой результат ожидается: черновик, обновление существующего материала или публикация. Здесь речь о сохранении записи, а не обязательно о неудачном обновлении ядра WordPress.

JSON — это содержимое ответа, а не имя кнопки

Редактору нужен ответ в ожидаемом формате. Если вместо него приходит страница входа, блокировка или посторонний вывод, разбор может не пройти. В документации MDN для Response.json ошибка SyntaxError связывается с невозможностью разобрать тело как JSON.

Но сама эта фраза не называет виновный плагин и не доказывает поломку базы. Более того, сообщение об ошибке в интерфейсе ещё не устанавливает окончательное состояние операции. До повторной публикации проверьте, не сохранились ли изменения уже: повторный запрос не всегда нужен для восстановления понятного статуса.

Исследуйте именно запрос сохранения

В сетевой панели браузера выделите обращение, которое относится к нажатой кнопке. Сохраните его URL без секретных данных, метод, время, HTTP-статус, Content-Type и безопасное описание тела ответа. Если обращение перенаправлялось, укажите, куда оно пришло в конце.

Не копируйте всю вкладку заголовков в публичное сообщение: там могут быть cookie, nonce и другие сведения доступа. Для поддержки WordPress обычно полезнее указать наблюдение «получена страница входа», чем прикладывать чужую авторизованную сессию. Полный материал для диагностики передают только уполномоченному специалисту.

Как читать неожиданный ответ

Это собственные сценарии диагностики, а не результаты проверки реального сайта. Строки не определяют точный статус для всех случаев: его нужно получить из конкретного ответа. Синтаксически корректный JSON также не равен успешному сохранению — внутри может быть предусмотренное сообщение об отказе.

Сессия редактора и авторизация REST

В документации WordPress об аутентификации REST API описана связь cookie-аутентификации с nonce и необходимыми полномочиями пользователя. Если nonce не передан, запрос в описанном механизме становится неаутентифицированным даже при входе в WordPress. Поэтому наличие открытой админки не закрывает проверку отдельного обращения.

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

Адрес API мог получить чужую обработку

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

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

Проверка изменения в безопасной области

1. Сохраните несохранённый материал и исходные наблюдения запроса.
2. Выберите подтверждённую ветвь по содержимому ответа, а не только общей фразе интерфейса.
3. Подготовьте копию или согласованный ограниченный сценарий проверки без реальных заказов.
4. Измените одну относящуюся к гипотезе настройку или компонент и сравните тот же запрос.
5. Проверьте фактически сохранённую запись отдельно от сообщения редактора.

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

Критерии успешного сохранения

Проверьте, что ожидаемый текст и настройки появились у нужной записи в правильном состоянии. Не публикуйте черновик только ради проверки публичной страницы. Если задача заключалась в обновлении существующей записи, убедитесь, что изменён именно выбранный материал, а не создана вторая копия.

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