Compatibilité PHP 8

Un verdict rendu sur une version que l’hébergement ne propose pas est un verdict sans objet : il donne le sentiment d’une porte ouverte sur un mur. Cet inventaire vient donc avant le verdict.

Cet inventaire dépend de l’hébergeur et changera sans prévenir : c’est pourquoi il porte sa date. Le reproduire tient en deux commandes — ls -d /opt/plesk/php/*/ et apt-cache search ^plesk-php.

Trois passes, dans cet ordre — et l’ordre compte, chacune voyant ce que la précédente ne pouvait pas voir.

Deux défauts, tous deux invisibles en PHP 7.4, tous deux corrigés.

Le verdict porte sur l’application. Il ne s’étend pas à tout l’outillage, et la matrice d’intégration continue l’a démontré dès sa première exécution.

php symfony doctrine:insert-sql --env=test rend un code 1 sous PHP 8 — code 0 sous 7.4 — alors qu’il a fait tout son travail : les onze tables et leurs clés étrangères sont créées dans les deux cas.

La mécanique est instructive et se retrouvera ailleurs :

Doctrine_Export::exportClasses() ouvre une transaction, émet les CREATE TABLE puis les ALTER TABLE, et appelle commit(). Or les instructions DDL de MySQL valident implicitement : la transaction est déjà refermée quand Doctrine la valide. PHP 7.4 laissait PDO silencieux ; PHP 8 lève une PDOException — « There is no active transaction ».

Le défaut est dans une dépendance vendue, pas dans le code du projet. L’intégration continue asserte donc le résultat — la présence effective des tables — plutôt que le code de sortie de la tâche. Tolérer le code sans vérifier le schéma laisserait passer une base réellement incomplète.

C’était le premier élément connu à corriger avant une migration réelle. Il l’est.

musiqueapproximative:build-test-schema — sous src/lib/task/ — enveloppe désormais la tâche de Doctrine : elle exécute le travail, ne tolère que l’exception « There is no active transaction », et vérifie la présence effective des tables avant de rendre 0. Toute autre erreur est propagée, et un schéma réellement incomplet fait échouer, quelle que soit la version de PHP.

On ne corrige pas Doctrine lui-même : src/vendor est ignoré par git et réinstallé à chaque composer install, un correctif y serait perdu au premier déploiement.

Le contournement qui vivait dans tests.yml a disparu au profit de cette tâche. Il ne couvrait qu’un poste de travail sur deux : make test-init lançait la même tâche sans garde, et un développeur voyait échouer sous PHP 8 ce que l’intégration continue voyait réussir. Les deux appelants ont maintenant le même comportement.

Le garde a été éprouvé par l’échec avant d’être déclaré bon, comme la matrice l’avait été : table post retirée à la main, la tâche rend 1 en la nommant.

Un « la suite passe » nu se lit comme « la migration est sûre ». Il ne l’établit pas.

Chacune aurait produit un verdict faux, et chacune coûte une demi-journée à celui qui la rencontre sans être prévenu.

Le cache d’autoload partagé. La première exécution sous PHP 8 a échoué au démarrage sur un chemin absolu introuvable. Ce n’était pas une incompatibilité : deux conteneurs montaient src/ à des emplacements différents et partageaient src/cache/. La mesure refaite avec un volume isolé sur cache/ et log/ donne exactement les mêmes échecs, les mêmes scripts, les mêmes numéros de test.

Le jeu d’extensions. Un conteneur jetable n’a pas les extensions de l’image du projet. Elles ont été comparées terme à terme avant de conclure : identiques à pdo_mysql près, installé dans la passe. Sans cette comparaison, un mbstring manquant aurait produit la même ampleur de casse et fait accuser PHP 8 à tort.

Un chiffre écrit dans une page vieillit sans prévenir. C’est arrivé quatre fois dans cette release.

La suite tourne donc sous les deux versions, 7.4 et 8.1, dans .github/workflows/tests.yml, avec le même statut bloquant. fail-fast est désactivé pour que les deux rendent leur verdict.

La matrice a payé dès ses deux premières exécutions, en trouvant deux défauts que la mesure locale n’avait pas vus : la contrainte php de composer.json, invisible tant que vendor/ était déjà installé, et l’échec de doctrine:insert-sql décrit plus haut, invisible tant que la base de test existait déjà.

Une passe seulement consultative aurait viré au rouge permanent puis à l’ignorance — c’est le mode de défaillance habituel des vérifications facultatives, et il vaut mieux ne pas en ajouter que d’en ajouter sans dents.

Le contrôle a été vérifié par l’échec avant d’être déclaré bon : le garde retiré, test:unit rend un code 1 sous 7.4 en nommant les assertions, et la suite fonctionnelle rend un code 1 sous 8.1 en nommant sfGuardUser.class.php et sa ligne.

Les deux volumes anonymes sur cache/ et log/ ne sont pas décoratifs : sans eux, le cache du conteneur de développement fait échouer la mesure pour une raison qui n’a rien à voir avec PHP 8.