J'essaie d'installer un ancien projet Laravel.
Lorsque je lance l'installation de composer, j'obtiens le message d'erreur suivant
This package requires php >=5.6.4 but your PHP version (5.5.35) does not satisfy that requirement.
Quand je cours
php -v
J'obtiens le résultat suivant
PHP 7.1.10 (cli) (built: Oct 12 2017 14:00:12) ( ZTS )
Ceci est le contenu de mon composer.json
{
"name": "laravel/laravel",
"description": "The Laravel Framework.",
"keywords": ["framework", "laravel"],
"license": "MIT",
"type": "project",
"require": {
"php": ">=5.6.4",
"doctrine/dbal": "^2.6",
"guzzlehttp/guzzle": "^6.3",
"intervention/image": "^2.4",
"intervention/imagecache": "^2.3",
"laravel/framework": "5.4.*",
"laravel/tinker": "~1.0",
"laravelcollective/html": "^5.4",
"maatwebsite/Excel": "^2.1",
"sentry/sentry-laravel": "^0.8.0",
"spatie/laravel-glide": "^3.2",
"spatie/laravel-permission": "^2.6",
"spatie/laravel-pjax": "^1.3"
},
"require-dev": {
"fzaninotto/faker": "~1.4",
"mockery/mockery": "0.9.*",
"phpunit/phpunit": "~5.7"
},
"autoload": {
"classmap": [
"database"
],
"psr-4": {
"App\\": "app/"
}
},
"autoload-dev": {
"psr-4": {
"Tests\\": "tests/"
}
},
"scripts": {
"post-root-package-install": [
"php -r \"file_exists('.env') || copy('.env.example', '.env');\""
],
"post-create-project-cmd": [
"php artisan key:generate"
],
"post-install-cmd": [
"Illuminate\\Foundation\\ComposerScripts::postInstall",
"php artisan optimize"
],
"post-update-cmd": [
"Illuminate\\Foundation\\ComposerScripts::postUpdate",
"php artisan optimize"
]
},
"config": {
"preferred-install": "dist",
"sort-packages": true,
"optimize-autoloader": true
}
}
Comment est-il possible que ce projet pense que j'ai PHP 5.6 en cours d'exécution?
Je vous remercie.
J'ai eu ce problème aussi. Si vous ne souhaitez pas mettre à jour tous vos packages compositeur, vous pouvez résoudre ce problème en modifiant manuellement le fichier composer.lock
et en écrivant votre version actuelle PHP dans platform > php
dans l'objet JSON.
Exemple
...
"platform": {
"php": "7.1"
}
...
Bien que cela fonctionne, le moyen le plus recommandé consiste à supprimer votre fichier composer.lock
, à modifier la version platform > php
dans composer.json
, puis à exécuter composer install
.
composer clear-cache
composer self-update
composer update --ignore-platform-reqs
or
composer install --ignore-platform-reqs
des informations supplémentaires et une réponse à @nicohase, Nico, vous avez raison de dire que composer n'utilise pas le même exécutable php qu'Apache. Pourquoi compositeur s'assurerait-il que php-cli répond aux exigences des autres packages requis? Ce ne serait pas et ce n'est pas le cas. L'utilisateur administre composer avec php-cli, ce qui signifie intrinsèquement qu'ils sont compatibles. Composer vérifie que la version de PHP exécutée sur le serveur Web et les autres packages sont compatibles.
Maintenant, pour ce qui est de savoir pourquoi, la méthode que j’ai énumérée et l’autre post suggèrent, sont toutes les deux des solutions probables. Composer met en cache les informations concernant le système, php et les paquetages installés pour deux raisons: 1. continuité .. 2. historique des versions. Si composer composait ses propres fichiers de cache lorsque des modifications externes se produisaient, il serait difficile de savoir quelles versions de packages étaient compatibles les unes avec les autres et à quel moment.
Donc, composer ne vérifie pas la version php lorsqu'une mise à jour ou une installation est en cours, il référence son cache. Apache trouve probablement toute référence aux versions php en cours de désactivation par l'utilisateur. Il trouvera une référence dans les fichiers cache du compositeur. Ma suggestion recommande de supprimer le cache pour cette raison. De plus, le
composer --self-update
demande au compositeur de se mettre à jour lui-même, par opposition aux paquets qu'il gère ...
composer update
à ce stade, si php avait été initialement installé avec yum/apt, puis mis à niveau par easy Apache, le drapeau --ignore-platform-reqs contournera toute fonctionnalité d’exclusion rpm pouvant encore exister les forfaits compositeur.
Sur mon hébergement mutualisé HostGator, j'ai pu résoudre ce problème en créant des alias dans mon fichier .bashrc pour la version php que je voulais utiliser:
alias php='/opt/php71/bin/php'
alias composer="/opt/php71/bin/php ~/bin/composer/composer.phar"
N'oubliez pas de source après avoir édité le fichier .bashrc: 'source ~/.bashrc'
Au cas où cela aiderait quelqu'un à l'avenir, j'ai rencontré ce problème en essayant d'exécuter la mise à jour du compositeur à partir de PHPStorm (2017.2). J'ai essayé les suggestions ci-dessus, mais aucune d'entre elles n'a fonctionné. J'ai plusieurs versions de PHP installées (5.6, 7.0, 7.1), toutes ajoutées dans les paramètres PHPStorm, afin de pouvoir basculer en fonction des exigences du projet. Quel que soit le paramètre d'interpréteur CLI sélectionné, il recherche toujours PHP 7.0 lorsqu'il appelle composer. L'exécution de composer dans un terminal en dehors de PHPStorm fonctionne sans problème (référence à la version configurée avec le chemin d'accès, 7.1). Dans mon cas, cela ressemble à un bug de PHPStorm.
c'est un problème de configuration/env. Idéalement, vous pouvez tester plusieurs versions php. Dans Apache, vous pouvez échanger les versions de la manière suivante:
Example:
Sudo a2dismod php5.6
Sudo a2enmod php7.0
Sudo service Apache2 restart
Qu'est-ce qui se passe ici, c'est quand il exécute php -v il exécute php-cli qui est configuré pour fonctionner en php7, mais peut-être que son Apache a activé la version 5.5 ... .. alors
Sudo a2dismod php5.5
Sudo a2enmod php7.0
Sudo service Apache2 restart