Erreur fatale: composer.lock a été créé pour PHP version 7.4 ou supérieure mais la version PHP actuelle est 7.3.11

Vous pouvez exécuter la composer update à composer update pour réinstaller les versions de la bibliothèque du fournisseur compatibles avec votre version de PHP.

Cela peut vous arriver si vous disposez de 2 conteneurs Docker différents exécutant le même projet. Ils prennent à tour de rôle les demandes entrantes. Pour résoudre ce problème, recherchez un ancien conteneur Docker zombie qui utilise PHP 7.3.11 et simplement docker stop et docker rm .

Dans le dossier de votre application, créez un fichier texte et tapez 7.4 , puis renommez le fichier .php-version sans nom, juste l'extension. Et ça devrait marcher.

C'est heureusement assez facile à résoudre. Vous pouvez demander à votre composer.json d'installer des bibliothèques de fournisseurs basées sur une version spécifique de PHP.

Par exemple, nous avons un projet en cours de migration de PHP5 vers PHP7. Nous ne pouvons pas installer uniquement les versions PHP7 des bibliothèques, nous ajoutons donc ceci à votre composer.json:

  "config": {
    "platform": {
      "php": "5.3.29"
    }
  },

Vous devriez maintenant pouvoir installer. Supprimez votre composer.lock , puis lancez l' composer install !

Voici la documentation pertinente:

https://getcomposer.org/doc/06-config.md#platform

J'ai résolu ça en courant

$ symfony local:php:refresh

du dossier du projet, car la sortie de l'exécution de $ php --version m'a donné PHP 7.4.1 (cli) tandis que $ symfony php --version m'a donné PHP 7.3.13-1+ubuntu16.04.1+deb.sury.org+1 .

Après l'actualisation, ils ont montré les mêmes versions.

Edit: Cela nécessitait l'utilisation du symfony-binary

Vous devez exécuter composer dump-autoload

J'avais la même chose et pouvais le réparer en supprimant un chemin d'exportation avec php 7.2 dans mon zshrc.

le dossier php dans lequel le compositeur a installé et le serveur apache tel que xampp, wampp, la version lampp doivent être similaires.

par exemple, si la version de php avec laquelle composer est installé est 7.4 ou supérieure, la version du serveur Apache telle que xampp, wampp, lampp doit également être 7.4 ou supérieure

cela peut facilement arriver si vous avez deux versions différentes de php sur votre machine locale. Pour contourner cela, recherchez la version de php dans la console qui correspond à ce que votre serveur local exécute.

rm composer.lock
/usr/bin/php /usr/local/bin/composer install

Composer recréera ensuite le fichier de verrouillage avec la version appropriée de php.

Cela peut être dû au fait que vous avez téléchargé le fichier vendor/autoload.php généré sur une autre version de php. C'est souvent le cas lorsque vous utilisez CI / CD pour créer votre application PHP.

La meilleure approche serait donc d'exclure ce fichier de vos artefacts au lieu d'exécuter composer dump-autoload (ce qui pourrait être la dernière solution).

J'ai eu ce problème dans Azure WebApp que j'ai résolu en définissant le CGI sur la version correcte

   <handlers>
        <remove name="PHP74_via_FastCGI"/>
        <add name="PHP74_via_FastCGI" path="*.php" verb="GET, PUT, POST, DELETE, HEAD, OPTIONS" modules="FastCgiModule"
             scriptProcessor="D:\Program Files\PHP\v7.4\php-cgi.exe" resourceType="Either" requireAccess="Script"/>
    </handlers>

Avec 2 versions de PHP installées, vous avez probablement oublié de modifier le fichier etc / hosts pour le domaine de test. Ou vous devez modifier le DNS.

# etc/hosts
127.0.0.1 localhost

Je ne sais pas comment fonctionne le programme d'installation de XAMPP (puisque j'installe et configure généralement manuellement), mais je peux supposer que très probablement lors de l'installation d'un nouveau XAMPP, il a changé les chemins dans la variable PATH (pourquoi la console fonctionne avec la version 7.4 ) et ajouté des hôtes au fichier etc / hosts mais n'a pas supprimé les anciens hôtes (le site fonctionne donc avec l'ancienne version).

Dans mon cas, les versions PHP sont séparées par IP. Si vous avez 2 versions de PHP sur une IP, vous devrez alors en arrêter une pour en démarrer une autre ou séparer les versions par ports. Sinon, conflit d'intérêts.
exemple

#httpd.conf -Apache settings (Apache folder for PHP 7.4)
Listen 127.0.0.1:80

#httpd.conf -Apache settings (Apache folder for PHP 7.3)
Listen 127.0.0.1:80

//file etc/hosts
#old host -forgot to delete
127.0.0.71 demo.symfony.local 
#new host
127.0.0.74 demo.symfony.local

Résultat: localhost contactera celui qui a occupé le premier port 127.0.0.1:80 dans la file d'attente d'écoute.

Un peu tard à la fête mais dans mon cas (serveur Apache sur Ubuntu 18.04), mis à part la désinstallation des versions précédentes de PHP et l'installation de PHP v.7.4, j'ai dû supprimer php7.2.conf et php7.2.load de /etc/apache2/mods-available/ pour mon projet Symfony pour enregistrer que je suis bien sur la version 7.4. Apparemment, ces fichiers ont persisté après avoir purgé toutes les versions précédentes de PHP de mon système et installé PHP v.7.4.

Mon problème était de mettre à jour la version php avec sudo update-alternatives --config php n'a pas mis à jour php-cgi.

Symfony CLI utilisait toujours l'ancienne version de php-cgi:

sudo apt-get install -y php-cgi

Je l'ai résolu en mettant à jour php-cgi:

symfony local:php:list
┌─────────┬───────────┬────────────┬─────────┬────────────────┬─────────┬─────────┐
│ Version │ Directory │  PHP CLI   │ PHP FPM │    PHP CGI     │ Server  │ System? │
├─────────┼───────────┼────────────┼─────────┼────────────────┼─────────┼─────────┤
│ 7.2.34  │ /usr      │ bin/php7.2 │         │                │ PHP CLI │         │
│ 7.3.23  │ /usr      │ bin/php7.3 │         │ bin/php-cgi7.3 │ PHP CGI │         │
│ 7.4.11  │ /usr      │ bin/php7.4 │         │ bin/php-cgi7.3 │ PHP CGI │ *       │
└─────────┴───────────┴────────────┴─────────┴────────────────┴─────────┴─────────┘