Кратко — скорее всего проблема не в самом WordPress в целом, а в конкретном содержимом/метаданных этой страницы (или в том, как на неё сработал какой‑то плагин/тема). Ниже — пошаговая диагностика и способы исправить.
1) Включите отладку и посмотрите ошибки
- В wp-config.php временно добавьте/включите:
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
(или временно true для WP_DEBUG_DISPLAY, чтобы видеть ошибку прямо в браузере).
- Попробуйте снова открыть страницу редактирования и посмотрите wp-content/debug.log и лог PHP/веб‑сервера (apache/nginx/php‑fpm). Ошибка в логе часто сразу показывает причину (fatals, uncaught exception, mod_security и т.п.).
2) Посмотрите ответ сети и консоль браузера
- Откройте DevTools → Network и посмотрите ответ, который возвращает /wp-admin/post.php?post=ID&action=edit (HTTP 500? содержимое ошибки?). В консоли — JavaScript ошибки (особенно если Gutenberg ломается).
3) Проверьте плагины и тему ещё раз «чистой» конфигурацией
- Отключите все плагины и временно переключитесь на дефолтную тему (Twenty Twenty‑One/Two). Вы писали, что отключали плагины — сделайте это полностью + смените тему, чтобы исключить влияние темы.
- Если с чистой конфигурацией страница открывается, включайте плагины по одному, чтобы найти виновника.
4) Проверьте содержимое этой страницы в базе данных
- Подозрение на «битый» контент (невалидный сериализованный массив, очень большой блок данных конструктора, сломанный шорткод), который вызывает фатальную ошибку при обработке.
- Получить содержимое через phpMyAdmin / Adminer / wp-cli:
SELECT ID, post_content FROM wp_posts WHERE ID = <ID_страницы>;
- Проверьте наличие длинных/странных мета‑полей (wp_postmeta) — особенно данные конструкторов: elementor, wpb, _et_pb etc.
5) Восстановите старую ревизию или замените содержимое
- Если в базе есть ревизии:
SELECT ID, post_date, post_content FROM wp_posts WHERE post_parent = <ID> AND post_type = 'revision' ORDER BY post_date DESC;
- Можно скопировать старое post_content в текущее (через SQL или wp‑cli):
UPDATE wp_posts SET post_content = '…безопасный контент…' WHERE ID = <ID>;
- Или через wp‑cli:
wp post update <ID> --post_content='…'
6) Попробуйте создать дубликат страницы
- Создайте новую страницу и копируйте содержимое по частям (binary search) — таким образом найдёте конкретный блок/шорткод, который ломает редактор.
7) Проверьте метаданные конструктора страниц
- Если на странице использовался Elementor / Visual Composer / WPBakery / Divi и т.п., проверьте связанные мета (_elementor_data, vc_grid_data и пр.). Иногда сохранённые данные повреждаются — удаление мета (временно) позволит открыть редактор.
8) Увеличьте ресурсы PHP
- Увеличьте memory_limit (256M/512M), max_input_vars и max_execution_time — иногда при больших страницах редактор «умирает» из‑за памяти.
9) Проверьте серверную защиту
- Если хост использует mod_security или WAF, запросы редактора могут блокироваться. Посмотрите логи безопасности хоста.
10) Временное обходное решение
- Откройте страницу через REST API и правьте raw HTML: GET /wp-json/wp/v2/pages/<ID>, затем POST с обновлением. Или используйте Quick Edit, если он работает.
Если хотите, помогу дальше — пришлите:
- Сообщения из wp-content/debug.log или из лога PHP/веб‑сервера после воспроизведения;
- ID проблемной страницы или её содержимое (или часть, где подозреваете шорткод/конструктор);
- Список активных плагинов и тема (включая версии) и версию PHP. Тогда дам конкретные команды/параметры для правки.