What PHP version does Contact Form 7 6.2 require?

Contact Form 7 6.2 requires PHP 8.3 or newer and WordPress 7.1 or newer. Version 6.1.7 needed only PHP 7.4 and WordPress 6.7.

Why can't I update Contact Form 7 to 6.2?

WordPress checks the plugin's minimum requirements before it installs anything, and your server's PHP or WordPress version is below them. The Plugins screen then shows no update link, or the update stops with a message naming the version it needs.

What does the Composer error "Your Composer dependencies require a PHP version >= 8.3.0" mean?

It means the Contact Form 7 6.2 files are running on a server whose web PHP is older than 8.3. Composer's platform check stops the plugin from loading, and WordPress shows a critical error.

How do I get my site back after the Contact Form 7 critical error?

Deactivate the plugin without deleting it, using the recovery mode link, by renaming the plugin folder, or with WP-CLI and the --skip-plugins flag. Do not delete it from the Plugins screen, because that permanently removes your forms and settings.

Contact Form 7 6.2 needs PHP 8.3: how to fix failed updates and the Composer error

Contact Form 7 6.2 came out on October 6, 2026, and it raised the plugin’s minimums to WordPress 7.1 and PHP 8.3, up from WordPress 6.7 and PHP 7.4 in 6.1.7. With more than 10 million active installs, that jump has left many sites unable to update, or down with a Composer error, and since October 8 the plugin’s support forum has filled with both.

If your site is up and the update refuses to run, nothing is broken: the fix is a PHP version change at your host, tested on a staging copy first. If your site shows a critical error, getting it back takes a few minutes, and the PHP upgrade is still the real fix.

Key takeaways

Contact Form 7 6.2 needs PHP 8.3 and WordPress 7.1. That is up from PHP 7.4 and WordPress 6.7 in 6.1.7, and it is why many sites cannot update or are showing errors. arvindkumar.ca
WordPress checks the plugin’s minimums before it installs anything, so a site on older PHP sees no update link or a blocked update. Nothing is broken in that case, and the check uses the PHP of the process doing the work, which is not always the PHP serving your pages. arvindkumar.ca
The Composer error appears when the 6.2 files reach a server on older PHP without that gate catching them. This happens through WP-CLI with a newer command-line PHP, files copied in outside WordPress, or a PHP version switched down afterwards. arvindkumar.ca
To find the cause, compare the “You are running” version in the error log, the PHP version in Site Health, and the one from wp –info. When they differ, you have found the problem. arvindkumar.ca
To get a site back after the critical error, deactivate the plugin without deleting it. Use the recovery mode link, rename the plugin folder, or run WP-CLI with –skip-plugins. Deleting the plugin permanently removes every form, the settings and the database table. arvindkumar.ca
Rolling back to 6.1.7 is only a stopgap while PHP gets upgraded. WordPress.org warns that previous versions may not be secure or stable, and the 6.2 announcement mentions no fixes for the 6.1 branch. arvindkumar.ca
The proper fix is to move the site to PHP 8.3 or newer, then update WordPress, then the plugin, testing on a staging copy first. If you are also covering PHP2Shell, go straight to PHP 8.3.36 or newer, or your host’s patched build. arvindkumar.ca

Summarised from this post, formatted for answer engines.

Why won’t WordPress update Contact Form 7 to 6.2?

Because the plugin declares PHP 8.3 and WordPress 7.1 as its minimums, and WordPress checks those before it installs anything. The release announcement says: “Contact Form 7 6.2 requires WordPress 7.1+ and PHP 8.3+, in accordance with our WordPress support policy.” That policy supports the PHP versions recommended by the second-latest major WordPress version, and WordPress’s requirements page recommends PHP 8.3 or greater.

Checked against WordPress 7.1.3’s code, every route runs the same gate:

The Plugins screen shows There is a new version of Contact Form 7 available, but it does not work with your version of PHP. with no update link.
An update attempt stops with The PHP version on your server is X, however the new plugin version requires 8.3. A zip upload ends the same way with “the uploaded plugin requires 8.3”. On WordPress below 7.1 it is Your WordPress version is X, however the new plugin version requires 7.1.
Automatic updates skip the plugin, wp plugin update runs the same check, and activation fails with Current PHP version (X) does not meet minimum requirements for Contact Form 7. The plugin requires PHP 8.3.

Each check uses the PHP version of the process doing the work, which is not always the PHP serving your pages. That gap is where the next problem comes from.

Why does my site show the Composer error anyway?

Because the 6.2 files reached a server on older PHP without that gate catching them. That happens when an update runs through WP-CLI or a host tool whose command-line PHP is newer than the web PHP; when files are copied in outside WordPress (SFTP, a file manager, a git or Composer deploy, a backup restore, a staging push or a migration); or when the site’s PHP is switched down afterwards.

Contact Form 7 6.2 then loads Composer’s autoloader, and Composer’s platform check stops PHP below 8.3. The server answers with a 500, the page shows Composer detected issues in your platform: Your Composer dependencies require a PHP version ">= 8.3.0". and WordPress adds There has been a critical error on this website. Recovery mode emails the site admin a recovery link. The visible message leaves out your PHP version, but the PHP error log keeps it, as does debug.log when WP_DEBUG_LOG is on:

PHP Fatal error: Uncaught RuntimeException: Composer detected issues in your platform: Your Composer dependencies require a PHP version ">= 8.3.0". You are running 8.2.34.

That “You are running” number is the PHP that actually served the request, and I’d trust it over a hosting control panel. Then I’d compare two more numbers: the PHP version under Tools, Site Health, Info, Server, which is the PHP serving the admin (the plugin’s author asks for exactly that field in support threads), and the one wp --info reports, which is the PHP WP-CLI uses. When they differ, you have your cause.

How do I get a site back up after the critical error?

Deactivate the plugin without deleting it, by whichever route you can reach:

Open the recovery mode link from the email and deactivate Contact Form 7. The site loads once the plugin is off.
Rename the wp-content/plugins/contact-form-7 folder over SFTP or the host’s file manager. WordPress deactivates the plugin and the front end returns. Rename it back before reinstalling.
Run the WP-CLI command below. The --skip-plugins flag keeps the plugin from loading while the command runs, so it works whichever PHP version WP-CLI uses.

wp plugin deactivate contact-form-7 --skip-plugins=contact-form-7

Two warnings. Never delete Contact Form 7 from the Plugins screen to reinstall it: deleting runs the uninstall routine, which permanently removes every form, the settings and the plugin’s database table. Replace it instead. And keep the folder named contact-form-7. One forum case showed The plugin contact-form-7-/wp-contact-form-7.php has been deactivated due to an error: Plugin file does not exist. because the folder had an extra hyphen; WordPress identifies a plugin by its folder and main file.

Should I roll back to Contact Form 7 6.1.7?

Only as a stopgap while PHP gets upgraded. The plugin’s WordPress.org page lists 6.1.7 under Advanced View, Previous Versions, with a warning: “Previous versions of plugins may not be secure or stable. They are not recommended for use on production websites.” Upload the zip at Plugins, Add New Plugin, Upload Plugin, and choose Replace current with uploaded. The 6.2 announcement says nothing about fixes for the 6.1 branch, so 6.1.7 is a bridge, not a destination.

How do I fix it properly?

Move the site to PHP 8.3 or newer, then update WordPress, then update the plugin, in that order.

If you are changing PHP this week anyway because of PHP2Shell, the two critical PHP vulnerabilities fixed on October 21, do both jobs at once. Go straight to PHP 8.3.36 or newer, or your host’s patched build, and Contact Form 7 can update afterwards. My PHP2Shell guide for WordPress site owners lists the fixed versions and how to check which one your site runs.

Make a staging copy and set WP_DEBUG and WP_DEBUG_LOG to true in its wp-config.php. It worked if staging loads and errors start landing in wp-content/debug.log.
Switch staging to PHP 8.3 or newer in your host’s PHP setting, and make it 8.3.36 or later, or a build your host confirms is patched: earlier 8.3 releases are open to PHP2Shell. It worked if Site Health shows 8.3.36 or higher, or your host confirms the patched build.
Click through the site and the admin, then read debug.log. Any other plugin or theme that fails on 8.3 shows up here; fix or replace it before touching production.
Update WordPress to 7.1 or newer, then Contact Form 7. It worked if the Plugins screen shows 6.2.3 or later and Active with no PHP notice.
Repeat on production, then send a test submission from a real form. It worked if the message arrives and the error log has no new Composer line.

If your host sets command-line PHP and web PHP separately, write both numbers down now. The next plugin that raises its minimum will hit the same gap, and knowing which PHP does what turns a confusing 500 into a short fix.