Presta atención ya que en este enunciado hallarás la contestación que buscas.
Solución:
He tenido este problema también. Si no desea actualizar todos sus paquetes de compositor, puede resolver este problema cambiando manualmente el composer.lock archivo y escribiendo su versión real de PHP en platform > php en el objeto JSON.
Ejemplo
...
"platform":
"php": "7.1"
...
Aunque funciona, la forma más recomendada de hacerlo sería eliminando su composer.lock archivo, cambiando el platform > php versión en composer.json y luego ejecutando composer install.
composer clear-cache
composer self-update
composer update --ignore-platform-reqs
or
composer install --ignore-platform-reqs
información adicional y respuesta a @nicohase, Nico, tiene razón cuando afirma que el compositor no está usando el mismo ejecutable php que apache. ¿Por qué Composer se aseguraría de que php-cli cumpla con los requisitos de los otros paquetes requeridos? No lo haría y no lo hace. El usuario está administrando composer con php-cli, lo que inherentemente significa que son compatibles. Composer está comprobando que la versión de php que se ejecuta en el servidor web y los demás paquetes sean compatibles.
Ahora, en cuanto a por qué, tanto el método que enumeré como el que sugiere la otra publicación, son soluciones probables. Composer almacena en caché información sobre el sistema, php y los paquetes que están instalados por dos razones, 1. continuidad… 2. historial de versiones. Si Composer modificara sus propios archivos de caché cuando ocurrieran cambios externos, sería difícil saber qué versiones de paquetes eran compatibles entre sí y cuándo.
Por lo tanto, el compositor no verifica la versión de php cuando se realiza una actualización o instalación, sino que hace referencia a su caché. Es probable que Apache greps cualquier referencia a las versiones de php que el usuario está deshabilitando, encontraría una referencia en los archivos de caché del compositor. Mi sugerencia recomienda que se elimine el caché por ese motivo. Además, el
composer --self-update
le dice al compositor que se actualice, a diferencia de los paquetes que administra…
composer update
en ese momento, si php se instaló inicialmente a través de yum/apt y luego se actualizó con apache fácil, el indicador –ignore-platform-reqs eludirá cualquier funcionalidad de exclusión de rpm que aún pueda existir y permitirá la instalación o actualización de los paquetes del compositor.
En caso de que ayude a alguien en el futuro, me encontré con este problema al intentar ejecutar la actualización del compositor desde dentro de PHPStorm (2017.2). Intenté las sugerencias anteriores, pero ninguna funcionó. Tengo varias versiones de PHP instaladas (5.6, 7.0, 7.1), todas agregadas en la configuración de PHPStorm, por lo que puedo cambiar según los requisitos del proyecto. Independientemente de la configuración del intérprete CLI seleccionado, siempre busca PHP 7.0 cuando llama al compositor. La ejecución de composer en una terminal fuera de PHPStorm funciona sin problemas (hace referencia a la versión configurada de la ruta, 7.1). En mi caso, esto se siente como un error de PHPStorm.
Sección de Reseñas y Valoraciones
Si guardas algún reparo y capacidad de progresar nuestro tutorial eres capaz de dejar una glosa y con gusto lo observaremos.