Selectively update themes in WordPress multisite

I have been running a WordPress multisite installation for a few years, and every time WordPress releases an update (from x.y.z to x.y or x.y.z to x.y.z) there is always a chance that one of the themes used on one of the sites break. This is due to the fact that each theme can be custom-made, from a major theme site, or a default theme; but any of them could at any time been slightly modified, have used a function that became deprecated on the update, or just not be well-made.

Granted that this is not an uncommon problem, at least not if your themes come from varied sources, I am considering a possible solution to ease the workload of updating the WordPress core without breaking one or more sites in the process. Consider the following:

Read More
  • Three WordPress installations are run in partial parallel:
    • Site one is partially publicly visible, containing the current version of all themes and site, on the not-updated version of WordPress.
      • We’ll call this “live site, pre-update”.
    • Site two is partially publicly visible, and contains the updated version of each theme and site, running the most updated version of WordPress (not beta or RC).
      • We’ll call this site “live site, post-update”.
    • Site three is not publicly visible, and contains a duplicate of each theme and site, running the most updated version of WordPress (not beta or RC), used for error-testing and optimizing.
      • We’ll call this site “testing ground”.
  • Whenever a major ( x.y.z to x.y ) or minor ( x.y.z to x.y.z ) update is released, the mirrored version of the site (the “testing ground” initially uses an exact duplicate of the theme the “live site, pre-update” uses) is tested for problems.
    • If there is a deprecated function, a change in appearance, or grounds for optimization, this is done in a controlled manner on the testing ground.
  • When a site on the “testing ground” is considered ready, “live site, post-update” updates the site there based on the content from “live site, pre-update” and the theme from “testing ground” and set as the current publicly available version of the site.

A hypothetical example:

  • On “live site, pre-update” I have a site called KittensWhoPurr with the theme KittenMania.
  • I update the “testing ground” and notice that some functions used in KittenMania are deprecated, and go through the process of optimizing the theme for the new version of WordPress.
  • On “live site, post-update”, I update the KittenMania theme from the version in “testing ground” with content from “live site, pre-update” and make this the currently publicly visible version of KittensWhoPurr.

This requires some streamlining of the process going between the three installations, most importantly the ability to disable a site on “live site, pre-update” in favour of the updated version of it on “live site, post-update” without disrupting normal functions such as user-accounts, plugin functionality etc. I imagine the same process would be suitable for error-testing plugins between versions, probably a bigger problem than themes for most in this situation.

I know there are some paid solutions to this around the web, but I categorically avoid them as I think there should be a free alternative. The biggest problem really is avoiding breaking statistics and functionality from the old live site when porting to the new one, but I think they can be overcome with some ingenuity.

Any suggestions for accomplishing this would be very much suggested.

Related posts