Почему не работает редактирование и добавление постов WordPress?

Question

[Rubilnik]

WordPress 6.7.1
Видимо после очередного автоматического обновления сломался редактор постов - не могу не добавить ни изменить существующие статьи.
Пробовал отключать все дополнения - не помогло.
Выводит ошибку в редакторе постов:
Вы попытались отредактировать несуществующий элемент. Вероятно, его удалили.
Как можно более подробно узнать, чем вызвана такая ошибка?

P.S. - попробовал через официальное андроид приложение - редактирование и добавление работает без проблем.

Comments

[Михаил Р.]

Как можно более подробно узнать, чем вызвана такая ошибка?

Что отладка wp говорит?

[Rubilnik]

Михаил Р., спасибо за наводку вероятно это то, что я ищу

[antdantd]

Мы тут с GPT подумали и я решил:
(НЕ ЗАБЫВАЙТЕ БЭКАПИТЬ БАЗУ И WP ПЕРЕД ЭКСПЕРИМЕНТАМИ)

1. Проверьте целостность базы данных:
За йдите в phpMyAdmin (или через командную строку) и выполните команду:
CHECK TABLE wp_posts;
Если будет указано, что таблица повреждена, выполните:
REPAIR TABLE wp_posts;
Существование поста в базе: Если вы пытаетесь редактировать конкретный пост, найдите его по ID:

SELECT * FROM wp_posts WHERE ID = 'ID_вашего_поста';

Если результат пустой, пост действительно удален.

2. Попробуйте отключить Gutenberg. Добавьте в файл wp-config.php строку:

define('USE_GUTENBERG', false);
define('USE_BLOCK_EDITOR', false);

Проверьте, работает ли теперь редактор. Если проблема исчезла, возможно, конфликт вызван плагином или темой.

3. Иногда ошибка может быть связана с активной темой.
Активируйте стандартную тему WordPress, например, Twenty Twenty-Three:

4. Проблемы с правами доступа
Проверьте, что установлены правильные права доступа:
Для файлов: 644.
Для папок: 755.

5. Отключение REST API
WordPress использует REST API для работы редактора. Если REST API заблокирован сервером или плагином безопасности, это может привести к ошибкам.
Проверьте, работает ли REST API, перейдя по URL:
https://ваш_сайт/wp-json/
Если вы видите сообщение об ошибке, проверьте настройки плагинов безопасности или правил на сервере (например, .htaccess).

6. Не изменились ли минимальные требования у новой версии Wordpress?
Может версии Вашего хостинга (PHP и MySQL) перестали удовлетворять им после обновы WP?

[Rubilnik]

antdantd, 1 - проверял в первую очередь, там порядок.
2 - попробую
3 - тема тут вряд ли виновата - стоит стандартная.
4 - папки не трогал
5 - работает
6 - PHP 8.2.7 не думаю...

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

[Rubilnik]

antdantd, 2 - без изменений :(

[antdantd]

Rubilnik, может памяти поболее раза в 1.5-2 выделить для php через настройки сервера? (это навскидку).

[Rubilnik]

antdantd, вот тут пришли к решению откатиться к предыдущей версии, понимать бы что вызывает ошибку, вроде бы кастомных полей у меня не было..
Сейчас ещё посмотрю БД может что-то лишнее есть в wp_posts

[Rubilnik]

antdantd, сейчас ещё залез посмотреть - 3 шелла в корневой папке лежало, вероятно кто-то мог поломать что-то...

[antdantd]

Rubilnik, ну тогда сначала functions.php сравнить с дистрибутивным, что там поломали.
Потом сам php wordpress сравнить с дистрибутивным.
В принципе все делается хоть в FAR, TotalCommander или MidnightCommander если под Linux. Далее WinMerge или Diff на сравнения кусков кода.

А вот с базой сложнее. Пока как вручную ее почекать на внедрения вирусов и шеллов не предполагаю... Видимо плагинами-антивирусами для базы для начала.

Вообще эта тема интересная - как почекать "ручками" базу WP на внедрения пакостей?
С кодом все ясно (см выше), а вот базка..

[antdantd]

Задачка не из простых, в ручную чистить, но GPT всегда готов:

1. Создайте резервную копию базы данных

2. Вредоносный код чаще всего внедряется в следующие таблицы WordPress:
wp_posts: вредоносные JavaScript-коды, iframe, ссылки.
wp_postmeta: скрытые данные о постах.
wp_users: добавленные злоумышленники-администраторы.
wp_options: вредоносные скрипты и перенаправления.
wp_comments: спам-ссылки и вредоносные коды.

3. Просмотр таблицы wp_posts
Что искать:
Подозрительные записи: JavaScript, iframe, ссылки на сторонние ресурсы.
Пример вредоносного кода:

<script>document.location='http://malicious.site'</script>

Как проверить: Выполните SQL-запрос для поиска подозрительных записей:

SELECT ID, post_title, post_content 
FROM wp_posts 
WHERE post_content LIKE '%<script%' 
   OR post_content LIKE '%iframe%' 
   OR post_content LIKE '%eval(%'
   OR post_content LIKE '%base64_decode(%';

Чистка:
Удалите или исправьте такие записи, оставляя только полезный контент.

4. Проверка таблицы wp_users
Что искать:
Подозрительные аккаунты: неизвестные пользователи с правами администратора.
Как проверить:

SELECT ID, user_login, user_email, user_registered 
FROM wp_users 
WHERE user_login NOT IN ('ваш_администраторский_логин');

Чистка:
Удалите неизвестных пользователей:
DELETE FROM wp_users WHERE ID = <user_id>;

5. Проверка таблицы wp_options
Что искать:
Подозрительные записи: вредоносные редиректы, инъекции кода.
Как проверить:

SELECT option_id, option_name, option_value 
FROM wp_options 
WHERE option_value LIKE '%<script%' 
   OR option_value LIKE '%eval(%';

Чистка:
Удалите или исправьте вредоносные записи:
DELETE FROM wp_options WHERE option_id = <id>;

6. Проверка таблицы wp_comments
Что искать:
Спам-комментарии: ссылки на подозрительные сайты.
Как проверить:

SELECT comment_ID, comment_content 
FROM wp_comments 
WHERE comment_content LIKE '%http://%' 
   OR comment_content LIKE '%https://%';

Чистка:
Удалите спам-комментарии:
DELETE FROM wp_comments WHERE comment_ID = <id>;

7. Проверка таблицы wp_postmeta
Что искать:
Вредоносные скрипты или подозрительные мета-данные.

Как проверить:

SELECT meta_id, meta_key, meta_value 
FROM wp_postmeta 
WHERE meta_value LIKE '%<script%' 
   OR meta_value LIKE '%eval(%';

Чистка:
Удалите вредоносные записи.

8. Общая проверка базы
Базовый поиск всего подозрительного:

SELECT * 
FROM information_schema.tables 
WHERE table_schema = 'your_database_name' 
  AND (table_name LIKE '%eval%' 
       OR table_name LIKE '%base64%' 
       OR table_name LIKE '%shell%');

9. Очистка с пониманием контекста
Сравните подозрительные записи с предыдущими резервными копиями.
Если резервных копий нет, сохраняйте статьи, заголовки и комментарии, которые явно полезны.

10. Обновление ядра, плагинов и тем
После чистки:
Установите обновленные версии WordPress, плагинов и тем.
Убедитесь, что файлы WordPress не содержат вредоносного кода.

11. Защита на будущее
Используйте плагины безопасности, например, Wordfence или Sucuri.
Регулярно делайте резервные копии.

[antdantd]

Из автоматов-чистильщиков:

Wordfence Security
Sucuri Security
Anti-Malware Security and Brute-Force Firewall
MalCare Security
WP Cerber Security
Quttera Web Malware Scanner
Exploit Scanner
GotMLS (Anti-Malware Security)
WPScan

Для простого сканирования и удаления вирусов подойдут Wordfence или Anti-Malware Security.
Если требуется минимальная нагрузка на сервер, попробуйте MalCare.
Если хотите сохранить контроль за процессом, используйте Exploit Scanner.

Для автоматической очистки и фокуса на базе данных:
Anti-Malware Security and Brute-Force Firewall.
GotMLS (Anti-Malware Security).
Для мониторинга и глубокого анализа (вручную):
Exploit Scanner.
Sucuri Security.

Для общего уровня защиты:
Wordfence Security.

Если ваша цель — полностью контролировать процесс чистки, выберите Exploit Scanner, но если нужна помощь в автоматизации, попробуйте GotMLS или Anti-Malware Security.

Answer 1

[Михаил Р.]

Используйте wp отладку, для выявления большинства проблем.

Comments

[Rubilnik]

К сожалению никакой дополнительной информации не выводит с включенным WP_DEBUG.
Я саму ошибку забыл указать:
Вы попытались отредактировать несуществующий элемент. Вероятно, его удалили.

Answer 2

[Rubilnik]

Поставил плагин Classic Editor и редактор заработал. В общем непонятно, но похоже что-то мешает работе Gutenberg, если не ошибаюсь, это новый основной редактор в WP.

Comments

[antdantd]

Попробуйте параллельно поставить чистый Wordpress на этом же хост той версии на которую проапдейтились с чистой базой.
Если Гутенберг в нем работает, добавляйтв него е плагины, один за одним такиеже какие стоят на рабочем WP и оцениваете работу Гутенберга.
Если поставили все и всё работает, попробуйте подключить рабочую базу, КОНЕЧНО СБЭКАПИВ ЕЕ И ОТКЛЮЧИВ РАБОЧИЙ WP ВРЕМЕННО.
ВСЕ ДЕЛАТЬ В РЕМОНТНОМ РЕЖИМЕ САЙТА С ПОМОЩЬЮ .htaccess
чтобы сайт не был виден пользователям.

Можно конечно прийти и с другой стороны.
У рабочего сайта отключить и удалить все плагины и очистить базу или подсунуть нулёвую.
После каждого шага оценивать работоспособность Гутенберга.

[antdantd]

define('USE_GUTENBERG', false);
define('USE_BLOCK_EDITOR', false);

Вы пишите, что это не помогло.
(Гутенберг отключен).

А помогла установка классического редактора.

Интересно...

Что же тогда вызывается в качестве редактора? (когда Гуттенберг отключен дерективами, а классический редактори не установлен еще).
Значит проблема в этой "штуке или ветке кода"?
Самому интересно стало..

Так, размышление..

[Rubilnik]

antdantd, так да в том то и прикол, что выглядело как будто никакого редактора в принципе нет. Гутенберг пробовал отдельно плагином ставить - не помогло, а вот классический редактор в виде плагина почему-то помог. Хоть и прошлый редактор был удобнее, но как временное решение пойдёт.