⚙️ WordPress Site Health, cPanel, and Changing the PHP Version

Featured image created from photo by Webaroo.com.au on Unsplash

Every now and again, I click around the tools I use to see what new features have snuck in while I was not paying attention. I know many of you are terrified of clicking into the unknown and I don't blame you, but since I am willing to throw caution to the wind in this area, why not learn from me and resolve issues with all the confidence and less of the anxiety. Here is how I found and resolved a security issue in my WordPress blog through the use of inquisitive clicking around.

Site Health

When I was writing a post on some of the great tools I use to support my software development, I spent a large amount of time procrastinating, clicking around the tools I use to look at features that I had forgotten or had never even seen before. One of the things I discovered was the Site Health feature of WordPress, which I just now discovered was added in their 5.2 release. You can find Site Health under the Tools menu of the admin dashboard side panel; I highly recommend checking it out once in a while to make sure your WordPress installation is secure and performing well.

Selecting the Site Health tool takes you to a page that runs a variety of performance and security checks on your WordPress installation. You can see what things it is checking once the report has been produced. If all is well, everything passes. However, when I ran it, I got a warning about the version of PHP being used.

Screenshot of the Site Health page in WordPress showing the a yellow circle with the word "Should be improved", and the Status tab selected with the text "The site health check shows critical information about your WordPress configuration and items that require your attention.", "1 critical issue",  and "Your version of PHP (7.0.33) requires an update", as well as a collapsed section labelled "Passed tests".

For those that do not know, PHP is the language with which WordPress is implemented. It is usually installed and managed by your hosting service and it is your hosting service where you must go to fix this problem.

Changing the version of PHP

My host is BlueHost, one of those recommended by WordPress and therefore, quite likely to be your host too. As with many WordPress hosts, BlueHost provide cPanel to manage things and it is in cPanel where the PHP issue can be fixed. However, I did not really know that until I started investigating, and as I said before, I like to click around the tools I use. This is how I found the screen where I could change the PHP version.

  1. Login to the site host account.
  2. Open cPanel
    In BlueHost, this is accessed by clicking the Advanced option in the sidebar.
    Screen grab of the BlueHost sidebar showing the Advanced option circled in red and indicated with an arrow
  3. Find and click the MultiPHP Manager option
    Screenshot of the BlueHost cPanel with PHP entered as a search term. The MultiPHP Manager option has been circled in red and indicated with a large red arrow.

At this point, I saw the following screen.

Screenshot of the MultiPHP Manager screen in BlueHosts version of cPanel. It shows the System PHP Version of PHP 7.2 as well as my domains, with each saying they inherit this same version of PHP.

The system default version of PHP is shown at the top as 7.2, below that the list of my domains show that they inherit that same version. However, my WordPress Site Health said I was running only 7.0 of PHP. One of these is wrong, and I suspect that it is the information displayed in cPanel1.

I checked the boxes on the left so that I could change all my domains and then I chose 7.3 from the dropdown and clicked Apply. Here is what my MultiPHP Manager screen showed; I've annotated it to make a few things clearer.

Screenshot of the MultiPHP Manager screen in BlueHosts version of cPanel. Several areas have been indicated with red arrows and associated text; the System Default version, the dropdown of available PHP versions,

Verifying the change

At this point, returned to the WordPress Site Health page and refreshed it so that the health tests reran. After a few moments, the status was updated and everything was good2.

Screenshot of the Site Health page in WordPress showing the a green circle with the word "Good", and the Status tab selected with the text "Great job! Everything is running smoothly here." as well as a collapsed section labelled "Passed tests".

The Site Health feature is a great addition to the WordPress platform and though issues can be a little daunting, it often only takes a few moments to address them. Hopefully, my little journey into addressing this issue on my WordPress site is helpful; take a moment to check out your own site health.

Until next the time, I'll be me, you be you, and we will all have a lovely adventure. 👋🏻

  1. if I were to guess, I'd say there is a bug in cPanel where the UX assumes the system version is inherited but in reality, it is the lowest available version, which in this case is 7.0 []
  2. NOTE: You may need to refresh more than once in order to give the system time to reload on the new version of PHP that you have selected []

CiviCRM deployment on IIS WordPress

At Ann Arbor Give Camp this year, I worked on a team looking into donation management options for non-profits. Thanks to Dr. Milastname (it would be inappropriate to reveal his true identity), we found CiviCRM and spent much of the weekend getting familiar with its deployment and functionality inside of WordPress. CiviCRM integration with WordPress is a relatively new feature, so it was not totally unsurprising that we encountered one or two issues. The first and by far the biggest problem we encountered was the White Screen of Death (WSOD).

After some debugging (which involved editing a couple of PHP files inside of the WordPress and CiviCRM systems), we discovered that a PHP add-in used by CiviCRM for templating was relying on the `open_basedir` variable and this was not set on our IIS-based system. This caused the templating add-in to fail, halting the rendering of the CiviCRM admin screen and resulting in the WSOD.

To rectify this problem, I edited `wp_config.php` to introduce the `open_basedir` variable just before the `require` statement for `wp_settings.php`. I set the variable to the path of the WordPress deployment (`ABSPATH`) and refreshed the CiviCRM admin screen.

ini_set('open_basedir', ABSPATH);

This fixed the WSOD and enabled us to continue our evaluation of CiviCRM1. We also raised an issue against the CiviCRM project and added a post to the CiviCRM forms, ensuring the lessons we learned would benefit future users of CiviCRM.

  1. And discover a bug that I had introduced all by myself []

Drop the BOM: A Case Study of JSON Corruption in WordPress

GiveCampIn September, I attended Ann Arbor Give Camp, a local event that connects non-profits with the local developer community to fulfill technological goals. As part of the project I was working on, I installed a plugin called CiviCRM into a WordPress deployment that was running on an IIS-based server.

It turned out that WordPress integration for CiviCRM was relatively new and a problem unique to IIS-based deployments existed after installation. This led to a white screen when I tried to access CiviCRM. I spent some time troubleshooting and eventually found the issue after I edited two files to track it down. The fix was quickly implemented. Unfortunately, I then discovered that some other features were not working properly.

The primary places this new issue surfaced were in displaying dialog windows within CiviCRM. It turned out that these dialogs obtained their UI via an AJAX call that returned some JSON and for some reason, jQuery was indicating that the call failed. Investigating further, I saw that the API call was successful (it returned a 200 status result) and the JSON appeared completely fine. How strange.

JSON in binary editor of Visual Studio
JSON in binary editor of Visual Studio

I made some debug changes to the JavaScript using the Google Chrome development tools and looked at the failure method jQuery was calling. In doing so, I discovered jQuery was reporting a parsing error for the JSON result. This seemed bizarre, after all, the JSON looked fine to me. I decided to verify it by copying and pasting it into Sublime. Still, the JSON looked just fine. Being tenacious, I saved the JSON to a text file and then opened it in Visual Studio's binary editor and there, the problem appeared. There were two characters at the start of the file before the first brace: byte order marks.

Corrupted JSON in Google Chrome developer tools
Corrupted JSON in Google Chrome developer tools

A byte order mark (often referred to as a BOM) is a Unicode character used to indicate the endianness (byte order) of a text file or stream1. JSON is not supposed to include them at all. In hindsight, I could have seen this issue much sooner if I had paid closer attention to the JSON response in the Network tab of Chrome's developer tools. This view had shown two red dots (see above) before the opening brace, each dot corresponding to a BOM that Chrome knew shouldn't be there. Of course, I had no idea what they meant and so I promptly ignored them. Lesson learned.

So, armed with the knowledge of why the JSON was causing parser errors, I had to find out what was causing this malformation and fix it. After reading about how a BOM in an incorrectly formatted PHP file2 could cause BOMs to be prepended in the PHP output, I started looking at each PHP file that would be touched when generating the API response. Alas, nothing initially stood out. I was getting frustrated when I had an epiphany; I had edited exactly two files in trying to fix the installation issue and there were exactly two BOMs. Coincidence?

I went to the two files that I had edited, downloaded them and discovered they both had BOMs. I re-saved them, this time without a BOM and uploaded them back to the site, which fixed the JSON corruption and got the CiviCRM plug-in in to working order.

In tracking down and fixing this self-made issue, I learned a few valuable lessons:

  1. Learn to use my developer tools
  2. Never assume it is not my fault
  3. It pays to understand how things work

Hopefully, my misfortune in this one incident will help someone track down their own issue with corrupted JSON in WordPress. If so, please share in the comments. Together, our mistakes can be someone else's salvation.

  1. Wikipedia – http://en.wikipedia.org/wiki/Byte_order_mark []
  2. one saved as Unicode with byte order mark []