I haven’t visited this in a while after upgrading to PHP 5.4 about a year ago.
I stopped at 5.4 because of the required mysql upgrade that isn’t compatible with “old_passwords”, which Interworx 5.0.x required.
[More info on the old_password issue that is no longer an issue: http://forums.interworx.com/threads/8276-Best-way-to-move-from-php-mysql-to-php-mysqlnd]
So now that I’m on iworx 5.1, I’m wanting to get back into the PHP upgrade.
What have others here that are still on CentOS 6.7 done to upgrade PHP?
What are the requirements for MySQL?
I think there is a little more that may need updating, but essentially yes, enabling remi and setting it the php version you need, should work
I would advice you do not use php 7 as yet, there are no ioncube loaders available for php 7. Of course, if you do not need ioncube, then php 7 is an option
Thanks John, I have no intention of upgrading past 5.6 at this point. I’m sure there are some incompatibilities with some older sites I hosts that I would have to resolve first.
Do you or anyone know if “yum --enablerepo=remi update php56” will actually update the main PHP (currently 5.4) with PHP 5.6 or will it install as a second php under PHP56?
I’m currently on a remi repo for PHP 5.4 (from my update a year ago).
I just thought though, you will need to add in the repository used, as I believe remi separate php repositories
I know when we updated our php on a new production server, it updated 5.3
[/QUOTE]
Yes, exactly right.
I was on 5.3 and have already used REMI once to upgrade to PHP 5.4.
I had to stop at 5.4 mainly because of the old_password issue I mentioned at the beginning of this thread.
So now that I have updated to mysqlnd and have manually deleted and recreated all my SiteWorx account database user (so they are created in the new long hash password style).
I’ve also tweaked a couple sites to not use mysql_ function and replaced with mysqli_. Although, it seems that mysql_ is only deprecated in 5.5+, not removed. That doesn’t happen until PHP 7.0.
So technically the sites would still work with mysql_, it would just throw some warnings (that you can just hide).
So I will be giving this a try later tonight here on the east coast. Hopefully all the sites run smoothly on the new version and if not I will try out the yum downgrade feature to go back to 5.4.
Thanks again for the feedback, good to confirm that this PHP56 will replace my current PHP54.
One More Questions though…
Is it better to run:
yum --enablerepo=remi update php56
I used the below for updating, so it updated all I needed, but I had to amend for PHP56, which remi repositories are seperate now, see pic, so you may have to lookup the correct resporitory, and amend as needed.
It was straight forward to do though, and I do not think you can yum downgrade (coudlbe wrong so appologies in advance), I think you just install for php54 if going backwards.
I hope that helps and appreciate if you could uodate post with your experience of how it went
Many thanks
John
wget http://download.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm
rpm -ivh epel-release-6-8.noarch.rpm
wget http://rpms.famillecollet.com/enterprise/remi-release-6.rpm
rpm -Uvh remi-release-6*.rpm
yum --enablerepo=remi upgrade php-mysql php-devel php-gd php-pecl-memcache php-pspell php-snmp php-xmlrpc php-xml php-mcrypt php-mailparse php-imap -y
yum --enablerepo=epel install php-pecl-mailparse
yum --enablerepo=remi install php-mailparse -y
yum --enablerepo=remi install php-imap -y
So when I do the upgrade I have to specify all the individual packages to update as well?
Also, I see you just say “upgrade”, but you have PHP56 enabled in your repo.
I have those all turned off which is why I was going to do:
yum --enablerepo=remi upgrade php56
And because you have your remi php56 Enabled in NodeWorx image, I don’t think you even have to do “–enablerepo=remi” right?
Also, you don’t seem to have php in that upgrade list? How does that get updated?
I’m sorry, I used mikes upgrade details, (licensecart) and meant to state that, but time is getting late here, rushed and missed it off sorry.
Also, I upgraded a clean install from IW on php5.3
Your also correct about running different versions of php, but I’m trying to think who posted how to do this, it might have been you but it’s a few years ago and you manually set the php, it is not set by IW for a different php version
Would still hope you post how it went for you if you don’t mind
Yes I will post later. My plan is to just enabled the [remi-php56] and run yum update.
I may also do the [remi] repo at some point, to get my mysql up to date.
And you can actually do all these updates (once remi is install on the system) from NodeWorx.
Here is a snap shot of the section “Check Updates” with both [remi] and [remi-php56] enabled via NodeWorx.
If you look at the bottom of that screen shot, you can check off the updates you want and then select Install Updates.
I guess you could also just let the iworx-daily cron run and it would update those as well (I think).
I’ll post back after I try it a little bit later tonight EST, just in case I have to make some tweaks to websites after the update.
Preparing a couple old sites to use mysqli vs mysql DB connection definitely was a good idea.
Although, the pages still work fine with the error message visible on the page. You can suppress the deprecated warnings by using ini_set(‘display_errors’, ‘0’); though.
I tried to do the yum upgrade without enabling [remi], but got the following errors
Error: Package: php-pecl-zip-1.13.2-1.el6.remi.5.6.x86_64 (remi-php56)
Requires: libzip.so.4()(64bit)
Error: Package: php-gd-5.6.21-1.el6.remi.x86_64 (remi-php56)
Requires: libgd.so.3()(64bit)
Error: Package: php-gd-5.6.21-1.el6.remi.x86_64 (remi-php56)
Requires: gd-last(x86-64) >= 2.1.1
You could try using --skip-broken to work around the problem
You could try running: rpm -Va --nofiles --nodigest
Enabling the main [remi] (in addition to [remi-php56]) I was then able to do the upgrade. I needed to update mysql anyway I guess
So all I did was enable those two repos and then do a “yum upgrade”
I did have a bunch of warnings spit out during the update like this
PHP Warning: PHP Startup: json: Unable to initialize module
Module compiled with module API=20131226
PHP compiled with module API=20100525
These options need to match
in Unknown on line 0
Pas de probl?me c’est normal.
Changement d’API donc pendant la MAJ on est le “cul entre 2 chaises”
A la fin de l’installation si “php -v” retourne la bonne version sans message, c’est que c’est bon.
which Google translates to
No problem this is normal.
API change so during the shift we are the “ass between two chairs”
At the end of the installation if “php -v” returns the correct version with no message is that it’s good.
