Upgrading to PHP 5.3 on CentOS EL5 Linux


After a few years of running PHP 5.1.6 on my main server, I needed to upgrade due to the large number of WordPress installs I have. The current version of WordPress requires PHP 5.2.4 and MySQL 5.0 or higher. I was fine on the MySQL part, so no worries there.

My favorite package tool is YUM. But the current repositories didn’t have anything available for my OS past 5.1.6.

Well I stumbled across the repositories needed to take this older CentOS install to a current web application server. I also had a couple minor bugs along the way and found the solutions to get back up and running.

Here are the steps I took, for you and for myself, because I’m sure I’ll have to do this again on other servers I manage.

1. Remi’s Repository

Remi maintains a repository for various Linux operating systems and architectures. As per his configuration page, I needed to download a couple of files and install them.

wget http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-4.noarch.rpm
wget http://rpms.famillecollet.com/enterprise/remi-release-5.rpm
rpm -Uvh remi-release-5*.rpm epel-release-5*.rpm

1a. First snafu – trying to upgrade PHP at this point, caused a YUM “Transaction Check Error”

This is because I wasn’t upgrading MySQL to a more current version. So I needed to install one more file:

yum --enablerepo=remi-test install compat-mysql55

Now proceed with upgrading PHP:

yum --enablerepo=remi update php

Now a quick php –v returns  PHP 5.3.8, great, upgrade successful.

2. Restart Apache – look for problems

A quick skim through my sites and I found several broken for a couple reasons, which I expected. The most common issues were sessions and ioncube loaders missing. Another minor issue was the default timezone needed to be set. In /etc/php.ini I just uncommented the date.timezone property and set it to ‘America/Chicago’. Now all those time warnings disappeared from a few of my custom CakePHP apps.

For my Apache install, the group it runs under is different than the default permissions specify on /var/lib/php/session/ so once I replaced the group permissions there, sessions started working normally.

Then I popped over to ionCube for the latest loader binaries.

Because I had many sites that used encoded files, I decided to store the loaders centrally rather than manually finding and upgrading any broken apps.

So, at the top of my /etc/php.ini I added zend_extension = /usr/local/ioncube/ioncube_loader_lin_5.3.so and made a final Apache restart.

Now all of my sites are back up and running with a much new version of PHP which should last me another few years.

Then I can finally proceed with upgrading all of my WordPress sites. Fortunately I have a custom shell script to perform batch upgrades. It’s simple but very effective when you have so many sites to deal with, but that’s a topic for another post.

Share on Twitter

3 Responses so far | Have Your Say!

  1. Wavatar

    Diego  |  September 6th, 2011 at 10:28 pm #

    Wow this is great ! many thanks for this ! share that post about upgrading all blogs at one time please 😀

  2. Wavatar

    Diego  |  September 6th, 2011 at 11:24 pm #

    i just have one problem after upgrading via your method, in one blog, i cant access wp-admin. what could it be? what can i do?

  3. Wavatar

    Roger  |  September 7th, 2011 at 1:02 pm #

    Hi Diego! Glad you found this useful! As far as your WP Admin page, if you still can’t access it, try running a: php -f /wp-admin/index.php from the command line. See if there’s any errors displayed that can point you in the right direction.