Different PHP versions on CLI, phpinfo and Laravel exception - php

I'm currently running a shared server with the multi PHP manager cPanel extension, so I'm trying to install Laravel 5.7, but I get the following exception:
Could not find package laravel/laravel with version 5.7.* in a version
installable using your PHP version 5.6.38.
But when I run php -v, it outputs the following:
PHP 7.2.11 (cli) (built: Oct 30 2018 20:57:09) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.2.0, Copyright (c) 1998-2018 Zend Technologies
with the ionCube PHP Loader (enabled) + Intrusion Protection from ioncube24.com (unconfigured) v10.2.4, Copyright (c) 2002-2018, by ionCube Ltd.
And if I do a phpinfo(), I get the following version:
PHP Version 7.0.32
So, as you can see all 3 versions are different and I don't know what is going on, any ideas?
NOTE: I don't have super user permissions, when I run commands with sudo I get the following : sudo: effective uid is not 0, is sudo installed setuid root?

Related

Update kuduscript with php 8

We are trying to update our azure web app service to php 8.
In deployment we use kudu and app service build service.
When we try to deploy after changing to php 8 in the code we get the error that php command is not found.
And when we run compose installer we can install due to composer.lock requiering php 8.0
The only source for php 7.3 (which specifies that is the problem) is the kudu script. However we have not found a decent way of updating this to php 8. Has anyone done this?
kudu_ssh_user#:/$ php --version
PHP 7.3.27 (cli) (built: Mar 18 2021 08:28:09) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.3.27, Copyright (c) 1998-2018 Zend Technologies

composer always detect wrong version of my local php

Whenever I try to test PHPUnit or composer update, I get this error:
PHP Fatal error: Composer detected issues in your platform: Your Composer dependencies require a PHP version ">= 7.4.0". You are running 7.3.19
but when I put on the terminal: source ~/.bash_profile it reads that I have 7.4 on my local machine and all works OK. Is there any solution for that issue, to not need to put every time that command source ~/.bash_profile before every start of the console?
Before run source ~/.bash_profile:
PHP 7.3.19 (cli) (built: Jun 12 2020 00:29:59) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.3.19, Copyright (c) 1998-2018 Zend Technologies
with Zend OPcache v7.3.19, Copyright (c) 1999-2018, by Zend Technologies
After run source ~/.bash_profile:
PHP 7.4.13 (cli) (built: Nov 30 2020 14:57:43) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies
with Zend OPcache v7.4.13, Copyright (c), by Zend Technologies
I was facing the same issue, I was using command prompt for laravel artisan commands. Which was showing wrong php version. I closed it and from Xampp Control Pannel Open the Shell for artisan commands and now its detecting the correct PHP Version. It fixed my problem.

How use different versions of PHP in command line

I'm facing an issue. I've multiple projects thats using different version of PHP. I world like to have a way to define for example:
sites/project1 -> php 5.6
sites/project2 -> php 7.0
sites/project3 ->
php 7.1
I'm currently using MAMP PRO to manage web-server but my issue is regarding to command line.
I don't want to use docker or vagrant for each project just configure a specific binary php per project folder.
Is there a way to do that?
Best!
You can use phpbrew, it's very simple and convenient when you want to switch between PHP versions as well as for PHP extension management.
For changing the PHP CLI version you just run one command:
$ phpbrew list
* php-7.1.12
php-5.5.15
$ php -v
PHP 7.1.12 (cli) (built: Jan 14 2018 22:25:40) ( NTS )
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.1.0, Copyright (c) 1998-2017 Zend Technologies
with Zend OPcache v7.1.12, Copyright (c) 1999-2017, by Zend Technologies
$ phpbrew use php-5.5.15
$ php -v
PHP 5.5.15 (cli) (built: Nov 9 2018 00:22:21)
Copyright (c) 1997-2014 The PHP Group
Zend Engine v2.5.0, Copyright (c) 1998-2014 Zend Technologies
If you use MAMP your php bin files are located under:
/Applications/MAMP/bin/php/php*.*.*/bin/php
I can recommend to create alias/symbolic link for each PHP version
/Applications/MAMP/bin/php/php7.1.12/bin/php => php7.1
/Applications/MAMP/bin/php/php5.6/bin/php => php5.6
etc..

Set default version of Php in CentOS 7

I have two versions of PHP in opt/remi folder php56 and php72
but when I php -v on cmd it shows:
Copyright (c) 1997-2016 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2016 Zend Technologies
with Zend OPcache v7.0.6-dev, Copyright (c) 1999-2016, by Zend Technologies
with Xdebug v2.4.1, Copyright (c) 2002-2016, by Derick Rethans
How to set default version to PHP 7.2?
I have two versions of PHP in opt/remi folder php56 and php72
how to set default version to PHP 7.2
SCL are designed for parallel installation so don't alter default version in base system
Once the collection is enabled, the version will be used
$ scl enable php72 bash
$ php -v
PHP 7.2.8 (cli) (built: Jul 17 2018 05:35:43) ( NTS )
If you want 7.2 to be the default version (base system) you should install it, according to Wizard instructions for "Default / single version" (and keep 5.6 as secondary version)
Change php cli version in Centos 7
First, find your php7, run phpinfo() and get path or you can do with other ways. for me, it is:
/usr/local/lsws/lsphp73/
then:
cd ~
. ~/.bash_profile
And:
alias php='/usr/local/lsws/lsphp73/bin/php'
Now:
php -v
PHP 7.3.13 (cli) (built: Dec 20 2019 16:02:35) ( NTS )
Create a file "/etc/profile.d/php.sh". Use pathmunge to add the path to your php bin you want as default on line one and save the file.
Example:
pathmunge /opt/remi/php73/root/bin
Reload your profile afterwards by logging in again.
Now if you do a which php and php -v you should see the following output in my case
[root#host etc]# which php
/opt/remi/php73/root/bin/php
[root#host etc]# php -v
PHP 7.3.4 (cli) (built: Apr 2 2019 13:48:50) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.3.4, Copyright (c) 1998-2018 Zend Technologies
with the ionCube PHP Loader (enabled) + Intrusion Protection from ioncube24.com (unconfigured) v10.3.4, Copyright (c) 2002-2019, by ionCube Ltd.
This is the preferred way to accomplish this task using tools that are already supplied on a minimal install. This also allows scripts and commands to hit the correct php binaries when accomplishing other tasks. Commands like, pear, pecl, phar, php-config. You want your experience to be global when setting the default, otherwise you might wind up still getting version 5.6's tools when trying to install an extension or complete another task.
module enable php74
for your understanding:
cat /opt/remi/php74/enable
export PATH=/opt/remi/php74/root/usr/bin:/opt/remi/php74/root/usr/sbin${PATH:+:${PATH}}
export LD_LIBRARY_PATH=/opt/remi/php74/root/usr/lib64${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}}
export MANPATH=/opt/remi/php74/root/usr/share/man:${MANPATH}

Why composer uses other PHP version then php command points to?

Here's my environment configuration (Ubuntu).
I have installed PHP 5.5.9 version via apt-get, and using PHPBrew also installed version 7.0.6. The PHP7 version is turned on.
$ which php
/home/username/.phpbrew/php/php-7.0.6/bin/php
$ php -v
PHP 7.0.6 (cli) (built: May 12 2016 08:54:46) ( NTS )
Copyright (c) 1997-2016 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2016 Zend Technologies
with Xdebug v2.4.0, Copyright (c) 2002-2016, by Derick Rethans
I have composer installed globally by putting it in proper directory:
$ which composer
/usr/local/bin/composer
Now, when I run composer require <something>, it uses PHP 5.5.9 and returns error like (when the package being installed requires it of course):
Problem 1
- This package requires php >=5.6.0 but your PHP version (5.5.9) does not satisfy that requirement.
Why doesn't composer use PHP version proper for current CLI configuration?
Please note that my question is why it happens and not how to solve the problem, because I've found already a few workarounds for that. I want to understand what happens here.

Categories