Our WordPress Hosting tries to keep a stable modern LEMP stack (Linux, Nginx, MariaDB, PHP). At the time of writing, we are still using PHP version 7.2 rather than the latest 7.3. With the new version available for some time, we are now getting the occasional query on when we plan to update.

The short answer is… soon.

To give a more in-depth answer to this question, and a look at why we haven’t already updated let me introduce you to package management on Linux.

Linux package systems

One of the amazing things about a Unix based operating system, such as CentOS 7.4 which is the Linux distribution we use in containers for sites, is that almost any piece of software designed to work on one distribution can be compiled to work on another.

Indeed in the early days (and for some even today) if you wanted to install software you would do something like:

  • configure
  • make
  • make install

And provided you have the relevant dependencies already installed, something to build your software such as GCC, and time, your software would compile and be ready to go.

Excellent! Except it never goes according to plan.

Inevitably you will be missing a dependency, something will need changing in the makefile or some other small but irritating problem will rear its head. It made for a good day when you tried to compile something and it just worked.

Distributions soon realised that compiling packages was time-consuming and error-prone so most started including package managers, such as apt-get for Debian based distros and yum/rpm for Red Hat based ones, which include CentOS.

Instead of compiling the software yourself, these package managers connect to repositories (normally referred to as repos) to get a list of available packages. If the software you want is available in the repo it will then download a precompiled binary (ie. already compiled to work on your system) and a small configuration file to tell it how to set up the binary.

Package managers also have the advantage that they take care of installing all the dependencies for you, again by installing the precompiled binaries of the dependencies.

Package managers massively simplify the installation of software and as a consequence they are heavily relied upon by everyone.

One of the main reasons to pick a distribution like Red Hat or its derivative CentOS is access to its repos which provide backwards compatibility and long term support for software, often well beyond that given by the developers. Red Hat have a team dedicated to providing patches to software that would otherwise not get patched. This means users of their OS have much longer upgrade cycles which provides much more time to plan, test and deploy which should mean fewer things break.

The slow pace of this cycle though is not exactly suited to that fast-paced world of hosting. For instance, the version of PHP available to Red Hat customers from the default repository is 5.4. While PHP 5.4 is end of life and no longer supported by the PHP team – not even for security patches – Red Hat does still support and provide security patches for it.

To get around the slow nature of Red Hat release cycles, you can add other repositories beyond the base ones. For instance some extra packages are made available by Red Hat in a repo called EPEL, or numerous third parties have their own repos, from individual software authors to groups providing large collections of compiled software.

Each time you add a new repo to your package manager you are adding a new source for packages to be downloaded and placing a huge amount of trust in the repo’s provider. As such it is very unwise to use any old repo for getting access to packages without a bit of vetting.

When it comes to selecting repos our first choice is always base, the main repo provided by Red Hat. If the package we need is not available within that repo then we will look next to EPEL, then to the package vendor directly. Quite a lot of software written for Linux will have its own repos for major Linux distributions.

If a package does exist in base but is too old for our use case (PHP, for example) then we look to IUS which is a community managed repo that provides more up to date but stable packages for CentOS. If the package we need is not available in IUS then we look to the vendors themselves, which for example is how we obtain a stable version of Nginx.

If all else fails we will compile and manage the package ourselves via an internal repository. Where practical we will avoid this as it means we have to maintain and manage each package individually and dedicate human resources to keeping those packages up to date and tested.

By limiting the number of repos and trying to keep the creation of our own packages to a minimum we reduce the potential issues with our vendors being hacked, gain all the benefits of third party package management while reducing complexity and compatibility issues. This allows us to adopt an automatic update model of constantly rolling updates as they are available with confidence that problems will be minimised.

So where is PHP 7.3?

As detailed above, we use the IUS repo for managing PHP, giving us access to latest stable versions of PHP 7. It’s stable, community-driven and ticks enough boxes to make it our choice for providing packages that we know will be compatible with our infrastructure.

Normally when a new release comes out, IUS runs a little bit behind. That’s ok; it gives us a chance to test things behind the scenes while we wait for the package to appear. Back in December 2018 when PHP 7.3 was released, we noted its release and looked at the best way to deploy it in Q1 2019. Unlike lots of our infrastructure, upgrading PHP versions requires more time. Because WordPress core and plugins are written in PHP any deprecation or changes to the codebase can have a direct knock-on effect to clients’ code. As such we look to see how many sites would be affected by a new version and get in touch to prepare those sites for the new release.

Unusually, PHP 7.3 didn’t appear in the IUS stable repo. We kept an eye on it but were happy to just update when it was ready. We were not going to update until after the WordPress 5.2 update which had some PHP 7.3 compatibility fixes included. WordPress 5.2 came and went and we started to get concerned.

Meanwhile, IUS were undertaking some changes to their infrastructure which will ultimately mean a new, more streamlined service. PHP 7.3 is one of the first packages on the new infrastructure and has been available in the testing repo for a while but still hasn’t yet been flagged as stable.

All indications are that it is in fact stable, but still we must make a decision on whether we hold on for IUS to complete their infrastructure move and get PHP 7.3 moved into the stable repo, or look at an alternative such as the popular Remi repo.

As of last week, it looks like IUS are about to move PHP 7.3, or more specifically 7.3.7, into the stable repo. We will do another round of testing and begin contacting clients who will need to make code changes.

Once that is done, we will be rolling out 7.3 across our WordPress Hosting stack, just in time for the release of PHP 7.4!

Should there continue to be delays, we will once again look at either switching repos or moving PHP compilation in house, though as before this is not our prefered option. While PHP 7.3 brings new features and performance enhancements, it does not deliver the huge benefits seen in the upgrade from 5 to 7, or even 7.0 to 7.2 so we are happy to take our time. The key as a host is to make sure we are providing the best stack for our users. In this case, it’s not about being right on the bleeding edge with the latest versions of everything, but making sure our service is stable and reliable.

Comments

    Sign up to our newsletter

    Get the latest tutorials, videos and special offers from 34SP.com.

    Thanks for signing up!