Symfony 4.3 inutilisable via Apache et module PHP

Bonjour,

Je viens vers vous aujourd’hui parce que quelque chose doit m’échapper.

J’essaie de passer certains de mes projets de Symfony 4.2 à 4.3. Seulement, à chaque fois que je tente d’accéder par HTTP à un projet que j’ai mis à jour, je me mange une erreur comme quoi le polyfill pour PHP 7.3 n’est pas trouvé.

• Je n’ai pas de souci avec la ligne de commandes ;
• J’ai installé symfony/requirements-checker, mais il ne fonctionne pas mieux ;
• J’ai tenté un projet vide , aucun changement (j’utilise composer, je prends symfony/website-skeleton) ;
• J’ai tenté l’installation sous Linux avec PHP 7.2.19, même souci ;
• Pensant que ça pouvait être un problème de la recette de déploiement, j’ai retenté plusieurs fois depuis la sortie de Symfony 4.3.1, mais je ne vois pas de différence malgré les versions ;
• Apparemment, seule la version 7.2 de PHP me pose problème (j’ai essayé la 7.2.13 puis ai mis à jour vers PHP 7.2.19 sans que cela ne change). Les versions 7.1.30 et 7.3.6 de PHP me permettent d’accéder sans souci au(x) projet(s) ;
• Fort de ce dernier constat, j’ai comparé les php.ini entre PHP 7.1/7.3 et 7.2. Outre les différences dues aux versions, je n’ai rien vu de suspect à ce niveau ;
• J’ai vérifié, le polyfill est bien installé, et le namespace cité dans l’erreur est correct ;
• La version de Composer n’est apparemment pas vraiment importante, le souci survient avec 1.8.6 sous Windows et Linux comme avec une 1.6.3 sous Linux ;
• symfony/symfony-demo se comporte de la même manière.

J’ai cru que je trouverais des pistes, mais apparemment non. Donc soit il y a quelque chose à quoi je n’ai pas pensé dans mes configurations testées ou/et une vérification que j’ai mal faite, soit j’ai la malchance d’être tombé sur un bug qui n’est pas encore référencé, et ça me surprendrait vraiment beaucoup.

En conséquence, est-ce que quelqu’un a déjà rencontré ce souci et comment l’a-t’il réglé ? Sinon, auriez-vous des pistes ?

Merci d’avance

D’après la doc à propos du package polyfill_php72, polyfill est apparu en 7.2, avant symfony doit pouvoir activer des commandes de support pour ne pas utiliser polyfill, ce qui est prouvé par ce morceau de code. D’où le fait que ça fonctionne en 7.1.

J’ai vu qu’il y avait aussi : polyfill_php73 qui ajoute de nouvelle fonction, as-tu essayé de l’ajouter ?

C’est justement Polyfill 7.3 qui me pose problème, alors qu’il est bien présent dans les dépendances installées. Seulement je finis par me dire que la génération des fichiers d’autoload est foireuse parce que Composer ne me l’intègre pas correctement.

Et j’ai bien vérifié, j’ai Composer 1.8.6 sur les deux machines Windows sur lesquelles j’ai reproduit le problème.

En même temps, pourquoi seul PHP 7.2 pose problème si c’est vraiment ça ?

Edit

Ah, si Polyfill 7.3 est installé, c’est qu’il fait partie des dépendances natives de Symfony, apparemment. En tout cas, je ne l’ai pas installé moi en plus — sans quoi je n’aurais pas dit qu’un projet "vide" ne fonctionnait pas non plus 

Même une installation avec PHP 7.1 cause les mêmes symptômes. J’imagine que si j’utilisais PHP 7.3 je n’aurai pas non-plus de souci à l’installation, mais je n’aurais pas le polyfill du fait de la version utilisée, et le serveur étant en 7.2, ça ne fonctionnera pas après déploiement…

Bon, je subodore que c’est plus un souci de PHP 7.2 sous Windows qu’en général, (d’autres tests sous Linux ne posent pas de problème).

Du coup, je laisse tomber, mais je ne mets volontairement pas en résolu.

J’ai déjà eu, une fois des soucis de lib php mal compilé sur php, sous Windows. C’est vraiment important d’utiliser php 7.2 si la 7.3 fonctionne ?

Le serveur étant en PHP 7.2, je voulais avoir un environnement en local qui colle au plus près, nonobstant l’OS. Et c’est assez particulier d’avoir le même souci avec deux versions de PHP 7.2. Un peu comme si l’ordre de chargement des différents fichiers de Composer n’était pas le même qu’avec les autres…

Bref, si quelqu’un a une illumination très éclairée, qu’il ne se gêne pas. Si on en est à penser à des histoires de mauvaise compilation, c’est très loin hors de mes compétences.

Peux-tu nous donner le message d’erreur exacte ?

Fatal error: Uncaught Error: Class 'Symfony\Polyfill\Php73\Php73' not found in C:\wamp\www\instrum-partitions\vendor\symfony\polyfill-php73\bootstrap.php on line 20
Error: Class 'Symfony\Polyfill\Php73\Php73' not found in C:\wamp\www\instrum-partitions\vendor\symfony\polyfill-php73\bootstrap.php on line 20

Call Stack

#	Time	Memory	Function	Location
1	0.0012	404008	{main}( )	…\index.php:0
2	0.0017	404584	require( 'C:\wamp\www\instrum-partitions\config\bootstrap.php' )	…\index.php:7
3	0.0019	404888	require( 'C:\wamp\www\instrum-partitions\vendor\autoload.php' )	…\bootstrap.php:5
4	0.0025	405648	ComposerAutoloaderInit41362268d9f3699e48a92462341dd5d2::getLoader( )	…\autoload.php:7
5	0.0069	411400	composerRequire41362268d9f3699e48a92462341dd5d2( )	…\autoload_real.php:56
6	0.0077	411784	require( 'C:\wamp\www\instrum-partitions\vendor\symfony\polyfill-php73\bootstrap.php' )	…\autoload_real.php:66

Je conseille vivement de reprendre les points que j’ai listés dans les précédents messages 

Edit

La ligne ci-dessus, c’est surtout pour bien prendre en compte tous les essais effectués, pas parce que j’avais fourni le message auparavant.

Là l’erreur indique que ton autoload n’a pas trouvé le fichier qui correspond pour déclarer la class Php73. As-tu vérifié le chemin d’accès ?

De base polyfill est inclu par php, mais ces fonctions sont nouvelles, certaine nécessite un support lorsqu’elles ne sont pas présentes.

J’ai vérifié, le polyfill est bien installé, et le namespace cité dans l’erreur est correct ;

Sans quoi avec les même fichiers je ne pourrais pas utiliser PHP 7.1, non ? Ma logique est la suivante : si Symfony demande le polyfill pour PHP 7.3, c’est qu’il est prévu pour cette version de PHP et donc qu’il doit avoir les définitions des trucs qui n’existent pas dans la version de PHP réellement utilisée. En PHP 7.1 ,je devrais donc avoir le même problème si l’installation de cette dépendance n’était pas bonne. Or, ce n’est pas le cas.

Si tu copies la classe Php73 dans ce fichier puis tu adaptes le namespace ça donne quoi ?

Fatal error: Uncaught RuntimeException: Please run "composer require symfony/dotenv" to load the ".env" files configuring the application. in C:\wamp\www\instrum-partitions\config\bootstrap.php on line 14
RuntimeException: Please run "composer require symfony/dotenv" to load the ".env" files configuring the application. in C:\wamp\www\instrum-partitions\config\bootstrap.php on line 14

Call Stack

#	Time	Memory	Function	Location
1	0.0026	403832	{main}( )	…\index.php:0
2	0.0045	404408	require( 'C:\wamp\www\instrum-partitions\config\bootstrap.php' )	…\index.php:7

J’ai l’impression que le problème se déplace

Ok, l’autoload ne permet pas de faire ça.

Et si tu mets directement le contenu dans hrtime sans passer par p\Php73::hrtime ?

Même erreur que dans le message précédent.

Et exécuter la commande ne corrige rien ?

Le composant cité est à la base de Symfony et donc déjà installé… Mais il n’arrive pas à trouver les classes, apparemment.

Je crois que j’ai fini par comprendre.

Je viens de mettre à jour vers PHP 7.2.20, et là ça fonctionne (à noter que je n’avais pas fait le lien avec le fait que phpMyAdmin ne fonctionnait pas non plus).

Soit j’ai pris la mauvaise version de PHP (une NTS au lieu d’une TS, probablement) pour les 7.2.13 et 7.2.19, soit les liens de téléchargement étaient foireux — je doute de cette dernière possibilité, on est bien d’accord — soit il y avait bien un souci quelconque dans ces versions précédentes.

Le fait est que le souci a été constaté sur deux machines différentes. Je verrai pour l’autre d’ici la fin de la semaine, je reviendrai éditer si c’est bon, sinon je répondrai à nouveau.

Edit

Je note quand-même que PHP 7.2.20 n’existe que sur windows.php.net, depuis hier, et pas sur le "site mère"

Edit ₂

Bon, sans avoir le fin mot de l’histoire, là ça fonctionne sur les deux machines Windows où j’avais constaté le problème après avoir mis à jour vers la 7.2.20.
Après réflexion, je doute que je me sois trompé dans la version (N)TS de PHP ni même mélanger x86 et x64, parce que dans les deux cas, PHP ne pourrait même pas se charger correctement.