View in #migration on Slack
@wpslayer: Is CP going to be forcing updates in the future, like WP has since 3.7? & will there be a choice to turn them off if it is?
@jnylen: Well… you shouldn’t turn them off 
We have a clear versioning policy that covers when we can and cannot make changes that are potentially breaking in any way
v1.x versions must all be compatible with v1.0.0, so we plan to leave auto-updates enabled from v1.0.0 to any later v1.x version
We will not auto-update you to v2 though
the details there remain to be seen, but I expect we’ll implement something similar to how the migration plugin works today
@wpslayer: So, people will still need to have a plugin to stop forced updates.
@jnylen: some automated checks, with clear descriptions of what’s changing
Not sure yet, because it hasn’t been decided.
@wpslayer: Never understood why a simple option couldn’t be allowed. Instead of forcing use of a plugin.
@jnylen: Because that has pretty serious drawbacks
Security releases should be auto-updated to as many people as possible, as quickly as possible
otherwise you are leaving your sites a window where they can be hacked
@wpslayer: So, dictating is still the rationale. I understand. Thanks.
@jnylen: No…
It’s a decision we need to make as a community
But the perspective of security in making that decision cannot be discounted or ignored
@wpslayer: I understand having forced updates defaulted to on. But the option to turn off for those who have reason for delaying updates, should be provided without needing a plugin. My opinion, of course.
@jnylen: Ok, help me out a little here. What’s your rationale for delaying updates?
@wpslayer: First and foremost, allowing for backups prior to updating.
That was my biggest argument when WP went to the forced updates. They argued up to that point, and still, when there is the choice to push the button to update “back up first”. But with forced updates, nobody cares (or should) from dev perspective.
I’ve seen sites taken down by forced updates. Many don’t realize the site is down until they visit it or someone tells them they can’t access the site. People should have the option to check a box or slide a cute little gadget in the admin area to allow them to back their site up prior to updating.
I find it interesting WP forces things upon people like forced updates and Gutenberg but provide no way to make the decision for something else unless you have another plugin installed.
@jnylen: So, our version policy will help a lot here.
If we release any 1.x version with a breaking change, then we have broken our contract with our users.
I realize that’s just words though, until we actually prove it.
I agree a “back up site now” button would be ideal, but there is a reason that there are large, dedicated plugins for this task: it’s complicated.
So the path forward is definitely something we need to discuss.
If we have an option to disable updates, it needs to be hidden behind a big red confirmation button and a list of reasons not to do that.
I think we should also consider an intermediate option like “wait up to 6 hours without confirmation before updating my site automatically”.
Still, I’d prefer to leave this to a filter / wp-config edit / plugin.
Disabling updates should be an informed choice, and I think it’s perfectly OK to make the site owner jump through some hoops if they really want to defeat our security protection.
@wpslayer: I don’t have to have a backup button. I can use a plugin for backing up. I do believe there is a justifiable reason and rationale for allowing an option to stop updates until the site owner or manager wishes to update.
I agree. Disabling updates should be an informed choice.
As stated, default to on.
As I said back when 3.7 was going to be released, it only takes one time for the forced updates to fail to prove my argument. That happened with WP a few times.
@jnylen: Yes, that’s also true.
@wpslayer: I personally don’t like the belief that users are basically stupid.
@jnylen: Again it helps a lot that we’ve thought about this problem and we are adopting a proven solution used by large parts of the software industry.
One way to look at the job of a programmer is to provide functionality while removing potential ways for users to shoot themselves in the foot.
And there are a lot.
@wpslayer: As argued previously by me, the software industry does not, as a standard, force updates. They give the option.
The flaw in the argument about programmers removing potential ways for “users” to shoot themselves in the foot, is believing all (or most) users don’t know what they are doing or they don’t have someone managing their site who does. In the case where they either do or have someone who does, there should be a simple option to turn them off.
@jnylen: Yes, I definitely believe that the average user does not, and should not have to, take the time to understand the intricacies of the software they are using.
Let’s use Firefox - my current browser - as an example.
It auto-updates by default. This is a good choice, I think, because they also have pretty nasty bugs and security issues to push through from time to time.
And they generally do this pretty well, without breaking my web browsing experience.
Anyway, here’s how you disable auto-updates in Firefox:
i.e. you go into the internal configuration of the app and set a flag, in a screen you never even see unless you are a power user.
This is right; this is the way it should be.
@wpslayer: FF also gives the user the option to either not look for updates, or notify them of the update and let the user do it. FF does NOT force updates without the option.
@jnylen: The equivalent for us is wp-config.php.
At least for me, Firefox does not provide an option to disable automatic updates in its default option screens.
I think that’s the right approach: if you want to disable automatic updates, you have to be a power user and you have to go looking for that specific option.
On the other side of that approach is a contract to not break the user’s installation.
As long as I’m core development lead, we will hold up our end of that contract.
@wpslayer: FF does not force updates without option.
@jnylen: Ok, the corresponding screen here looks very different.
Probably due to OS + installation method.
Still doesn’t change the core points of my argument though.
I think this decision is one that we should put before a vote of the committee - that’s the best way we have at the moment to settle potentially contentious issues like this one.
@wpslayer: I didn’t think it would. Nor does your argument change mine. It’s just that you are the one who has the choice.
It’s not something that I can change. I can raise valid points and you make the decision.
@jnylen: I’d prefer not to make the decision unilaterally - I don’t think that’s what’s best for the project.
If no one steps up to discuss and help implement, I will have to
but I think it would be better to present both sides of the issue and have a vote on it.
@wpslayer: Understood.
I agree
@jnylen: Unless we can come up with a better way to solve this.
so, thanks for stepping up to discuss and share your point of view - that’s the first step.
@wpslayer: I’m usually up for discussing. I appreciate what you have to say. I also appreciate the position a lot of people are in who wish to back up their sites or those sites they manage prior to updating. Going into the wp-config.php file for every site owned or managed or installing a plugin on every one of those sites is a PIA. An option in the admin area (with all the red bells and whistles you want to put with it) is a better option for a lot of people. IMO
I’m happy to make the argument whenever and wherever. And put it to a vote, if that is the way it will be done. 
@jnylen: So, do you think an option like “wait 6 hours for confirmation, but then do an auto-update” would be worthwhile?
Let me give a concrete example of what can happen otherwise.
https://wordpress.org/news/2017/01/wordpress-4-7-2-security-release/
> An unauthenticated privilege escalation vulnerability was discovered in a REST API endpoint.
This one was really, really nasty.
It allowed any unauthenticated user to edit any post via the REST API, by passing certain malformed parameters to the API endpoint.
When an issue like this becomes public, it’s an arms race between hackers and the automatic update system.
Within a couple of hours [of that release], we saw tens of thousands of sites get hacked.
So in this case you really benefit from having timely automatic updates.
@wpslayer: I agree with the logic. However, I would argue that the race to get new and better geegaws into WP has created a BIGGER potential for security releases being needed. I don’t believe WP has exercised solid logic and good development practices in their release timeframes.
Too much has become a problem. Too many reports of vulnerabilities (some of which either haven’t been fixed or took a long time to fix) due to not adequately testing prior to release.
CP has the opportunity to change that.
I would agree that a 6 hour confirmation might be a good choice. However, those of us who use security software protect sites until the update can be implemented. Wordfence has not failed in protecting any of my sites or those I manage for several years.
@jnylen: Wordfence would not have caught this issue without its own update. Which is either automatic (in which case many of the same concerns should apply) or not (in which case the same risk is still present).
> CP has the opportunity to change that.
Yes, definitely. I think if CP were releasing something major like a REST API, it would go in a new major version, and the update would be opt-in.
This was also the case for WP: by default, major version upgrades require confirmation.
Our opportunity there is to make it extremely clear (a) what is a major version and what isn’t, and (b) what exactly you’ll be upgrading to, and where the risks are.
@wpslayer: Actually Wordfence did protect against that vulnerability.
https://www.wordfence.com/blog/2017/02/reminder-to-update-to-wordpress-4-7-2-and-check-your-site/
Wordfence: Reminder to Update to WordPress 4.7.2 and Check Your Site
@jnylen: Again, this is either because they updated their rules (automatically) or because the plugin released a new version (manually).
@wpslayer: Point is, the forced update is not the only answer, until the site owner or manager can get the update done.
Wordfence is often one of the companies who find the vulnerabilities.
@jnylen: In this case there was also a forced update: Wordfence regularly updates its firewall rules in the background. This is how they were able to guard against this issue.
If you’ve never noticed that, it’s because they did their job correctly and didn’t break any sites with their updates.
@wpslayer: They also don’t force updates on my sites or those managed by me. Their rules have an effect on the sites where their plugin is installed, but those rules did not require core WP files to be replaced or the database altered.
@jnylen: That difference is arbitrary. The same concerns should apply to Wordfence’s own automatic updates.
Unless you are saying that you trust Wordfence to do its own automatic updates more than you trust WordPress to do theirs.
Which is fair, but I hope ClassicPress would earn a place on the “trusted” list there by example.
@wpslayer: Wordfence is a security software. The purpose of that software is security. That’s why I use it. Their reputation is solid. Some of their features aren’t used by me because the company that manages the server I lease has their own firewall and they advised against using PHP firewalls due to performance issues. I don’t take security lightly. Many people and companies who manage sites take security pretty seriously.
Tell me the difference between a site being taken down by a hacker or one being taken down by a forced update? They are both down. They both require work to get them back up.
I would agree that a site hacked to be used for the hacker’s purpose is dangerous. Many plugins and themes can introduce vulnerabilities.
I don’t allow plugins or themes to force updates. Yoast used to cause all kinds of problems when updated. I never let them force an update either.
I do hope CP earns “trusted”. That would be a welcomed change.
One big check mark in favor of CP is the willingness to discuss and debate prior to making decisions. That’s a biggie in my book. Thanks for that.
@jnylen: > Tell me the difference between a site being taken down by a hacker or one being taken down by a forced update?
They’re both preventable. The solution to preventing hackers exploiting known issues is automatic updates. The solution to a site being taken down by an automatic update is for the software maintainers not to make mistakes with the update.
I am intentionally not using your term “forced update”. We are not talking about forced updates here, we are talking about automatic updates that are enabled by default and have to be disabled via a power user operation.
@wpslayer: Forced updates.
@jnylen: No, it is not forced.
@wpslayer: Actually, yes it is.
If you have to manually go into files to stop it or install a plugin to stop it, it is, by default - forced.
@jnylen: Semantics, but it applies a negative connotation to automatic updates that I am not willing to embrace.
@wpslayer: It is a negative from my perspective.
Precision is a programmers expectation.
@jnylen: Yes, otherwise we cannot program our way out of a paper bag.
(Whatever that actually means in practice.)
@wpslayer: Then semantics is important.
@elisabetta.marina.cle: Let me just put my two pennies in… Some “dreaded” one click installers like softaculous do ASK for an “update policy” prior to installing. Default is applied when not specified. Would it be so “dangerous” having a screen asking for that setting in the installation/migration process? Something explaining what is all about and giving the chance to be at least conscious of what’s going on with updates? It would be a great place to state CP promise not to break sites by update. As usual disregard if my point is silly. And by the way, I am for automatic updates on by default.
@jnylen: I think an options screen (ideally something like “Advanced”) is better than a step in the installation process.
@elisabetta.marina.cle: Yes, that is what I was trying to convey. Something user has to read before flagging, and could be reached only by going on advanced settings
@wpslayer: I like the “Advanced” option.
I also like the option on install.
I believe wholeheartedly that “ON” by default should be the case.
@elisabetta.marina.cle: Yes, and having such an option on installation/migration screen will give us the chance to stress one of our strengths and be different from WP. Even if hidden under an advanced menu, we will be able to give users a level of information they don’t get from WP. Informing is the first step in educating people towards responsible decisions. Doing so in my opinion will push user to take security seriously and be conscious of what is best to ensure site stability.