(How-To) Centos 7 - Upgrade to PHP 5.6, 7.0, 7.1, 7.2 (Remi)

21 posts / 0 new
Last post
#1 Mon, 02/20/2017 - 01:33
Diabolico
Diabolico's picture

(How-To) Centos 7 - Upgrade to PHP 5.6, 7.0, 7.1, 7.2 (Remi)

IMPORTANT NOTE:
- This guide will UPGRADE PHP5.4 to PHP 5.6, 70, 71 or 7.2, so this isnt side-by-side installation!
- Make full backup of your server and i cant stress enough this part!
- All what you see in this post i tested on my server. If you didnt make some major (deal-breaking) changes it should work without any problem.
- In case you have installed other PHP versions (side-by-side) it would be smart to remove them before proceeding with this guide.
--------------
IMPORTANT NOTE # (New):
- I just updated this guide up to PHP 7.2.
- Originally this post was made for PHP 5.6 upgrade but i moved away from this version and now i'm currently testing 7.2.
- Details about the upgrade to 7.0, 7.1 and 7.2 can be found at the bottom of this post.

I saw many topics from people asking how to upgrade their Centos 7 native PHP 5.4, or they encountered some problems during/after the upgrade. There are good tutorials how to do this but each one of them was missing something, so i decided to go on my test VPS, check every step of the installation and write it down as simple as i can.


Basic info:
- OS: Centos 7
- PHP: 5.4
- Extra PHP modules: Zend opcache (separate install on PHP 5.4)
- Other PHP versions: None
- Repo needed for this guide: Remi, Epel


Now the tutorial:

1. Disable any extra repository you have installed with yum-config-manager --disable repository_name, but leave Epel and Remi in case you have it.

2. Update your existing software with yum update and press y + enter when asked. After the update run yum clean all.

3. Install Epel (skip if you already have it): yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm.

4. Install Remi (skip if you already have it): yum install http://rpms.remirepo.net/enterprise/remi-release-7.rpm.

5. Enable both repos with yum-config-manager --enable epel and yum-config-manager --enable remi-php56/php70/php71/php72 (use only one, e.g. yum-config-manager --enable remi-php71).

6. Install "yum-utils": yum install yum-utils.


This is the part where i did slightly different then suggested from many guides. Skip steps 7, 8, 9 and 11 if you dont have any obsolete modules or you previously upgraded PHP 5.4 to newer version (must be Remi).

7. Run yum check-update and write down or copy the results. If you have PHP modules that are obsolete i would suggest to remove them with yum remove php-* (e.g. yum remove php-mysql).
My case:
Check-update reported that php-mysql-5.4.16-42.el7.x86_64 and php-pecl-zendopcache-7.0.5-1.el7.x86_64 are obsolete, other modules will be updated plus some dependencies installed.

8. Write down or copy the results of step 7 so you can later install all missing modules.

9. Restart httpd systemctl restart httpd.


Now we are going to upgrade PHP to 5.6.

10. Upgrade PHP with yum update and press y + enter when asked.
Note:
During the upgrade there is a chance you will see messages like PHP Warning:  Module 'some-PHP-module' already loaded in Unknown on line 0 but they are safe to ignore.

11. Hope you saved the results from step 7 because now we need them. Check what modules were obsolete and removed and now we will bring them back with yum install php-** (e.g. yum install php-mysql). Pay attention that some modules could have different names in never PHP versions so you should check (Google or Remi website) before proceeding with this task.

12. Restart httpd systemctl restart httpd.

13. Run yum clean all.

14. Update your phpMyAdmin. Easiest way would be Virtualmin -> Virtual_server_name -> Install Scripts -> Installed Scripts and there you will have an option to update your phpMyAdmin. Currently last version is 4.7.4.
Note:
After the first upgrade from PHP 5.4 to newer version you will almost certainly have a phpMyAdmin update waiting for you.

15. Run find / -name " * .rpmnew" and find / -name " * .rpmsave" (remove spaces before/after "*") and see if anything related to PHP comes out. If there are any .rpmnew and .rpmsave files related to PHP you should compare them with the old files and if needed modify them (the old one). Dont forget to run systemctl restart httpd once you are done with modifications.


Few test to see if everything works. The results you see are from my test server with PHP 7.2.

16. SSH:

[root@##### ~]# php --version
PHP 7.2.0 (cli) (built: Nov 28 2017 20:22:21) ( NTS )
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.2.0, Copyright (c) 1998-2017 Zend Technologies
    with Zend OPcache v7.2.0, Copyright (c) 1999-2017, by Zend Technologies



17. Virtualmin:

The status of your system is being checked to ensure that all enabled features are available, that the mail server is properly configured, and that quotas are active ..
- - - - - -
    Apache is installed.
    The following PHP versions are available : 7.2.0 (/bin/php-cgi)
- - - - - -
.. your system is ready for use by Virtualmin.




How to upgrade to other PHP versions (7.0, 7.1, 7.2)

19. If this is first upgrade from default PHP 5.4 to 7.0, 7.1 or 7.2 follow all earlier mentioned steps.

20. If you already upgraded PHP 5.4 to never version then skip step 7, 8, 9, 11 and follow the rest.

21. Dont forget to replace php56 with php70, php71 or php72.

22. Keep in mind that some modules could not be available for PHP 7.*, but if you didnt install anything "exotic" you should be fine.

23. There is a chance you will have some/many deprecated records inside the old *.conf files and you should remove them accordingly.

24. Some preliminary test with Wordpress, Divi theme and PHP 7.2 didnt show any problem, but if you want to play a little safer then go for 7.0 or 7.1.

25. What i saw until now all benchmarks show PHP 7.2 as fastest PHP ever released. If speed is important for you then i would suggest to test it first and if your software/scripts doesnt complain switch to this PHP version. PHP 7.2 is fast, some results show speed increase from 9-10% up to more than 20% compared to 7.0/7.1 and 2x-3x+ better than 5.6.


Short Q&A:

- Why not side-by-side install?
Because almost everything you have in PHP 5.4 is available in never versions, so i didnt see any point to have multiple PHP versions. Every CMS or software should work 100% up to PHP 7.1 and if it doesnt that means its time to change it for something newer and better maintained.

- How long will my PHP be updated?
PHP 5.6: December 2018
PHP 7.0: December 2017
PHP 7.1: December 2018
PHP 7.2: December 2019

- My PHP isnt working.
At the end of the day its your server and your responsibility to maintain or find someone for this job. Like i mentioned at the beginning of this post i tested each and every step to ensure everything is working. If something went wrong probably you didnt properly follow each step or your server had some other software installed what could be the cause for this installation to fail.

- SAVE!!! the old and new files off-server for the sake of your nerves and health!


I hope you will find this guide useful as i did my best to explain each step and it should be relatively easy to follow. Enjoy your Centos 7 with PHP 5.6, 7.0, 7.1 or 7.2.


Last revision: 30.11.2017.
- Until now i didnt encounter any problem so i can expect that future Remi updates/new versions will follow this trend. Thats why i dont see any reason to continue to update this post and this is my last revision (i hope).

Tue, 02/28/2017 - 19:39
samrich

Diabolico,

This has been a great set of directions! I have one question and it is about number 15 under "Last few steps."

I too only had one file: /etc/httpd/conf.d/php.conf.rpmnew

When I look in that directory, I see the php.conf.rpmnew file along with what I assume is the old file, php.conf. Both of these files are different from each other. What should I be changing here? This part got a little confusing.

Thanks for the help.

Tue, 02/28/2017 - 22:40
Diabolico
Diabolico's picture

Always take your original file as base for any changes and never the new one. Best would be to compare both files and see if there are any major changes. Usually the new file will have a lot of options turned off by default but what you must watch is the deprecated functions what could come with never software version. Speaking of php.conf i didnt have to change my original (old) file but this can be different for others, thats why is important to check each of this files.

Last but not least, there isnt any rules when it comes to this subject so its really up to the server owner (or person who is managing the server) to check each file and make their own decision what to do.

Edit: Forgot to mention, always save the old file BEFORE any changes and the new file (.rpmnew, .rpmsave) offserver, just in case your changes broke something so you can quickly revert back and see what went wrong.

- I often come to the conclusion that my brain has too many tabs open. -
Failing at desktop publishing & graphic design since 1994.

Tue, 03/28/2017 - 20:59
applejack

I would be very wary of updating to using only PHP7+ since many Wordpress plugins are not yet compatible (Bloom from Elegant Themes since you mentioned Divi being one of them "allegedly"). But of course it depends what sites your server is running which is why is use Software Collections to run multiple versions of php from 5.4 as the core then 5.5, 5.6 and 7. Sites able to run on PHP7 are noticeably quicker and this is on an already fast server.

Wed, 03/29/2017 - 01:43
Diabolico
Diabolico's picture

You are right @applejack but that is a just devs and their bad coding and anyone have full right to rub this mistake in their face. Four months in 2017 and there isnt any excuse for a developer to not have proper code ready for PHP 7. To be honest i didnt test Bloom (only Divi) so thanks for the info, but i said in my OP that everyone should test their website before the upgrade.

While i understand the logic behind multiple PHP versions in the same time i'm not a person who is easy to forgive devs omissions or lack of care for their products. At least PHP 7 show us the difference between good and bad coding/devs, and if their product isnt ready for PHP 7 there are many others on the market who will support this PHP version without any problem.

- I often come to the conclusion that my brain has too many tabs open. -
Failing at desktop publishing & graphic design since 1994.

Wed, 03/29/2017 - 05:24
applejack

Or you have clients who either aren't interested in updating their sites or don't want to pay no matter how many times you suggest it to them for all the good reasons we know. I still have some clients sites which will barf on anything above 5.4

Wed, 03/29/2017 - 15:04
Diabolico
Diabolico's picture

Well all my clients have full managed solution and they only care their website is working. How this is accomplished isnt important and i have all the freedom to do what i want, so of course i'm always pushing for the higher limits.

- I often come to the conclusion that my brain has too many tabs open. -
Failing at desktop publishing & graphic design since 1994.

Thu, 11/30/2017 - 03:43
Diabolico
Diabolico's picture

This is last update of my initial post and you should be good to go from now on. After extensive test with 5.6, 7.0 and 7.1 i never had any problems, Wordpress with Divi theme and few addons never complained. Currently testing 7.2 and so far the situation didnt change, so i would say it works but because of short time period i cant be 100% sure. Still based on all my previous test i have done i think PHP 7.2 is just another great improvement while waiting for PHP 8.0.

- I often come to the conclusion that my brain has too many tabs open. -
Failing at desktop publishing & graphic design since 1994.

Sat, 03/31/2018 - 14:21
diegoweb

Hey buddy! My fresh virtualmin installed PHP 5.4 and PHP 7.0.10, but when I go to SSH and type php -v is shows PHP 5.4 as default.

[root@server ~]# php --version
PHP 5.4.16 (cli) (built: Mar  7 2018 13:34:47)
Copyright (c) 1997-2013 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2013 Zend Technologies

How can I make CentOS run php 7.0 instead of php 5.4 in bash/ssh?

I was looking for a way to add php70 to the system path but until now I got not luck. I have no interest to have PHP 5.4 running in my system, but since Virtualmin installed PHP 7.0 together with it, I wanna make it as default even for webmin/virtualmin and system.

I tried to follow your guide but I got some errors and I had to restore my VPS. Is there a easier way to just add php70 to the path that you know (maybe even replacing php54?

Thanks!!!

Sat, 03/31/2018 - 20:07
cruiskeen

It's not clear to me if you followed these instructions (in which case you'd only have one version of php) or did side-by-side installations of php. If so you should read about how SCL packages work on CentOS but the simple answer (assuming you installed the SCL packages) is scl enable php70 bash

Sat, 03/31/2018 - 20:27 (Reply to #10)
diegoweb

I did follow this instruction. But my virtualmin installed PHP 5.4 and PHP 7.0 simultaneously. When i type scl enable php70 bash it returns:

[root@server ~]# scl enable php70 bash
Unable to open /etc/scl/conf/php70!

When I type scl -l it returns:

[root@server ~]# scl -l
rh-php70

So I type scl enable rh-php70 bash and I get no error message, but if I type php70 or rh-php70 I get:

[root@server ~]# php70
bash: php70: command not found
[root@server ~]# rh-php70
bash: rh-php70: command not found

---------EDIT Nevermind, I got it working :D

Sun, 04/01/2018 - 07:55
Diabolico
Diabolico's picture

I did everything i know to make this instructions easy to follow and only thing left would be to personally install a never version of PHP. This instructions should work for any future Vritualmin and Remi/PHP versions, well at least until Virtualmin doesnt make some ground-breaking changes (not likely to happen).

Last but not least, with this instructions there is no way to install two (or more) PHP versions simultaneously. For me looks like you didnt follow the instructions or there was something previously installed what could trigger such problems.

- I often come to the conclusion that my brain has too many tabs open. -
Failing at desktop publishing & graphic design since 1994.

Tue, 04/03/2018 - 09:27
Jfro

We did it some other way arround changing the repolists with remis php 5.6.x fpm working for more then 6 months now. So 1 PHP version should be possible.

Problem is still with also virtualmin's php themselves if using fpm only 1 version! ( own / separate userpools)

Probably with more knowledge more is possible to configure!

apache with http2 and so on working here it seems.

With remi's installing first and editing repolists wich versions repos for php was my way.

centos 7.4.x

Sun, 07/22/2018 - 07:15
Kvark
Kvark's picture

Hello, have inssue with updating php to ver 7.1 and 7.2 - websites now start downloading php files instead of opening them in browser, is that something related to apache configuration change on update process or its missing something where?

Mon, 07/23/2018 - 02:52
Jfro

Use only one version is in manual abov. 5. Enable both repos with yum-config-manager --enable epel and yum-config-manager --enable remi-php56/php70/php71/php72 (use only one, e.g. yum-config-manager --enable remi-php71).

So take a look in text above also for how to upgrade, if still 2 remi php are enabled .......

by default but what you must watch is the deprecated functions what could come with never software

Mon, 07/23/2018 - 04:24
Kvark
Kvark's picture

yes instalation goes well, no warnings no error, via virtualmin can switch bitween versions, but php files continue to be downloading... :/

Mon, 07/23/2018 - 08:59
Jfro

I don't use that version so sorry.

Did you updated only php? Or also more as https://www.virtualmin.com/node/58104

Mon, 07/23/2018 - 18:56
Kvark
Kvark's picture

Found solution! :) checked this file: /etc/httpd/conf.d/php.conf - and put comments on every line #

after update older one was renamed as .rpmnew and new one has uncomented SetHandler and other stuf that make Apache disorentated :)

Tue, 10/16/2018 - 20:12
diegoweb

It seems there is a bug in REMI repo. I have also tried to enable REMI-SAFE but it didn't work. I have also posted in their github issue page. https://github.com/remicollet/remirepo/issues/109

A dependency called libtiff.so.5 seems to be missing from their repo. https://rpms.remirepo.net/enterprise/7/remi/x86_64/ https://rpms.remirepo.net/enterprise/7/safe/x86_64/

This is what I get when I run yum update with only EPEL, REMI-PHP72 (and I have tried with REMI-SAFE enabled too, without success).

[...]
---> Package php-xmlrpc.x86_64 0:5.4.16-45.el7 will be updated
---> Package php-xmlrpc.x86_64 0:7.2.11-1.el7.remi will be an update
--> Running transaction check
---> Package gd-last.x86_64 0:2.2.5-5.el7.remi will be installed
--> Processing Dependency: libtiff.so.5(LIBTIFF_4.0)(64bit) for package: gd-last-2.2.5-5.el7.remi.x86_64
--> Processing Dependency: libtiff.so.5()(64bit) for package: gd-last-2.2.5-5.el7.remi.x86_64
---> Package libargon2.x86_64 0:20161029-2.el7 will be installed
---> Package php-fedora-autoloader.noarch 0:1.0.0-1.el7 will be installed
---> Package php-json.x86_64 0:7.2.11-1.el7.remi will be installed
--> Finished Dependency Resolution
Error: Package: gd-last-2.2.5-5.el7.remi.x86_64 (remi-safe)
           Requires: libtiff.so.5()(64bit)
Error: Package: gd-last-2.2.5-5.el7.remi.x86_64 (remi-safe)
           Requires: libtiff.so.5(LIBTIFF_4.0)(64bit)
You could try using --skip-broken to work around the problem
You could try running: rpm -Va --nofiles --nodigest

----EDIT

A remirepo (github) user told me that I should not disable the default repos, :P Now it's working.

Fri, 10/19/2018 - 03:16
Jfro

Can you post your YUm and repos configs?

Sat, 12/08/2018 - 00:46
Diabolico
Diabolico's picture

Little update: PHP 7.3 is out and with some changes compared to PHP 7.2 it brings better overall performance. More info you can find HERE.

If you want to upgrade from default PHP 5.4 or some never version just follow my original post as nothing changed.

- I often come to the conclusion that my brain has too many tabs open. -
Failing at desktop publishing & graphic design since 1994.