I have tried using MacPorts to update to the latest version of PHP. After typing
sudo port install php
and installing all the necessary packages, when I type php --version in the terminal, I still get:
PHP 7.3.29 (cli) (built: Aug 15 2021 23:10:16) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.3.29, Copyright (c) 1998-2018 Zend Technologies
Why does my computer still have an outdated version of PHP instead of PHP 8?
The php port in MacPorts is a shim, it only installs the /opt/local/share/doc/php/README file and depends on (currently) php82. Click one of the Files links on https://ports.macports.org/port/php/details/ to see that.
What gets run when you type php --version in your shell depends on the symlink /opt/local/bin/php, but that symlink is managed by the port select mechanism explained in the port-select(1) manpage:
port select provides a mechanism to choose from different
implementations of a common tool or port. Selecting one of the options
makes it the primary version or implementation, e.g. the one to be run
by default when you do not explicitly select a version or
implementation on the command line.
Note that port select is only for your convenience as user. It does
not, for example, affect which compiler MacPorts uses when it compiles
software, or against which copy of MySQL a port builds. If there is a
user-visible choice, it is usually offered as a variant on the port.
If the port select mechanism affects how a port builds, that should be
considered a bug.
One example is the set of MySQL and forks of MySQL, where there are
mysql51, mysql55, mysql56, mariadb, mariadb-10.0, mariadb-11.0,
percona, possibly among others. port select lets you choose which of
these becomes the version run, when you simply run mysql or other
commands from the MySQL suite.
In your case, you have probably previously used sudo port select --set php php73. To make PHP 8.2 your default, run sudo port select --set php php82. Run port select --summary to see the currently selected option.
Related
Environment:os and apache and php and mariadb version.
uname -a
Linux MiWiFi-R3-srv 4.9.0-11-amd64 #1 SMP Debian 4.9.189-3+deb9u2 (2019-11-11) x86_64 GNU/Linux
sudo apachectl -v
Server version: Apache/2.4.25 (Debian)
Server built: 2019-10-13T15:43:54
php -v
PHP 7.0.33-0+deb9u6 (cli) (built: Oct 24 2019 18:50:20) ( NTS )
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2017 Zend Technologies
with Zend OPcache v7.0.33-0+deb9u6, Copyright (c) 1999-2017, by Zend Technologies
Login mariadb with password and input status:
Server: MariaDB
Server version: 10.1.41-MariaDB-0+deb9u1 Debian 9.9
Check php-mysql:
sudo dpkg -l php-mysql
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-==============-============-============-=================================
ii php-mysql 1:7.0+49 all MySQL module for PHP [default]
Get the mysql.so library:
sudo find / -name "*mysql.so"
/usr/lib/php/20151012/pdo_mysql.so
Chekc all modules which contain mysql:
php -m |grep mysql
PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php/20151012/php_pdo_mysql.so' - /usr/lib/php/20151012/php_pdo_mysql.so: cannot open shared object file: No such file or directory in Unknown on line 0
mysqli
mysqlnd
pdo_mysql
sudo vim /etc/php/7.0/fpm/php.ini
Rewrite
; ... or under UNIX:
;
;extension=mysql.so
as
extension=mysqli.so
or
extension=mysqlnd.so
or
extension=pdo_mysql.so
Restart apache2 and mariadb database,the issue remains ,none of the three format can work,how to fix then?
pdo_mysql is not the same as mysql.so. The old mysql extension was removed in PHP 7.0. The supported extension is now only mysqli.
From there on it depends on what the software is expecting to find - if it needs the old mysql library, then you're going to have to use a shim or an older PHP version (i.e. anything before PHP 7, such as PHP 5.6).
You can use the php7-mysql-shim library or the mysql-shim library (be aware, this might incur a small performance penalty) to make a transparent mapping available that dispatches any calls to the old mysql library to the still supported mysqli library. As long as you've installed php7-mysql-shim through composer and your project uses composer, it should be loaded automagically.
A third option is to run the original code through the mysql-to-mysqli rector configuration, but if this is not your own code, that will be hard to maintain in the future.
The .so file that can't be loaded might be because of permission issue. Make sure to ls -al that file and correct any ownership or permission issues (chmod og+r <filename>, probably).
Remove php and related packages.
sudo apt-get autoremove php7*
sudo find /etc -name "*php*" |xargs rm -rf
sudo apt purge `dpkg -l | grep php| awk '{print $2}' |tr "\n" " "`
Check.
dpkg -l | grep php7.0
Install.
sudo apt-get install php php-mysql
At last my issue solved.
MatsLindh is right, mysql is deprecated from php 7, it seems that you have deployed old php5 code on the server that is why you received this error, now you can do two things
either install php5.6 and select the version for that website folder depending on which hosting you have and restart the server
or you can upgrade the code to php 7+ either yourself or by using tools which I do not know if it works perfectly, recently I came across this
Rector Tool for upgrading php legacy code
We were down the same path in previous months and and we updated mysql code to mysqli and also updated the classes declarations and added the necessary checking, fixed the error handling and we were able to run the legacy app on the php 7 successfully.
Sometime due to complicated development, it is not possible to upgrade in an instant and it is also not possible to start from the scratch either because of the business logic introduced over the years so changes can only be introduced with baby steps, I can say this because we handle our high traffic ecommerce site.
As others have stated, though without a source, the mysql extension (ext/mysql) was deprecated in 5.5 (per RFC: ext/mysql deprecation) and removed in 7.0 (per RFC: Remove deprecated functionality in PHP 7).
(This is the git commit that actually removed ext/mysql from PHP, as linked to from the removal RFC - this link was added by the RFC author [nikic])
This is also mentioned all throughout the ext/mysql manual on php.net, though it doesn't link to any other notes concerning the deprecation and subsequent removal.
If you view the backwards-incompatible changes page for 7.0 then it further mentions that all mysql extension functions were removed, and provides a link to help in choosing a new MySQL API. This provides the support and path necessary for moving on from ext/mysql.
Avoid using a quick fix that will make your application support the old php-mysql driver. There is a reason that it was removed from php.
You can use the successor of php-mysql which is the MySQLi driver, the name MySQLi actually means MySQL-improvedand as you can understand is an improved version of the MySQL driver that gives the developer more benefits.
You may also use the PHP Data Objects (PDO), an extension that defines a lightweight, consistent interface for accessing databases (MySQL is one of them) in PHP.
This would mean that you would have to re-write pieces of code related with database handled information. If you wrote a class for it then you only need to re-write that class only. If all the MySQL related functions are written in all your application then you have a lot of work.
DO NOT USE THE OLD MySQL EXTENSION OR SOMETHING POINTING THAT BY USING A QUICK FIX.
Do some further reading of your own to judge for yourself what would be the best practice for this situation, MySQLi Wiki, Introduction to PDO, MySQLi Overview.
The First thing that you need to check for this issue is PHP version compatibility with the existing CMS Version.
In most of the cases the error due to that only.
If you are using the domain hosting and have a various site in that, you can also switch the PHP version in one sub domain only by this Htaccess file.
Like this - FcgidWrapper "/home/httpd/cgi-bin/php53-fcgi-starter.fcgi" .php
Thnak you!
Good day,
Just to clarify, I'm asking about macOS Server, the application published by Apple. I'm not referring to the system's PHP version.
I've looked everywhere, Google, SO, forums, for quite some time and haven't found a solution.
I'm unable to upgrade my PHP version for macOS Server no matter what I try. There's just simply no documentation.
I've updated the app from the App Store, I've upgraded my PHP version on my Mac, and I've changed the PATH to reflect the new PHP install, and when I do php -v in Terminal, it shows the correct version I want.
However, macOS Server seems complete unaffected by it. I tried looking around everywhere possible, but I don't see a separate install of PHP for Server, and I looked in the config files, everywhere, but can't see where and which PHP it's using.
Any help?
EDIT: I just realised that it's a whole application which many parts actively use PHP, and upgrading it on my own may break those things, but I'm willing to give it a shot, if it's at all possible. I mean, the worst that can happen is for me to delete and re-install Server, right?
Installing php on macOS
Honestly, you sound like you know more about this than is evident in the question. So you probably know a lot of this, but I wanted to be as complete as I can, from my experience, since these responses remain for others who may locate them in the future and find the information useful. If I have left anything out, I hope someone will point it out for me so I can learn a bit more along the way.
Back in the day, then thunder gods ruled the world:
php has come bundled standard on Macs since Mac OS X version 10.0.0, as you can read about here. The first version of Mac OS X Server (1.0) was a hybrid of OPENSTEP from Steve Jobs' NeXT Computer and Mac OS 8.5.1 released in 1999.
Starting with Mac OS X 10.7 (Lion) Mac OS X and Mac OS X Server have been combined into one operating system package and the macOS Server is an add-on package available through the App Store. This means that you can't really worry very much about ruining anything too important.
You can't always get what you want ...
A lot of the value in this response will depend on what you use the Server package for. If you only use the web server for a development environment, it can easily be replaced with any version of the typical LAMP (linux-apache-mysql-php) style environment.
For macOS, this means upgrade apache, install php, and install MySQL if you cannot use SQLite that comes bundled with macOS. Here is one of the many great tutorials available online. (no affiliation) It can get complicated ...
Another option that is popular, but that I haven't used myself, is the non-profit XAMPP. They are focused on making it simpler to setup php development, Wordpress, Drupal, e-commerce, and popular open source apps.
When you're a stranger ...
If you are using some of the more esoteric apps that came with the server package, you will have to upgrade them separately. But since you are asking about php and the server recognizing it, I'm assuming you are talking about the web server and that you are using something like this to see what php version apache is finding:
<?php phpinfo(); ?>
Most likely, what you are saying is that the command line php version shows correct versions and settings, but the web page version served by apache shows the old version. Is that right?
Version and File Locations:
I'm not sure if you have checked for this, but the first thing I would do is find out for sure what the path is and what version I am using. This also gives me a quick direct link to the ini file so I can go break stuff faster. Here are my results (screenshot at the end) using php --version and php --ini:
$ which php
/usr/local/bin/php
$ php --version
PHP 7.3.6 (cli) (built: May 31 2019 23:38:25) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.3.6, Copyright (c) 1998-2018 Zend Technologies
with Xdebug v2.7.0, Copyright (c) 2002-2019, by Derick Rethans
with Zend OPcache v7.3.6, Copyright (c) 1999-2018, by Zend Technologies
$ php --ini
Configuration File (php.ini) Path: /usr/local/etc/php/7.3
Loaded Configuration File: /usr/local/etc/php/7.3/php.ini
Scan for additional .ini files in: /usr/local/etc/php/7.3/conf.d
Additional .ini files parsed: /usr/local/etc/php/7.3/conf.d/ext-opcache.ini
A touch too much:
Using php -i will output an enormous amount of information. It is many pages ... more than you would ever want. If you are looking for specifics, you can grep it for whatever you like: php -i | grep ini or php -i | grep -- '--with' to look for options.
Hiding in plain sight:
Most likely you are checking, testing, and upgrading the wrong installation of php or apache. macOS is infamous for having standard versions of many programs and it will likely break something if you upgrade the 'system' version of any of them.
Ruby and Python are the most common ones to cause problems for me. I have never had any issue with php, but there and many workarounds available for many programs (e.g. coreutils for gnu).
Homebrew!
The easiest way I have found is to use Homebrew to install a separate version that you can manage and upgrade as you like and link it somewhere early in your path so it is always the first version found.
$ brew install php
It does everything for you and keeps it updated. It also allows php to always be running as a service using brew services start php. This reduces startup time and prevents some multiple version issues. A list of all brew services and status info is, as you might expect, found with brew services list. If you update any config or ini files, you should restart php (and apache) with brew services restart php. You can also still use launchctl and apachectl if you choose.
Apache!
The other handy thing about homebrew is that you can use it to install and manage apache2, also. Try this:
$ brew install httpd
$ brew services start httpd
$ httpd
Non-alcoholic recipe:
If you prefer to abstain and not use homebrew, you can install any version you wish from php.net and make a link in a directory early in your PATH. Patches and upgrades are regular and everything is extremely professional and well (over?) documented.
Download a php binary, check it with the provided signatures, and link it somewhere on your path: ln -s /path/to/new/php ~/bin/php or somewhere else if you don't use your /home/bin. Homebrew puts the link in /usr/local/bin by default.
No matter which method you choose, after you install the programs you will definitely have to adjust a few settings. There are several great posts online about this. This one is a multi-part series and is updated for Mojave. The main information to get you started should be available as shown in the screenshot below.
I've tried to build php7 with the command below:
./configure --prefix=/root/testphp --with-openssl --enable-zip --enable-mbstring --with-pdo-mysql --enable-static
make
make install
And then I try to run it on compile machine, it worked like this:
[root#guningvm ~]# /root/testphp/bin/php -v
PHP 7.3.4 (cli) (built: Apr 8 2019 11:25:09) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.3.4, Copyright (c) 1998-2018 Zend Technologies
But when I mount the dir /root/testphp on an alpine docker container:
docker run -itd --name "testforphp" -v /root/testphp/:/usr/local/php/ alpine:3.7
And run php command in the container with /usr/local/php/bin/php -v, it got wrong with sh: /usr/local/php/bin/php: not found
Could anyone tell me why it didn't work?I've taken a lot of time with this problem.Thanks a lot.
It's not entirely clear, but it seems you are building PHP on your local Linux machine (say, Ubuntu), and trying to run it on an Alpine container.
I'm also assuming you have good reasons for building PHP from source - otherwise, you could use the available PHP builds for Alpine.
Building on non-Alpine Linux and running the resulting executable on Alpine usually won't work, since Alpine Linux uses a special libc (Standard C library) implementation called musl libc. musl is not compatible with the GNU C Library - glibc, used by most other Linux distros, so for running native software on Alpine Linux, it must be built against that same, musl libc library.
The /usr/local/php/bin/php: not found error message is quite confusing, and assuming the file is present is likely to result from a dynamic linking failure. You could verify that using ldd /usr/local/php/bin/php.
Therefore, you'll have to link PHP against the musl C library for running on Alpine, and most preferably, on an Alpine machine.
I can think of the following options:
Build PHP on an Alpine container. I'm not sure whether the main development PHP branch supports this (for example, OpenJDK Java Alpine support is developed under seperate projects, named IcedTea and Portola), but it is well worth a try. I believe it is possible, since PHP builds are available for Alpine - try following their build recipe, if you encounter difficulties. This is the best option, in my opinion.
Keep building PHP on your non-Alpine Linux machine, but link it against the musl libc binary (usually available through packages), instead of glibc. This may be more difficult to achieve, and more prone to issues, so less recommended.
Run your built PHP on a glibc-enabled Alpine container. This is a fairly simple procedure. However, this option is probably not a viable one, since your PHP would still be non compatible to vanilla Alpine, and can't be used by PHP Alpine users out-of-the-box. Plus, adding glibc to the container has several MB overhead, which conflicts with your goal for minimal size.
Devils advocate answer:
If your host os was, say, fedora 30 and your container was based on a fedora 30 image, this would work fine.
But then again, we go back to my initial comment about how this isn't the way we use containers.
I'm currently using Raspbian Wheezy 7.0 right now. Since PHP 5.6 is not available on the apt repositories for wheezy, I decided to build it from source. The build worked perfectly, I didn't receive any errors from it.
So when I used php -v it gave me the following output.
PHP 5.6.10 (cli) (built: Sep 18 2016 09:23:21)
Copyright (c) 1997-2015 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2015 Zend Technologies
Ok, I thought. Perfect, everything is updated like it should be.
Here's where the problem comes in. For some reason, when I use phpinfo() on my apache2 server. It says that I'm still on version 5.4.45.
My first guess was that the module apache was using libphp5.so located in /usr/lib/apache2/modules/ was out of date. But, I have no idea where the libphp5.so module is for the new php version that I just installed is.
It'd be great if anyone could help me with this or point me in the right direction. I'm using Apache version 2.2.
As you can see from your console, php -v is the CLI binary. When building PHP you can build many different binaries for different SAPIs (Server APIs), one of them being CLI. Apache2 Handler or mod_php would be another one. In order to build your PHP as an Apache httpd module you need to make sure you include the --with-apxs2 configuration option when compiling from source. This means running ./configure --with-apxs2 before you make; make install; the binary. You then need to make sure to load the newly built libphp5.so or mod_php.so (however you built it) to the appropriate directly and load it from your Apaache httpd config. Where your newly compiled binaries are stored, depends on your compile time configuration options and environment, but typically they are located in $PREFIX/$HOME/bin. So for example, if you compiled --with-prefix=/usr you might get /usr/php/bin/libphp5.so, but typically the binary is moved for you by make install. You do need to make sure you restart httpd for the newly built binary to be loaded.
See the PHP manual on installation for more details.
I am trying to install composer on my shared host for the first time.
When I run curl -sS https://getcomposer.org/installer | php
I am getting a Composer successfully installed
User it: php composer.phar
when I run php composer.phar i am getting this warring error:
Warning: Composer should be invoked via the CLI version of PHP, not the cgi-fcgi SAPI
any ideas on how to fix this ? and why i am getting this error ? :(
when I run php -v i get this back
PHP 5.4.39 (cgi-fcgi) (built: Mar 25 2015 14:20:20)
Copyright (c) 1997-2014 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2014 Zend Technologies
with Zend Guard Loader v3.3, Copyright (c) 1998-2013, by Zend Technologies
Do I need to run this using CLI version if so how would i do this ?
Any help would be nice thank you.
I resolved this by explicitly calling the version of PHP it asked for. Keep in mind that on a shared server environment there is often multiple versions of PHP running and even though you may have set up your default in your cPanel config, bash commands often resolve to another (lower) version.
First, I created a bin directory and moved composer.phar into it. Then, I added this alias to my .bash_profile and it worked like a charm:
alias composer="/usr/php/54/usr/bin/php-cli ~/bin/composer.phar"
Hope this helps!
As Composer is now available via WHM you can use this to find it:
which composer
This returned path "/opt/cpanel/composer/bin/composer" for me. If this returns nothing then disregard the rest of this answer, as Composer is not available to you at system level.
You can now use php-cli to call this with Composer's absolute path:
php-cli /opt/cpanel/composer/bin/composer install
php-cli /opt/cpanel/composer/bin/composer update
php-cli /opt/cpanel/composer/bin/composer require whatever/example
You may however need to alias php-cli if your system claims this isn't found. It very much depends how PHP has been deployed on the WHM server. You can do this by adding a user alias to the end of your ".bashrc" file as follows:
alias php-cli=/opt/cpanel/ea-php72/root/usr/bin/php
Replace ea-php72 with the release of PHP you want to use. Submit this as a command in the shell to make it available immediately, otherwise it'll become available when you open your next Bash session.
If you want to make this available with just composer alone you could create this alias again in ".bashrc":
alias composer=/opt/cpanel/ea-php72/root/usr/bin/php /opt/cpanel/composer/bin/composer
Or
php-cli $(which composer) ...
The location of the php versions installed will vary from host to host. Try finding them with:
locate /bin/php
For me this lists all php versions and I can then replace php with, for example:
/usr/bin/php71-cli
To access the command line interface version rather than the default cgi one. Then as stated by #Diggery you can create an alias.
alias composer='/usr/bin/php71-cli bin/composer.phar'
There are many suggestions on StackOverflow on how to test for a cli installation but the above is the only one that worked for me.
I have made a script to handle changes in composer/vendor. The script works with ftp-only servers, sends/removes only the changed files. Maybe someone will find it useful.
https://github.com/psad73/tune-composer