Prev
Sometimes, website changes go smoothly.
Sometimes they don’t.
On December 28, I had a couple of rare free days, and I thought I’d finally get around to seeing if I could upgrade my sites from PHP 5.6 to PHP 7.4. The programming language PHP is what runs WordPress and does most of the automation of the webpages that transfers data to and from the MySQL databases that contain everything.
I mentioned the necessity to eventually upgrade the PHP version in my blog post from a year ago: Averting Blog Disaster
It would be nice if I could just flip the switch and everything worked. But then, these are computer systems, and as everyone knows, nothing ever goes smoothly when it comes to computer systems.
My major use of PHP is in my Behold blog, my Behold forum and my GenSoftReviews site which use installations of WordPress on my sites.
I had two choices
1. To upgrade my versions of WordPress so that they’d be the current version that work with PHP 7.4, or
2. To fix any of the underlying PHP code that doesn’t work properly under PHP 7.4 and get it to work.
Only one of these options is truly viable for me at current time. GenSoftReviews has at its core a WordPress plugin that turns it into a rating site. To upgrade wouldn’t only mean WordPress would have to be upgraded, but it would mean that plugin would have to be upgraded as well. Unfortunately, the ratings site plugin is no longer available and I’ve already got the latest version installed on GenSoftReviews. In addition, I’m using about 12 other WordPress plugins on GenSoftReviews and/or my blog/forum, and half of them are in the same boat.
The other problem is that I custom coded my WordPress sites with all sort of nice features that I really like. If I upgraded WordPress, I would lose all those customizations. I’d have to go back and implement them all over again.
I figure upgrading and recustomizing would take me about a month. But fixing the code seemed like it would be easier. If all worked perfectly, I estimated that I’d be able to get the PHP code working in maybe a couple of days.
Step 1: Get it running in my Development Environment
On my computer, I keep a copy of my websites for my own development work. I run them locally on my computer when needed using IIS (Internet Information Services), Microsoft’s webserver.
I have installed PHP and MySQL (the database PHP uses) on my computer. I set up 3 different versions of PHP under IIS and under IIS’ PHP Manager, I can select which one I want to use.
The switch is instantaneous. I can select 5.3.28, press OK and open Edge and view my local site in that version of PHP. I can then select 7.4.1, press OK, switch to the site in Edge, press F5 (refresh) and *tada* it’s displaying in the new version of PHP.
This allows me to easily test old version versus new version side-by-side and ensure everything that’s working in 5.3 is also working in 7.4.
I don’t have the greatest development environment for PHP. I’m sure there are good debuggers and PHP development interfaces out there somewhere, but I’m happy enough usomg the good old technique of trackomg down where a problem is happening by adding a debug and a halt statement directly into the PHP code, i.e.:
echo “Here I am!”; exit;
If the “Here I am!” displays and it didn’t get to the problem, then I know the problem happens later in my code and I move the debug line down and try again. If the problem displays, then the “Here I am!” is after the problem and I move the debug line up and try again. I follow the path through the chain of modules that are called to discover which module and what line is causing the problem.
The first issues I encountered were some PHP commands that were either deprecated or otherwise illegal and no longer available in PHP 7.4. These included:
- "=& new" needed to be changed to "= new"
- "= @ =" needed to be changed to "="
- I found two parameters of a function had the same name (both were named $deprecated) which newer PHP doesn’t allow, so I changed the second name to $deprecated2.
- I found a few PHP opening tags (a less than sign followed by a question mark followed by “php”) without the "php" in them, which won’t work in 7.4.
Once I found those, it wasn’t too difficult to search my code to find all occurrences and fix them.
A more severe problem was that the PHP MySQL extension is now deprecated and I needed to switch it all over to MySQLi. The conversion is non-trivial, but I found and used this great page for the conversion. I then rewrote the entire wpdb.php (WordPress database) module as well as any other occurrences of MySQL commands to use MySQLi.
This took me a couple of days to do. Once I completed, I had GenSoftReviews and my Behold blog and forum all working on my computer in my test environment.
Step 2: Copy the Changes to My Live Website
I use the program Beyond Compare to copy my local files to my live website. It can compares my local website directory to its corresponding live directory at my webhost Netfirms and shows me which files are different. I can then see the differences within each file and easily update the ones that need to be updated.
So I copied over the files. Netfirms also has an interface allowing me to change the PHP version used on my live websites:
They allow selection of 8 different versions. I was running PHP 5.6. The simple selection of “7.4” changes it to that version. Like in IIS on my own machine, the change is instantaneous on my live site. I can make the change and refresh the page and see the difference right away.
But that’s not what you want to do on a live website. You really want to make the change once and have everything work from that point on. With it all seeming to work fine on my test site, I was optimistic that everything would work fine.
But I was wrong. Version 7.4 didn’t work. The sites wouldn’t display. I spent a few hours trying to debug the site live and ran into problems.
I tried to recover and set everything back to PHP 5.6 and leave it for the morning to figure out. … But disaster. GenSoftReviews displayed okay again, but my Behold blog and forum would not. I tried what I could to get them going again in 5.6 but no luck. Something I changed prevented from working again in 5.6.
So sadly I put up the following message that was to be displayed on my blog and forum for the next few days:
Some GenSoftReviews Fixes
I thought it best to see if I could get GenSoftReviews going first. There were a few reasons: I thought it would be easier because GenSoftReviews is made only from WordPress, whereas my blog and forum are a much more complex combination of WordPress and bbPress. Also, I was hoping to announce the 2021 GenSoftReviews User Choice Awards in the new few days, so I needed the site running well for that. And I was hoping that any fixes I needed to make for GenSoftReviews might also apply to my blog and forum and maybe those alone would be enough to fix them, or at least get them to display.
There were quite a few things needing fixing on the GenSoftReviews site.
First, special and accented characters were being displaying incorrectly:
A question mark enclosed in a black diamond was being displayed instead of the correct character. The first thing I did was check the database. It is UTF8 and it did have the correct characters in it. That verified it was just a display issue.
It took me a while, but I found the solution as the top answer for this StackOverflow question: UTF-8 all the way through. My fix was to add a set_charset command prior to the selection of the mysqli database:
$this->dbh->set_charset(’utf8mb4′);
mysqli_select_db($this->dbh, $dbname);
The second problem was one not visible to users. The Wordpress admin pages which I need to maintain the GenSoftReviews site were not including the CSS (Cascading Style Sheets) for the site’s theme, so they were just being displayed to me on a blank page.
The reason why I write these sort of one-off technical blog posts is to not only help others who might be running into problems doing something similar to what I’m doing (e.g. upgrading their PHP version), but also to be a place where I can record what I did so that I can come back to recall what that was if I have to do it again in the future. I mention this because, it’s now only a few days later, and I’ve already forgotten what I did to fix the CSS problem. I did fix it however, and if I do remember, I’ll come back here and include what I did.
The third problem was when a review was posted, it was not using the user’s name he entered but was always replacing it with the default: Anonymous. I found that the WordPress filter called “pre_comment_author_name” was blanking out the name the user entered. This was happening in my test environment as well. I didn’t know why and couldn’t fix that filter, but I fixed the problem by using the “the_author” filter instead.
Along the way, I found that the ereg set of commands were deprecated and no longer worked and needed to be replaced with the preg set, i.e.:
- ereg(‘xxx’ –——> preg_match(‘/xxx/’
- eregi(‘xxx’ –——>preg_match(‘/xxx/i’
- ereg_replace(‘xxx’ –——> preg_replace(‘/xxx/’
I found a few 3 parameter eregi calls. The third parameter does not have an equivalent in preg_replace, so those calls are better changed to “mb_eregi” which will do the same and is supported in PHP 7.
This next one was a tough one. It took me a full day to track down:
preg_replace with the “/e” option should not be used. Instead use preg_replace_callback. I found the solution at this page: https://core.trac.wordpress.org/ticket/8689 which helpfully lists all its locations in the WordPress code and the code to replace each occurrence with. Also see: PHP – How to fix the "Warning: preg_replace(): The /e modifier is no longer supported" error in PHP7 (ryadel.com)
The secret trick is to replace:
preg_replace(‘#aaa#e’, “bbb”, ccc)
with
preg_replace_callback(‘#aaa#’, create_function(‘$match’, “return bbb”), ccc);
These changes got the live GenSoftReviews site working well under PHP 7.4.
Getting the Behold Blog and Forum Going Again
First, I went through all the changes done at GenSoftReviews and did the same where applicable on my blog and forum code.
There was still a major problem as my pages would not display and there was no error message. So I did the painstaking step-by-step tracking and after a full day of debugging, eventually found the problem was that the hostname for the database was inadvertently set to “localhost” when it should have been “lkessler.netfirmsmysql.com’”. I’m not sure how I got “localhost” copied from my test server to my live server, but however I managed to do that, it cost me a day of my time and an extra day downtime for my blog and forum.
Once I fixed that, my blog and forum finally appeared again. But the page would timed out and never finish. That one didn’t take me too long to track down. It was a plugin initializing, so I just commented that out for now and presto, all my blog posts were available again.
Final Analysis
As I write this, I’ve now got GenSoftReviews working well, and my Behold Blog and Forum at least back up and displaying all the posts. There’s still some issues left to fix in my blog and forum, such as getting that infinite-loop plugin fixed as well as a couple of other minor items such as the archive year links not working. But I can now relax and fix those in the background over the next few days.
GenSoftReviews wasn’t down for long, maybe a few hours while I was debugging live. My blog and forum however were down for 6 days from Dec 30 to Jan 5. But now that they’re running again, a bit of downtime wasn’t the worst that could have happened.
Sometimes you just have to tackle the problem and not give up. The result is worth it.
Followup: Jan 15, 2022: I still had a few more puzzles to solve to get everything working right and for a few minutes now and then, my blog or GenSoftReviews might have been down during the past week, or showing strange debug messages. The worst problem was one only on my live site that would cause the server to time out, and if I did it a dozen times in a row while testing it occasionally bring up this nasty message:
and I’d have to wait a few minutes for the SQL server to reset itself again before I or anyone else could continue. It took me about 16 hours of debugging over 3 days to track down and fix this particular problem. Believe it or not, the final fix was to initialize an array to null prior to using it in a function call:
$query_args = array(); <== Had to add this!!
$query_args = wp_parse_args( $query_args );
I may find more minor problems in the future, but this was the last of what needed fixing for now.
Another change Apr 12, 2022: Server was timing out for a certain action in WordPress Admin. It took about 4 hours to debug, but ultimately the solution was to replace the deprecated clean_url function with esc_url which is what WordPress replaced it with.
RSS
Trackback
Permalink