
Table of Contents
WordPress Statistics Insights
The official WordPress statistics tells an interesting story (November 2024).
WordPress 6.7.0 was released on Tuesday 12 November 2024.
With more than 42% of all ~493 million websites updated, in a few weeks.

WordPress Installations – Version by % Table (2024-11)
Version Installations (%)
6.7 42.22%
6.6 24.57%
6.5 6.06%
6.4 4.70%
6.3 1.96%
6.2 2.51%
6.1 2.20%
6.0 1.66%
5.9 1.22%
5.8 1.46%
5.7 1.14%
5.6 0.77%
5.5 1.08%
5.4 1.26%
5.3 0.96%
5.2 0.90%
5.1 0.58%
5.0 0.36%
4.9 1.75%
4.8 0.46%
4.7 0.55%
4.6 0.23%
4.5 0.23%
4.4 0.24%
4.3 0.14%
4.2 0.14%
4.1 0.12%
4.0 0.08%
3.9 0.09%
3.8 0.05%
3.7 0.02%
3.6 0.06%
3.5 0.08%
3.4 0.05%
3.3 0.04%
3.2 0.02%
3.1 0.04%
3.0 0.06%
- With WordPress 3 on ~2.465 million websites (~0.50%).
- With WordPress 4 on ~19.326 million websites (~3.92%).
- With WordPress 5 on ~47.870 million websites (~9.71%).
- With WordPress 6 on ~423.339 million websites (~85.87%).
That is ~69.6 million WordPress websites officially not supported.
Good news. Serious issues do appear to be backported, occassionally.
- WordPress 3.0.0 released 2010-06 with 3.9.40 patch on 2022-11.
- WordPress 4.0.0 released 2014-09 with 4.9.26 patch on 2024-06.
- WordPress 5.0.0 released 2018-12 with 5.9.10 patch on 2024-06.
- WordPress 6.0.0 released 2022-05 with 6.7.0 patch on 2024-11.
WordPress Automated Update Considerations
A WordPress website with a lower risk profile is always desirable.
However, the delima of using automatic WordPress updates for an imporoved and lower risk profile is a clear choice for blind dependecy on another organisations regression testing capability.
It is a good website owner strategy to get the latest updates for WordPress core, plugins and themes uploaded to the WordPress Production website as soon as possible. The latest known security and user feature fixes are always welcome and appreciated.
However … are 100% automated updates really that safe?
WordPress 6.7.0 introduced a Cascading Style Sheet (CSS) minification error.
The ability to edit pages in the WordPress Administration area was not possible, due to a white-screen-of-death.
Only logged in users who edit WordPress Pages were impacted.
Digging under the hood revealed that the edit page capability was all there, delivered to the web browser client.
It was the post-processed minified CSS distributed with 6.7.0 that appears to be the root cause of the problem.
At first glance, it looks like regression testing was done on the original CSS ‘*.css’ file, but not the final packaged ‘*.min.css’ files, distributed to 100’s of millions of websites. Sounds plausable enough; but, is it the real root cause or is it something else a bit of a perfect-storm of circumstances?
The immediate solution was easy enough. Quite a few great WordPress Administrators shared their band-aid work-arounds. You could enable WP_DEBUG mode and force WordPress to use the original CSS files, not the minified CSS files.
Issue has a band-aid on it and the Production website now runs in debug mode until an official solution is provided in WordPress core; hopefully soon. What is the fix?
Now the local WordPress Administrator has a task to circle back to.
When can WP_DEBUG mode be turned off in Production? Only when a newer WordPress Core update has resolved the issue? Ok, it is what it is.
However … without automated updates, this user impact and administrator housekeeping could have been avoided.
A preference would be to enforce a website owner policy to conduct regular updates in a staging website; after in-house regression testing on core features the website actually uses.
You do not have to test every WordPress feature available, just the core ones that your website actively uses.
Wow … that is a lot of regression testing man-hours required. Either setting up automated regression testing process in a staging site or doing it manually.
Huummm, I would be biased toward wanting to rely on another organisations regression testing practices too. But at what cost?
Running a blog to share thoughts and ideas? The acceptable risk profile can be quite high.
Running a business shopping cart? The acceptable risk profile needs to be quite low. Every man-hour the shopping cart and user accout features do not work is actively blocking sales and increasing brand reputation damage.
[Observation] why were only some websites impacted by the WordPress 6.7.0 edit page white-screen-of-death? This would imply the root cause issue is more related to the target hosting environment, compatibility with other installed plugins and caching technologies used. Ok, lets go down that rabbit-hole a bit further.
Simply … for each website you own or maintain, choose an acceptable risk profile you are happy to live with.
[Option-1] Some of your websites apply automated updates, hands free with an expectation that you can live with any user feature impacts for a while, until you notice them and fix them after it has already happened to the WordPress Production website.
[Option-2] Some of your websites apply ‘patch’ automated updates, hands free. Following a semantic version schema (major.minor.patch.early) allows you to choose to automatically update patch releases, which historically have a way lower risk profile. While leaving Major, Minor and Early releases to follow your website owner policy for regression testing in non-production staging websites; applied to Production once regression testing of used features have passed and an outage window is agreed too, by the website owner.
[Option-3] Some of your websites apply a no automated updates policy. Everything is regression tested in a non-production staging website and requires in-house approval with a zero-defect policy before being applied to the Production website.
Why? While there are plenty of other options, these 3 outline a few core choices for all website owners. Any business online presence or service should demand 5 start stability and performance, because reputation matters to the financial bottom-line.
[Observation] Automating the WordPress 6.x core, plugins and themes updates seems to go very soomthly … only when the various caching mechanisms are disabled.
[One-Day-Maybe] Unfortunately, the below process is not automatable within the current WordPress update feature. Not without custom enhancements, as far as I know. I guess I now know what one of my future development projects should be … to add pre & post actions to the WordPress automated updates feature; specifically tied into the maintenance-mode capability.
- Disabling Object Cache Pro, Autoptimize and WP Rocket before any Major or Minor release updates.
- Action the WordPress core, plugin and theme updates.
- Sometimes, the local web browser cookies for the WordPress Administrator user logged in session, seem to disable the WordPress administration area from working properly, right after the updates are applied in-bulk. They all applied successfully but the WordPress Administration area refuses to load; not until I clear the local web browser session cache and re-log back in. Nothing wrong with the updates on the server.
- Enabling Object Cache Pro, Autoptimize and WP Rocket after the updates are applied.
- Action the priming of the Autoptimize and WP Rocket caches. For all version types (Major, Minor, Patch and Early).
[One-Day-Maybe] A curious side-note. It is possible that the page edit white-screen-of-death problem is more of a local web browser caching issue. We know that delivery network cache best practices recommend that any new version of a file gets deployed as a brand new file name. Specifically, file names should have a unique id of some sort that changes when it’s content changes. Like “mycustomlookandfeel.0.0.1.min.css”. This avoids the need to invalidate any geo-located server caches or web browser caches. It is curious that the only web site I had a page edit white-screen-of-death problem with, was one that I was logged into and doing other WordPress Administration area stuff. Perhaps the long-term solution is for WordPress core to follow delivery network cache handling best practices and use a version number in the minified “.min.css” files; which, should be applied to all the public assets like JavaScript, Images and CSS files.
Either way, it is definetly good food-for-thought when developing our own plugins and what file name schema to use for the included resources like JavaScript, Images and CSS files.
Question: What actions do you do, to stabilise WordPress updates?
Leave a Reply