Php version shows 7 but composer does not work #6918
Comments
|
Pretty sure it is an issue on your end, not with Composer. You are using cPanel, that is mistake number one. Please run the following commands in your project directory directly from the command line and give us the output (unaltered): |
PHP 7.0.26 (cli) (built: Dec 4 2017 16:05:39) ( NTS )
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2017 Zend TechnologiesConfiguration File (php.ini) Path: /opt/cpanel/ea-php70/root/etc
Loaded Configuration File: /opt/cpanel/ea-php70/root/etc/php.ini
Scan for additional .ini files in: /opt/cpanel/ea-php70/root/etc/php.d
Additional .ini files parsed: /opt/cpanel/ea-php70/root/etc/php.d/02-pecl.ini,
/opt/cpanel/ea-php70/root/etc/php.d/20-bcmath.ini,
/opt/cpanel/ea-php70/root/etc/php.d/20-calendar.ini,
/opt/cpanel/ea-php70/root/etc/php.d/20-ctype.ini,
/opt/cpanel/ea-php70/root/etc/php.d/20-curl.ini,
/opt/cpanel/ea-php70/root/etc/php.d/20-dba.ini,
/opt/cpanel/ea-php70/root/etc/php.d/20-dom.ini,
/opt/cpanel/ea-php70/root/etc/php.d/20-exif.ini,
/opt/cpanel/ea-php70/root/etc/php.d/20-ftp.ini,
/opt/cpanel/ea-php70/root/etc/php.d/20-gd.ini,
/opt/cpanel/ea-php70/root/etc/php.d/20-gettext.ini,
/opt/cpanel/ea-php70/root/etc/php.d/20-iconv.ini,
/opt/cpanel/ea-php70/root/etc/php.d/20-imap.ini,
/opt/cpanel/ea-php70/root/etc/php.d/20-intl.ini,
/opt/cpanel/ea-php70/root/etc/php.d/20-json.ini,
/opt/cpanel/ea-php70/root/etc/php.d/20-ldap.ini,
/opt/cpanel/ea-php70/root/etc/php.d/20-mbstring.ini,
/opt/cpanel/ea-php70/root/etc/php.d/20-mcrypt.ini,
/opt/cpanel/ea-php70/root/etc/php.d/20-mysqlnd.ini,
/opt/cpanel/ea-php70/root/etc/php.d/20-pdo.ini,
/opt/cpanel/ea-php70/root/etc/php.d/20-phar.ini,
/opt/cpanel/ea-php70/root/etc/php.d/20-posix.ini,
/opt/cpanel/ea-php70/root/etc/php.d/20-simplexml.ini,
/opt/cpanel/ea-php70/root/etc/php.d/20-soap.ini,
/opt/cpanel/ea-php70/root/etc/php.d/20-sqlite3.ini,
/opt/cpanel/ea-php70/root/etc/php.d/20-tidy.ini,
/opt/cpanel/ea-php70/root/etc/php.d/20-tokenizer.ini,
/opt/cpanel/ea-php70/root/etc/php.d/20-xml.ini,
/opt/cpanel/ea-php70/root/etc/php.d/20-xmlwriter.ini,
/opt/cpanel/ea-php70/root/etc/php.d/20-xsl.ini,
/opt/cpanel/ea-php70/root/etc/php.d/30-mysqli.ini,
/opt/cpanel/ea-php70/root/etc/php.d/30-pdo_mysql.ini,
/opt/cpanel/ea-php70/root/etc/php.d/30-pdo_sqlite.ini,
/opt/cpanel/ea-php70/root/etc/php.d/30-wddx.ini,
/opt/cpanel/ea-php70/root/etc/php.d/30-xmlreader.ini,
/opt/cpanel/ea-php70/root/etc/php.d/30-xmlrpc.inithanks |
|
No the latest stable release for Composer is Simply run |
|
Can you also return the output of: |
|
The problem is composer version? I am running on VDS and not sure about version update as it may cause some troubles |
|
What does the following return? |
|
|
Ok, well then I cannot help you any further. It makes no sense that Composer would detect a different version based on the information you provided us. So either you have not been entirely truthful, or your environment is seriously broken. |
|
You serious ? |
|
I mean that either the information presented above has been altered for some reason (privacy or security being common ones -- people assume details are not important when they, in fact, are), or your system is just broken. Like I said before, it makes no sense for Composer to detect a different php version if all of the information provided above is accurate. |
|
Basically that is the reason why I opened issue |
Do they invoke Composer on a daily basis? No. Please update Composer to something we actually can support, and then provide the output of |
|
Thanks for reply, I will see if we can update version and get you back . |
Getting same output |
|
I am not confident that updating the Composer version will fix anything. I really think cPanel is doing something weird. There is no reason for Composer to detect another PHP version, unless it is specifically running through another version. |
|
It is awkward but |
|
What about |
Have you noticed those in last comment ? I guess that explains why it does not work , but not sure how it gets it |
|
Yes, I noticed. All signs indicate your host/environment is in a completely broken state. However none of my attempts to figure out why this is the case have proven fruitful. All of the commands I gave you to run, returned output that would suggest it should just work. Quite a puzzle. |
|
I am trying to figure out how does the composer choose an interpreter to work with ? |
|
And as I said before this came out after laravel 5.5 . there are websites running 5.2-3 without problems |
|
Have you read the cpanel docs regarding what it does with php versions: https://documentation.cpanel.net/display/EA4/EasyApache+4+and+the+ea-php-cli+Package The following may help:
Or there could be directives in a |
|
I also face the same problem:
|
|
Try |
|
I would recommend taking up the issue with cPanel support. Nothing we can do about this from the Composer end, it's a *nix level configuration issue. |
|
I also face the same issue , the server doesn't have cpanel, has both php70 and php71 running on the server. Composer version is one of the latest.
|
|
The |
|
If the directory is leading, and Composer is installed in its usual location of ln -s `which composer` composer
./composer show -p | grep phpOr, of course, if the PHP executable is selected correctly when not running it via env, just use: If that shows the "right" PHP version you can also make it transparent: alias composer='php `which composer`'And permanent: echo "alias composer='php `which composer`'" >> ~/.bashrc |
|
Thanks @curry684, your first suggestion there does seem to work! So we have 2 decent work arounds here:
or
|
|
Dare I ask if there is a particular reason why |
|
Because |
Yes, but as per your manual:
So, if not specified, the working directory will be the current directory, correct? So why different outcomes? |
|
Hate to be repeating myself, but that is only possible on a wildly misconfigured system. Hence my comment that they are different commands, you'd just logically expect the same output on a sane system, and something in cPanel is intervening. But that's the recurring theme here - all the workarounds I posted cannot make a difference on a sane system, and the fact that they do only prove what a mess cPanel and/or the ea-php wrappers are making of it. |
I hate to be repeating myself too, but it is NOT a misconfigured system. cPanel's ea-php-cli package adds the ability to be able to have different PHP versions in different directories. It's clearly explained here: https://confluence1.cpanel.net/plugins/servlet/mobile?contentId=2435150#content/view/2435150 And I believe we largely got to the bottom of why composer isn't working nicely with it. I don't see it as either composer's fault or cPanel's fault. I'm happy with the workarounds for now, but very disappointed in the unnecessary cPanel bashing. |
|
The fact that the tool is documented hardly makes its behavior suddenly normal or acceptable. It's breaking sane and expected default system behavior. So yes, to us it's also frustrating to have people complaining that a PHP tool is no longer being run by the logically expected PHP executable because they knowingly installed a tool that is explicitly and only intended to change the PHP executable used based on arbitrary local environment settings and the execution path of the code. I have helped to the best of my ability in suggesting workarounds for the issues arising from using said tool, they are confirmed to be working, and I will therefore henceforth consider this issue permanently solved and closed, and no longer respond. |
|
One idea I see for the different ea-php-cli behavior could be that it does not only look at the script being run ( But anyway, this whole ea-php-cli thing is the culprit: it is incompatible with PHP CLI tools installed globally (as is probably the case for composer in your setup) which are meant to be used by projects (as it looks at the location of composer). In any case, that is not something composer can solve, as composer is not selecting the PHP runtime. Your system does . The shebang tells the system to use |
|
I confirm my idea about the fact that Btw, this mean that |
|
Ouch, that just reduces the exposed behavior to more or less random once you start running more complex CLI scripts that work on one or more files. I'd consider that an explicit (and pretty severe) bug on their end. It also invalidates most of the workarounds I suggested as they can still be broken by adding certain arguments. |
|
well, the |
|
It likely breaks most Symfony native console commands for the same reason unless you explicitly call |
|
I had the same issue yesterday. The reason for the "PHP 5" was a global composer setting i´ve done month before. Check with:
I assume you will find a line:
To get rid of them simply use:
And remove (or adjust) the config in the editor. Hope this helps other too. |
Wow, great support here |
You do realize this is an open source project with only spare time support from a number of volunteers getting paid nothing at all? Be glad there's any support at all before complaining about the quality - if enough people with your attitude show up here it won't be long before the free support is also going to find better things to do with their life.
That is not at all what he's saying. As any IT professional with any minimal kind of real world experience can tell you, users lie all the time. Just most of the time not with bad intent or consciously, by forgetting errors, or configuration changes they made, or ignoring important output and then claiming there never was any, misrepresenting their local system, or etc. etc. In his response, @alcohol was completely correctly pointing out that the issue described was technically impossible to occur given the described circumstances. So either the description was wrong (which is not necessarily lying) or the host system was fundamentally broken. The only unprofessional thing I see here is you whining about a professional, correct and concise response from a volunteer and insulting him and his professionality. |
|
Too much noise here. It does sound like there is some unexpected behaviour when running Composer in an environment that makes use of ea-php to configure the php version on a per directory basis. Perhaps consider opening a new issue with a descriptive reproducible scenario. |
|
@curry684 no, because |
|
i have had this issue trying to 'quickly and simply' install laravel.. i needed composer and 2 days later still tryin to figure out how to update php 7.0 to php 7.2.. . . iam on wamp local host so dont think its a cpanel thing. |
|
This doesn't sound like a Composer issue. It sounds like you should be looking on the wamp forum. However, if you are on Windows, run https://getcomposer.org/Composer-Setup.exe again and point it to the version of php you want to use. |
|
You may want to try this.
|
|
run this |
|
Update Default php version in WHM to use latest php version . |
|
I have been having same issues on my localhost. To solve this issue, I edited the Finally, I reinstall composer using |
|
My previously discovered workaround of using |
|
i got the same problem and i solved it by going to Multi php Manager in WHM and change default php version from there to 7.1. |
|
@hiviyan that is just about the worst possible solution or workaround that will actively break either Composer or the project itself in most situations. As for the other commenters - you may be interested to note the issue was closed and therefore nobody is reading what you post unless someone accidentally opens it (like I do now). |
|
When u r installing composer , u need select correct php path for PHP version 7 |
|
So I am able to solve the problem by changing the version of PHP in my main 'config.php'. Before '$required_php_version = 7.2' and I had upgraded to 8.0.9 and so it was not taking the right version and so I changed it to '$required_php_version = 8.0.9'. Or here one can simply put greater than a particular version. After that change the required version of php in 'composer.json' and 'composer.lock' file to reflect the same.
|
|
I had PHP 8.0 in my composer file and got platform related issues when attempting to install.
To solve this I simply set the default PHP version in WHM ("MultiPHP Manager") This issue is 100% not related to composer and relates to something cpanel does to the php cli version. |
and others
My
composer.json:Output of
composer diagnose:When I run this command:
I get the following output:
And I expected composer to install laravel dependencies
Output of php -v
Delete all kind of caches but still no success , I don't want to update composer if possible.
Thanks
The text was updated successfully, but these errors were encountered: