Laravel Compositeur voit mal la Version de PHP

Je suis en train d'installer une ancienne Laravel Projet.

Quand je lance le compositeur installer, j'obtiens l'erreur suivante

This package requires php >=5.6.4 but your PHP version (5.5.35) does not satisfy that requirement.

Quand je lance

php -v

J'obtiens le résultat suivant

PHP 7.1.10 (cli) (built: Oct 12 2017 14:00:12) ( ZTS )

C'est le contenu de mon compositeur.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 de php 5.6 exécution?

Merci.

Quel milieu êtes-vous à l'aide, Homestead? Essayez-le et retirez votre compositeur.verrouillage de fichier et de l'exécuter à nouveau
Vous avez probablement plus d'une version de PHP installée sur votre système et votre serveur web est configuré pour utiliser 5.5.35. Vérifiez votre web server, les fichiers de configuration.
c'est juste Laravel service de Voiturier.
Ne pas exécuter php -v qui vous donne un autre chargé le module php. Utilisation phpinfo() de trouver la version de la configuration de votre serveur
Sincèrement curieux, n'compositeur / artisan pas utiliser la version CLI de PHP?
que diriez -php-fpm7.1 -v?
c'est une commande introuvable. 🙂
Eh bien les gars c'est bizarre, compositeur de mise à jour a fait le tour, Et je ne suis pas un avertissement sur le fichier de verrouillage étant obsolètes...
Ce serveur web que vous utilisez?
Service de voiturier, à partir de Laravel

InformationsquelleAutor Notflip | 2017-10-17

8

J'ai eu ce problème aussi. Si vous ne voulez pas mettre à jour tous vos compositeur paquets, vous pouvez résoudre ce problème en modifiant manuellement le composer.lock fichier et écrire votre version de PHP dans platform > php dans l'objet JSON.

Exemple
```
...
"platform": {
"php": "7.1"
}
...
```
Bien qu'il travaille, le plus recommandé pour ce faire serait de supprimer votre composer.lock fichier, la modification de la platform > php version en composer.json et l'exécution d' composer install.
- "Une bonne solution! Mieux que la mise à jour, je suppose. Je suis toujours peur de quelque chose se briser après une mise à jour
- C'est une bonne solution! Merci pour l'info gd.silva. @Notflip je pense que ma réponse est travaille aussi pour vous?
- Oui, la mise à jour de tout ce qui n'est pas la meilleure option dans la plupart des situations.
- C'est une très bonne solution. Je veux juste ajouter que "plate-forme" clause doit être à l'intérieur "config" de la clause.
InformationsquelleAutor gd.silva
5
```
composer clear-cache
composer self-update
composer update --ignore-platform-reqs
or
composer install --ignore-platform-reqs
```
supplémentaire de l'information et de la réponse à @nicohase, Nico, vous avez raison quand vous dites que le compositeur n'est pas en utilisant le même exécutable php d'apache. Pourquoi serait-compositeur s'assurer que php-cli répond aux exigences des autres paquets nécessaires? Il ne serait pas et ne le fait pas. L'utilisateur est l'administration de compositeur avec php-cli, ce qui, en soi, signifie qu'ils sont compatibles. Compositeur de la vérification pour s'assurer que la version de php qui s'exécute sur le serveur et les autres logiciels sont compatibles.

Maintenant, pourquoi, tant la méthode que j'ai énumérés et l'autre post l'indique, sont les deux solutions possibles. Compositeur caches d'informations concernant le système, php et les paquets qui sont installés pour deux raisons, 1. la continuité.. 2. version de l'histoire. Si le compositeur a modifié ses propres fichiers de cache lors de changements externes s'est produite, il serait difficile de savoir quels paquets, les versions sont compatibles les uns avec les autres, et quand.

Donc, le compositeur n'est pas la vérification de la version de php lorsqu'une mise à jour ou l'installation est en cours, il fait référence à son cache. Apache probablement grep toutes les références à des versions de php qui sont en train d'être désactivé par l'utilisateur, il va trouver une référence au compositeur des fichiers de cache. Ma suggestion recommande que le cache soit supprimé pour cette raison. En outre, la
```
composer --self-update
```
raconte compositeur pour mettre à jour lui-même plutôt que les paquets dont il gère ...
```
composer update
```
à ce point si php a été initialement installé par voie de yum/apt, puis mis à niveau par facile apache, le --ignore-plate-forme-reqs drapeau de contourner n'importe quel régime exclure des fonctionnalités qui existent encore, et de permettre l'installation ou de la mise à jour du compositeur paquets.
- Pouvez-vous ajouter une explication à cela? Pourquoi pensez-vous que cela résout le problème?
- Alors pourquoi effacer le cache et mise à jour de compositeur si vous allez à la contourner avec "ignorer la plate-forme reqs" de toute façon?
- compositeur install --ignore-plate-forme-reqs est réelle magie , merci beaucoup @gavintfn
InformationsquelleAutor gavintfn
0

c'est une config/env question. Idéalement, vous pouvez avoir plusieurs versions de php pour faire des tests, dans apache, vous pouvez permuter les versions comme ceci:
```
Example:
sudo a2dismod php5.6
sudo a2enmod php7.0
sudo service apache2 restart
```
Ce qui se passe ici, c'est quand il exécute php -v, il est en cours d'exécution php-cli qui est configuré pour s'exécuter en php7, mais peut-être sa apache a 5.5 activé.
donc
```
sudo a2dismod php5.5
sudo a2enmod php7.0
sudo service apache2 restart
```
- Pouvez-vous expliquer comment changer la version de PHP utilisé par le serveur web affecte compositeur qui n'utilise pas cette version, après tout?
InformationsquelleAutor MSD
0

Dans le cas où il aide à quelqu'un dans le futur, j'ai rencontré ce problème lors de l'exécution du compositeur de mise à jour à partir de l'intérieur de PHPStorm (2017.2). J'ai essayé les suggestions ci-dessus, mais aucun ne lui a travaillé. J'ai plusieurs versions de PHP installée (5.6, 7.0, 7.1) toutes ajoutée en vertu de l'PHPStorm paramètres, de sorte que je peux changer en fonction des exigences du projet. Quel que soit sélectionnée la CLI interprète, il a toujours l'air de PHP 7.0 lors de l'appel de compositeur. L'exécution de compositeur dans un terminal en dehors de PHPStorm fonctionne sans problème (références le chemin d'accès configuré version 7.1). Dans mon cas, cela se sent comme un PHPStorm bug.

InformationsquelleAutor bfuzze
0

Sur mon HostGator hébergement mutualisé, j'ai été en mesure de surmonter ce problème en créant des Alias dans mon .bashrc fichier pour la version de php, je voulais l'utiliser:
```
alias php='/opt/php71/bin/php'
alias composer="/opt/php71/bin/php ~/bin/composer/composer.phar"
```
N'oubliez pas de source d'après l'édition de l' .bashrc fichier: 'source ~/.bashrc'

InformationsquelleAutor rwilson

Vous devez vous connecter pour publier un commentaire.