Automatic updates: Mandatory or optional?

Some good discussion about this topic on Slack. I am in favor of enabling automatic updates for minor versions and keeping the existing “hoops” that people need to jump through in order to change this (edit the wp-config.php file or install a plugin), but not everyone agrees.

One thing that helps here is that ClassicPress has a much stronger “non-breaking changes” guarantee than WordPress. This is baked into our versioning structure: if we release a 1.x version that contains a breaking change from another 1.x version, then we blew it.

Full transcript:


I like the idea of being able to toggle auto updates via the admin interface. There are no doubt hundreds of edge cases where this is needed.

There are use cases for this, but the admin interface is the wrong place for this option.

Bit confused as you said “I think an options screen (ideally something like “Advanced”) is better than a step in the installation process.”

Is that not what you meant?

Better, but still a terrible idea.

Disabling updates should require a config file edit. Making this a standard option will lead to hacked sites.

1 Like

I agree with that. It’s already bad enough (for me, at least) that WordFence isn’t CP-friendly yet so it’s operating at half it’s capacity.

In fact, as a web dev who works with small business clients daily, I can tell you with no uncertainty that automatic security updates are ideal. The overwhelming majority of small “mom and pop” business owners I deal with have no idea what Gutenberg is, what CP is, don’t have time to learn how to manage their sites, and just want more customers. And for me, if CP can run auto security patches and updates there is no reason I would not be in favor of that unless I was worried about breaking a site (which no security update should do). I don’t see why anyone would not want security patches unless a site is a “specialty” site with very unique issues - and in those cases, that developer would either know how to tinker with the WP CONFIG file or (like me) have to study up on how to to modify and edit it appropriately. For whatever it’s worth, I would want security patches and updates automated…now if it’s easier to build on…I suppose one could simply update when you see the “updates needed” alert or email…but I think you get my general feelings on the matter.


I agree, I vote for Auto updates for the same reasons. I saw it stated in one of the support threads on that WordFence has been asked to support ClassicPress. The more that ask the more likely that it will be looked at seriously and possibly faster.

I’ve actively nagging them and reminding people to switch to CP.

1 Like

I like to bring a different perspective to this issue…

WordPress has always seemed to adopt the same philosophy which Apple has so successfully championed: We are very intelligent people, so that you do not have to be, and we make very smart decisions, so you do not have to (the philosophy behind “Just Works”).

Works great at the consumer level, but that culture is also why Apple has never successfully penetrated into the corporate IT data centers. Their servers, storage arrays, networking gear, etc. always looks great on the surface, but very quickly gets tagged as “toys” by any competent IT staff.

So much of the [Word/Classic]Press (heretofore [W/C]P) word is made up of web developers and coders. What I’ve always thought is missing is, a high availability/critical infrastructure, corporate IT viewpoint and that of the consultants who live off of SLA based contracts. While you should never see [W/C]P in a true mission critical environment, you do see it in a lot of high availability situations (fund raising event pages, large online retail sales, etc.).

As it stands today, anyone who deploys [W/C]P in any sort of critical high availability type of environment should be fired…immediately. There are a few reasons for this, but lets start with the current patch management, as it is a complete non-starter.

Here is the issue at hand…ClassicPress may say they have a “social contract” and believe they are very smart and extremely diligent, but that is of zero importance. If a web page quits doing what it is supposed to, it is not [W/C]P who will get blamed or have their jobs/contracts be put at risk. Is is the I.T. department / consultant who manages the system who’s ass is on the line.

Because of this alone, it should be the IT dept./consultant who controls the patch management on the system.

Beside, you have no way of knowing what kind risk assessment or tolerance anyone else is using. Bug fixes and security patches which may seem important to you may just be an unnecessary risk to someone else. Change control boards, backups, maintenance windows, etc. may all need to be assesed and addressed. An easy to use, in the wild, complete pwnage security issue which requires a physical port to exploit, might be of zero concern to someone who’s servers are in a hardened data-center vault secured by well armed dudes who have zero since of humor (at one time, I had to sit through a dozen or so LONG meetings discussing that very issue to get a patch through a change control board).

This is also especially true due to the nature of [W/C]P, where it may me installed on a huge number of different combinations of hardware and OSes, and with a nearly infinite number of 3rd party applications and plugins affecting it. You have no way to test even a fraction of those combos, and it doesn’t take much to create chaos.

An example: Several years back I patched a POS system. After the patch, some of the retail products quite processing correctly. Not all, just some. Took us hours to figure out that one of the applications we had was hard quarrying a text file which had a spelling mistake corrected in the POS system patch we applied. Yes… some bone head had hard coded a search quarry which relied on a spelling mistake…but who do you think got the blame for the missed sales? That’s right…the consultants who updated the system.

As far as I am concerned, a person(s)/entity who is responsible for the up-time of a system/web site should be the one who is responsible for ALL patching…period.

Now that the rant is over…

If your position is that there should be some mechanism to push a critical patch to systems to prevent an in-the-wild exploit which is turning [W/C]P into a cloud of zombie bots…OK, maybe. That might be worth discussing. Anything else, should not only have auto-updates disable-able, it should be do so in a way that is readily available.

Conversely, if it is your position that [W/C]P is just a consumer level “toy” which should be limited to things like Myspace like personal blogs or home based store store fronts…well, then never mind (that is just a joke which nicely bookends by post…really, no offence is intended!)


We agree, and we are working on a set of recommendations and documentation to enable this use case. I think it looks something like this:

  • ClassicPress and plugins and themes are installed and managed via composer
  • All deploys are done first to a test environment, and then pushed through perhaps a staging server and then finally to production. Once a change is tested, approved, and committed, deploys are automatic.
  • At the filesystem/OS level, ClassicPress itself does not have permissions to write to anywhere outside of wp-content/uploads and perhaps other selected directories.

What we have so far is here - - and note that we explain how to disable automatic updates on this page.

Under such a scenario, I completely agree. I see two possibilities for such an IT organization or professional.

  1. They are ready, willing, and able to manage their own updates (will set up, test, and receive update notifications, and apply the updates in a timely fashion). They are therefore capable of understanding and editing the wp-config.php file to disable automatic updates, as well as following all of the other advanced steps involved in setting up this environment correctly. This is the current recommendation for people who need to disable automatic updates.
  2. They are not able to follow the necessary steps to do their own updates in a timely fashion, for whatever reason. Therefore they should let us handle updates instead. (Whether we like it or not, most normal users also fall under this category.)

This is not really even a maybe - this is mandatory. The ClassicPress committee voted today to always emphasize security first, and this is a decision I fully agree with.

On our side, we’re not going to use automatic updates for anything with backwards compatibility implications. This is due to our strict and well-defined versioning policy, something which WordPress lacks. More details here: Longevity for CP

I agree with this too, with one important exception: you already have a way to override this decision if you need it. It’s important that you don’t do this without a very good reason, however, so this is why we require that you edit a config file.

Frankly, if editing a config file is too much to ask, then you have no business disabling automatic updates.



Software like CP (and WP) should attempt to be ‘secure out of the box’, and until everyone involved manages to write 100% secure bug free code (i.e. never) having automatic updates within the ‘minor update’ family as the default is part of this.



I know how to edit the config file if I get the code, but then again I like CP having automatic updates for security patches.


OK, what about this scenario:

Core gets a signal for update (core, plugin, theme).

Checks if any backup plugin registered (configuration options here). If “yes”, then sends signal to backup plugin to start backup.

After receiving a signal that backup is successfully completed, proceeds an updates.

Of course, this scenario requires adjusting of the backup plugins, but this is doable.

And yes, there should be some options to configure. Backup before security updates? Backup before minor version? You can come with more options.

This would be a big step from the WP uncertainity.