In an unprecedented move, WordPress developers are working on implementing a plan to forcibly update outdated versions of the WordPress CMS to the latest version to provide greater security features. The bold plan would see all old WordPress sites running version 3.7 and later being updated to the latest secure release.
Currently, only the six most recent WordPress versions – starting from 4.7 and up to the current version, 5.2 – are officially supported and have access to the latest security updates. With WordPress sites accounting for at least 34% of all websites currently online, and with new and ambitious WordPress exploits and attack attempts discovered all the time, is WordPress making the right move? Or, as some dissenters argue, are WordPress developers overstepping their bounds by changing their automatic update system from the current opt-in version to one where users will need to physically opt-out to remain on an older version of the CMS?
Old Sites, But Not Ancient
The automatic updates will affect those WordPress sites running version 3.7 and up, which accounts for tens of millions of sites – approximately 11.7% of all WordPress sites globally. This begs the question: what happens to sites running earlier versions of the CMS than 3.7? And why that particular cut-off?
The answer becomes clear when you consider that the 3.7 update was the first time that the auto-update mechanism was rolled out in the WordPress CMS. Sites running earlier versions cannot be auto-updated and must be manually updated to later versions of the CMS. In other words, even if WordPress wanted to bring ancient WordPress sites – those running CMS versions earlier than 3.7 – up to speed, they wouldn’t be able to, unless they wanted to manually update each site. Various sources suggest that somewhere between 1% and 3% of all current WordPress sites are running versions earlier than 3.7, and therefore won’t be affected by the auto-update move.
A Tiered Approach To Avoid A Major Update
The WordPress developers have put forward a tiered approach to the updates, in which each site would be updated from one version to the next while being carefully monitored for errors along the way. Under this approach, WordPress’s plan is potentially safer and less likely to cause major site issues than if a site owner suddenly decided to update straight from 3.7 to 5.2. Such an enormous leap would be very likely to cause problems with the theme or plug-in compatibility, or even render the site unusable (the dreaded white screen of death).
In a relatively conservative approach, the plan will begin with updating all WordPress 3.7 sites to 3.8. Even that step will be done in stages, with only 2% of 3.7 sites undergoing the update in the first round, followed by another 18% of sites the following week. Two weeks later, the remaining 80% of 3.7 sites would be updated to 3.8.
It is envisaged that the gaps between batches would allow WordPress developers to carefully monitor the sites that had been updated to ensure that no major problems were identified. WordPress developers have assured concerned site owners that, if major site breakages or widespread problems are detected during the auto-update process, previous versions can be rolled back and the process stopped until the problems can be rectified.
Following the first step, all sites running 3.8 would be updated to 3.9 in a similar staged approach. This would continue until all sites were running an officially-supported version of WordPress.
Outing-Out vs Opting-In
The ethical issues of consent and the difference between opting in and opting out are some of the major causes of dissent amongst concerned WordPress developers and site owners. To combat these concerns, WordPress core developers have lent their assurances that emails will be sent to site administrators and warnings shown on the main WordPress dashboard within the CMS at least six weeks before the auto-update process begins.
Not only will site owners be warned in advance that their site will be updated, but they will also be given explicit instructions on how to opt-out of the automatic update process if they willingly choose to continue running their WordPress site on an older version of the CMS.
In The End, It’s About Safety And People Hours
Proponents of this plan point to safety and security as the reasons driving the proposed updates. WordPress sites are more likely to be hacked and exploited than other CMSes, partly because of the sheer volume of WordPress sites on the Internet. WordPress core developers have been trying to stay one step ahead of hackers for years, and the sheer number of old WordPress installations has meant that increasingly more people hours are required to roll out each new security patch.
As PHP code continues to evolve, the work required to convert security patches written in new PHP code to older versions to suit installations as early as 3.7 has skyrocketed. By ensuring that sites running on CMS version 3.7 and up are auto-updated to more recent versions, the team of WordPress developers will dramatically cut down their workload, streamlining the process of rolling out security updates and patches as needed.
While no official decision or start date has been announced, it appears clear that the minds of WordPress developers have been made up. The process of automatically updating old WordPress sites using the tiered method described above will happen, and there are indications that the entire process is expected to take place within the next year.
While the move should see the Internet become a safer space, vastly reducing the risk of older WordPress sites being hacked or exploited, it does so at the risk of the breakage of individual sites and concerns by many that the move was not an ethically correct one.
WordPress site owners who actively wish to remain on an older version of the CMS – perhaps to maintain compatibility with a particularly nuanced theme or plug-in, and at the risk of potentially severe security issues – will need to ensure that they have opted out of automatic updates prior to the launch of WordPress’s auto-update plans.