A critical error is a lousy way to find out your plugins updated overnight. I dealt with several client sites that went down after Contact Form 7 6.2. Some still had a working dashboard. Others didn’t. The way back depended on the error log and the server’s PHP version.
This isn’t a reason to delete your contact forms. It’s an update problem, and you can get back in even if WordPress won’t let you log in.
What broke in 6.2?
Contact Form 7 has more than 10 million active installs. Its author called 6.2, released October 6, 2026, a major update. It requires WordPress 7.1 or newer and PHP 8.3 or newer; 6.1.7 requires WordPress 6.7 and PHP 7.4.
The confirmed bug is oddly specific. The plugin tried to load its Composer file with require 'vendor/autoload.php';. PHP can look in the current working directory first, often the WordPress root on the front end. If there’s a separate vendor/autoload.php there, Contact Form 7 can load the wrong file and fail while looking for RockLobsterInc\Swv\CompositeRule. Sites without that root-level vendor file reportedly updated fine.
Sometimes the front end failed while /wp-admin/ worked. Others lost both; WP-Cron and WP-CLI could fail too. Version 6.2.1, released October 8, fixes the path by using the plugin’s full directory path.
There’s another, less settled report. Some sites below PHP 8.3 say auto-update installed 6.2 anyway, then showed Your Composer dependencies require a PHP version ">= 8.3.0". WordPress normally blocks incompatible updates, so why those got through isn’t clear. One report showed PHP 8.2 in the error and 8.4 in Site Health. Different server processes, including cron, may use different PHP versions. And 6.2.1 does not lower the PHP requirement.
People also reported date-picker selections failing validation, choices with apostrophes failing and multi-step or grid add-ons not submitting. Rolling back to 6.1.7 reportedly helped. The 6.2.1 changelog lists the path fix, not fixes for those form problems.
How to tell if Contact Form 7 is the problem
Got a white screen or WordPress’s “There has been a critical error on this website” message after updates? Check the error log before changing files. Look in your hosting panel, or in wp-content/debug.log if WP_DEBUG_LOG is enabled.
Search for contact-form-7, RockLobsterInc\Swv\CompositeRule, or platform_check.php. The class error points to the autoloader problem; the platform check points to PHP. Try /wp-admin/ directly too. It might still open.
Get back in, even if the dashboard won’t open
- Check for a recovery mode email. WordPress may email the site admin address from Settings > General when a plugin crashes. Its link pauses that plugin for your session so you can log in. It expires after about a day, and WordPress sends it at most once a day. If site email is unreliable, dont wait for it.
- Rename the plugin folder. In SFTP, FTP, or your host’s file manager, rename
wp-content/plugins/contact-form-7tocontact-form-7-off. WordPress will deactivate it. If Contact Form 7 caused the crash, the site should load, though forms may disappear or show raw shortcodes. A way back in. Not a fix to leave for days. - Use WP-CLI if you have SSH access. Run
wp plugin deactivate contact-form-7 --skip-plugins=contact-form-7. Keep that skip flag: WP-CLI may otherwise crash while loading the plugin. To roll back directly, runwp plugin install contact-form-7 --version=6.1.7 --force --skip-plugins=contact-form-7.
No SSH? The hosting file manager is usually quicker to use during an outage anyway.
Update to 6.2.1 or roll back?
Check PHP at Tools > Site Health > Info > Server or in your hosting panel. Check WordPress too: the 6.2 series needs 7.1 or newer. If an error reports a different PHP version, ask your host which version the failing process uses.
If you meet both requirements, install 6.2.1. Renamed the folder? Rename it back, reactivate and update promptly, or upload a fresh 6.2.1 copy. If restoring the old folder brings the fatal error back, use the fresh copy rather than fighting the dashboard. Then send a real test message through every form. Chek date fields, apostrophes in choices and any add-on forms. A loaded page doesn’t mean a working form.
If PHP is below 8.3, restore 6.1.7. Use the WP-CLI command above, or download the older zip from the plugin’s WordPress.org page under Advanced > previous versions and replace the plugin folder. Its address is downloads.wordpress.org/plugin/contact-form-7.6.1.7.zip. Disable Contact Form 7 auto-updates on the Plugins screen so it doesn’t jump to 6.2 again. In WP-CLI, run wp plugin auto-updates disable contact-form-7.
Plan a PHP upgrade with your host, but test it on a copy first; older themes and plugins can break. I’d skip the forum workaround of editing load.php. Version 6.2.1 fixes the path, and another update would overwrite your edit.
What I’d change after this
For me, WordPress maintenance means checking the forms after an update, not just seeing that the homepage loads. I don’t mind auto-updates for small patches. A jump that raises the PHP requirement? I’d rather pick the day myself and look at the support forum first. You can change that setting per plugin.
- Try major updates on a copy first. This WordPress staging guide shows you how.
- Know how to restore your backup, not just where the zip lives. A backup isn’t a recovery plan if you’re learning the restore steps during an outage.
- Use an uptime monitor to catch a dead homepage. And test submissions yourself: a form can fail on a perfectly normal-looking page.
Today, check your PHP version in Site Health and whether Contact Form 7 is set to auto-update. Those two answers tell you whether 6.2.1 is an option, or whether you’d need 6.1.7 back first.