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:
- 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â.
- Site one is partially publicly visible, containing the current version of all themes and site, on the not-updated version of WordPress.
- 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.
