Обслуживание WordPress Взломали сайт? Плагин безопасности Цены Блог
Главная / Блог / Обслуживание WordPress
8 октября, 2026

Contact Form 7 6.2 уронил сайт? Как вернуть доступ

Ночью обновился Contact Form 7, утром сайт показывает критическую ошибку. На этой неделе я разбирал такую поломку на нескольких клиентских сайтах. Где-то открывалась админка, где-то не открывалось вообще ничего. Поэтому универсальной кнопки «починить» тут нет: сначала нужен лог ошибок и версия PHP на сервере.

Удалять контактные формы навсегда не придется. Это проблема обновления. Вернуть доступ можно даже тогда, когда WordPress не пускает вас внутрь.

Что сломалось в 6.2?

У Contact Form 7 больше 10 миллионов активных установок. Автор назвал выпуск 6.2 от 6 октября 2026 года крупным обновлением. Для него нужны WordPress 7.1 или новее и PHP 8.3 или новее. Для 6.1.7 хватало WordPress 6.7 и PHP 7.4. Разница немаленькая, особенно если хостинг давно никто не проверял.

Подтвержденная ошибка довольно хитрая. Плагин загружал свой файл Composer через require 'vendor/autoload.php';. PHP мог сперва поискать его в текущей рабочей папке - на страницах сайта это часто корень WordPress. Если там лежал отдельный vendor/autoload.php, Contact Form 7 подхватывал не свой файл. После этого он мог упасть при поиске RockLobsterInc\Swv\CompositeRule. По сообщениям пользователей, сайты без такого файла в корне обновились нормально.

Иногда ломались только страницы сайта, а /wp-admin/ продолжал работать. Иногда пропадали и сайт, и админка; WP-Cron и WP-CLI тоже могли падать. В версии 6.2.1 от 8 октября путь исправили: плагин теперь обращается к своему полному пути.

Есть и другая история, пока не до конца понятная. Некоторые владельцы сайтов с PHP ниже 8.3 сообщали, что автообновление все равно поставило 6.2. Потом появлялась ошибка Your Composer dependencies require a PHP version ">= 8.3.0". Обычно WordPress блокирует несовместимые обновления - почему здесь это не сработало, неясно. В одном сообщении ошибка показывала PHP 8.2, а «Здоровье сайта» - 8.4. Разные процессы сервера, включая cron, могут использовать разные версии PHP. И да, 6.2.1 требование PHP не снижает.

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


Как понять, что виноват Contact Form 7

После обновления видите белый экран или сообщение WordPress “There has been a critical error on this website”? Не меняйте файлы вслепую. Сначала откройте лог ошибок в панели хостинга. Еще один вариант - wp-content/debug.log, если включен WP_DEBUG_LOG.

Ищите в логе contact-form-7, RockLobsterInc\Swv\CompositeRule или platform_check.php. Ошибка с классом указывает на загрузчик файлов, проверка платформы - на PHP. И попробуйте открыть /wp-admin/ напрямую. Вдруг админка жива, хотя главная страница уже нет.

Как вернуть доступ, если админка не открывается

  1. Проверьте письмо для режима восстановления. WordPress может отправить его на адрес администратора из Настройки > Общие (Settings > General). Ссылка временно приостановит проблемный плагин для вашей сессии - сможете войти. Она действует около суток, а WordPress отправляет такое письмо не чаще раза в день. Если почта сайта работает через раз, не ждите ее.
  2. Переименуйте папку плагина. Через SFTP, FTP или файловый менеджер хостинга переименуйте wp-content/plugins/contact-form-7 в contact-form-7-off. WordPress отключит плагин. Если падал именно Contact Form 7, сайт должен открыться. Правда, формы могут исчезнуть или показать сырые шорткоды. Это способ попасть обратно, а не решение на несколько дней.
  3. Используйте WP-CLI, если есть SSH. Выполните wp plugin deactivate contact-form-7 --skip-plugins=contact-form-7. Флаг пропуска оставьте: без него WP-CLI тоже может упасть при загрузке плагина. Для прямого отката выполните wp plugin install contact-form-7 --version=6.1.7 --force --skip-plugins=contact-form-7.

Нет SSH? Во время аварии файловый менеджер хостинга часто быстрее. Не нужно разбиратся с доступом к консоли, когда сайт уже лежит.


Ставить 6.2.1 или откатываться?

Проверьте PHP в Инструменты > Здоровье сайта (Tools > Site Health) > Информация > Сервер (Info > Server) либо в панели хостинга. Заодно проверьте WordPress: ветке 6.2 нужна версия 7.1 или новее. Если ошибка называет другую версию PHP, спросите у хостинга, какую версию использует именно падающий процесс.

Оба требования выполнены? Ставьте 6.2.1. Если переименовывали папку, верните ей старое имя, включите плагин и сразу обновите. Либо загрузите свежую копию 6.2.1. Когда возврат старой папки снова вызывает критическую ошибку, не пытайтесь воевать с админкой - замените папку свежей копией. Потом отправьте настоящее тестовое сообщение через каждую форму. Проверьте поля даты, варианты с апострофами, формы с дополнениями. Страница открылась - еще не значит что заявки доходят.

PHP ниже 8.3? Верните 6.1.7. Подойдет команда WP-CLI выше. Без консоли скачайте старый архив со страницы плагина на WordPress.org: Дополнительно (Advanced) > предыдущие версии (previous versions). Замените папку плагина. Адрес архива - downloads.wordpress.org/plugin/contact-form-7.6.1.7.zip. В разделе Плагины (Plugins) отключите автообновление Contact Form 7, иначе он может снова прыгнуть на 6.2. Через WP-CLI для этого есть wp plugin auto-updates disable contact-form-7.

Обновление PHP запланируйте вместе с хостингом, но сначала проверьте сайт на копии: старые темы и плагины иногда ломаются. Совет с форума вручную править load.php я бы пропустил. В 6.2.1 путь уже исправлен, а следующий апдейт затрет вашу правку.

Что я бы поменял после такого сбоя

Для меня обслуживание WordPress вручную - это проверить формы после обновления, а не просто убедиться, что главная страница открылась. Небольшие исправления можно ставить автоматически. А вот скачок с новым требованием к PHP лучше назначить на выбранный день и сначала заглянуть на форум поддержки. Автообновления можно настроить отдельно для каждого плагина.

  • Крупные обновления сначала пробуйте на копии сайта. В статье о том, как обновляться без сюрпризов, разобран безопасный порядок действий.
  • Разберитесь с восстановлением заранее, а не только с местом хранения архива. Бэкап - еще не план восстановления, если порядок действий вы выясняете уже во время простоя.
  • Подключите мониторинг доступности - он заметит упавшую главную. Но отправку заявок проверяйте сами: форма может не работать на совершенно обычной с виду странице.

Сегодня проверьте две вещи: версию PHP в «Здоровье сайта» и включено ли автообновление Contact Form 7. Вот эти ответы подскажут, можно ли вам ставить 6.2.1 прямо сейчас или сначала придется вернуться на 6.1.7.