Contact Form 7 6.2 est sorti le 6 octobre 2026 et a relevé les exigences minimales du plugin à WordPress 7.1 et PHP 8.3, contre WordPress 6.7 et PHP 7.4 pour la version 6.1.7. Avec plus de 10 millions d’installations actives, ce saut empêche beaucoup de sites de se mettre à jour, ou les fait tomber en panne avec une erreur Composer. Depuis le 8 octobre, le forum de support du plugin se remplit de messages sur les deux cas.
Si votre site fonctionne et que la mise à jour refuse de s’exécuter, rien n’est brisé : la solution est de changer la version de PHP chez votre hébergeur, en testant d’abord sur une copie de staging. Si votre site affiche une erreur critique, le remettre en ligne prend quelques minutes, et la mise à niveau de PHP reste la vraie solution.
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.
Pourquoi WordPress ne met-il pas Contact Form 7 à jour vers la 6.2?
Parce que le plugin déclare PHP 8.3 et WordPress 7.1 comme minimums, et que WordPress vérifie ces exigences avant d’installer quoi que ce soit. L’annonce de la version dit : « Contact Form 7 6.2 requires WordPress 7.1+ and PHP 8.3+, in accordance with our WordPress support policy. » Cette politique prend en charge les versions de PHP recommandées par l’avant-dernière version majeure de WordPress, et la page des exigences de WordPress recommande PHP 8.3 ou plus récent.
D’après le code de WordPress 7.1.3, chaque chemin passe par la même vérification :
- L’écran des extensions affiche
There is a new version of Contact Form 7 available, but it does not work with your version of PHP.sans lien de mise à jour. - Une tentative de mise à jour s’arrête avec
The PHP version on your server is X, however the new plugin version requires 8.3.Le téléversement d’un zip se termine de la même façon avec « the uploaded plugin requires 8.3 ». Sur WordPress antérieur à 7.1, le message estYour WordPress version is X, however the new plugin version requires 7.1. - Les mises à jour automatiques ignorent le plugin,
wp plugin updateeffectue la même vérification, et l’activation échoue avecCurrent PHP version (X) does not meet minimum requirements for Contact Form 7. The plugin requires PHP 8.3.
Chaque vérification utilise la version de PHP du processus qui exécute la tâche, et ce n’est pas toujours le PHP qui sert vos pages. Cet écart est à l’origine du problème suivant.
Pourquoi mon site affiche-t-il quand même l’erreur Composer?
Parce que les fichiers de la 6.2 se sont retrouvés sur un serveur avec un PHP plus ancien sans passer par cette vérification. Cela arrive quand une mise à jour passe par WP-CLI ou un outil de l’hébergeur dont le PHP en ligne de commande est plus récent que le PHP web; quand les fichiers sont copiés en dehors de WordPress (SFTP, gestionnaire de fichiers, déploiement git ou Composer, restauration de sauvegarde, envoi depuis un staging ou migration); ou quand le PHP du site est rétrogradé après coup.
Contact Form 7 6.2 charge alors l’autoloader de Composer, et la vérification de plateforme de Composer bloque tout PHP inférieur à 8.3. Le serveur répond par une erreur 500, la page affiche Composer detected issues in your platform: Your Composer dependencies require a PHP version ">= 8.3.0". et WordPress ajoute There has been a critical error on this website. Le mode de récupération envoie un lien de récupération par courriel à l’administrateur du site. Le message visible n’indique pas votre version de PHP, mais le journal d’erreurs de PHP la conserve, tout comme debug.log quand WP_DEBUG_LOG est activé :
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.
Ce numéro « You are running » est le PHP qui a réellement servi la requête, et je lui ferais plus confiance qu’à un panneau de contrôle d’hébergement. Je comparerais ensuite deux autres numéros : la version de PHP sous Outils, Santé du site, Info, Serveur, qui est le PHP qui sert l’administration (l’auteur du plugin demande justement ce champ dans les fils de support), et celle que rapporte wp --info, qui est le PHP utilisé par WP-CLI. Quand elles diffèrent, vous avez trouvé la cause.
Comment remettre un site en ligne après l’erreur critique?
Désactivez le plugin sans le supprimer, par la voie qui vous est accessible :
- Ouvrez le lien du mode de récupération reçu par courriel et désactivez Contact Form 7. Le site se charge une fois le plugin désactivé.
- Renommez le dossier
wp-content/plugins/contact-form-7par SFTP ou avec le gestionnaire de fichiers de l’hébergeur. WordPress désactive le plugin et le site public revient. Redonnez-lui son nom d’origine avant de le réinstaller. - Exécutez la commande WP-CLI ci-dessous. L’option
--skip-pluginsempêche le plugin de se charger pendant l’exécution de la commande, donc elle fonctionne peu importe la version de PHP utilisée par WP-CLI.
wp plugin deactivate contact-form-7 --skip-plugins=contact-form-7
Deux avertissements. Ne supprimez jamais Contact Form 7 depuis l’écran des extensions pour le réinstaller : la suppression lance la routine de désinstallation, qui retire définitivement tous les formulaires, les réglages et la table de base de données du plugin. Remplacez-le plutôt. Et gardez le dossier nommé contact-form-7. Un cas sur le forum affichait The plugin contact-form-7-/wp-contact-form-7.php has been deactivated due to an error: Plugin file does not exist. parce que le dossier avait un trait d’union de trop; WordPress identifie un plugin par son dossier et son fichier principal.
Dois-je revenir à Contact Form 7 6.1.7?
Seulement comme solution temporaire, le temps de mettre PHP à niveau. La page WordPress.org de l’extension propose la version 6.1.7 sous Advanced View, Previous Versions, avec cet avertissement : « Previous versions of plugins may not be secure or stable. They are not recommended for use on production websites. » Téléversez le zip sous Extensions, Ajouter une extension, Téléverser une extension, puis choisissez Remplacer l’actuelle par celle téléversée. L’annonce de la version 6.2 ne dit rien sur d’éventuels correctifs pour la branche 6.1; la 6.1.7 est donc un pont, pas une destination.
Comment corriger le problème pour de bon?
Faites passer le site à PHP 8.3 ou plus récent, puis mettez WordPress à jour, puis l’extension, dans cet ordre.
Si vous changez de toute façon la version de PHP cette semaine à cause de PHP2Shell, les deux vulnérabilités critiques de PHP corrigées le 21 octobre, faites les deux tâches d’un coup. Passez directement à PHP 8.3.36 ou plus récent, ou à la version corrigée de votre hébergeur, et Contact Form 7 pourra être mis à jour ensuite. Mon guide PHP2Shell pour les propriétaires de sites WordPress indique les versions corrigées et comment vérifier laquelle votre site utilise.
- Faites une copie de préproduction et réglez
WP_DEBUGetWP_DEBUG_LOGà true dans son fichier wp-config.php. Si la préproduction se charge et que les erreurs commencent à s’écrire dans wp-content/debug.log, c’est réussi. - Faites passer la préproduction à PHP 8.3 ou plus récent dans le réglage PHP de votre hébergeur, en choisissant 8.3.36 ou plus récent, ou une version que votre hébergeur confirme corrigée : les versions 8.3 antérieures sont exposées à PHP2Shell. C’est réussi si Santé du site affiche 8.3.36 ou plus, ou si votre hébergeur confirme la version corrigée.
- Parcourez le site et l’administration, puis lisez debug.log. Toute autre extension ou tout autre thème qui échoue sous 8.3 apparaît ici; corrigez-le ou remplacez-le avant de toucher à la production.
- Mettez WordPress à jour vers 7.1 ou plus récent, puis Contact Form 7. C’est réussi si l’écran des extensions affiche 6.2.3 ou plus, avec le statut Activée et aucun avis PHP.
- Refaites la même chose en production, puis envoyez un message de test depuis un vrai formulaire. C’est réussi si le message arrive et que le journal d’erreurs ne contient aucune nouvelle ligne Composer.
Si votre hébergeur configure séparément le PHP en ligne de commande et le PHP du web, notez dès maintenant les deux numéros de version. La prochaine extension qui relèvera sa version minimale se heurtera au même écart, et savoir quel PHP fait quoi transforme une erreur 500 déroutante en correctif rapide.
