Consider to provide a hook to allow developers to hide the auto-updates UI for Core major versions

[audrasjb]

Just like we did for plugins and themes.

Not sure we'll want to fully remove the section or to only disable the checkbox. I'd personally vote for removing the entire section. I guess we don't want to display something that is not actionable.

What would be the best name for this filter?

As we already have plugins_auto_update_enabled and themes_auto_update_enabled for plugins and themes, we could use core_major_auto_update_enabled new filter.

But we can also discuss the opportunity to use the existing allow_major_auto_core_updates filter but I do think we need a different hook: this one is for enabling/disabling the updates, not the interface.

I believe it would be better to introduce a brand new filter for disabling the core auto-updates section on update-core.php. Maybe something like display_core_auto_updates_ui or similar.

Any thought?

[kirasong]

Agreed that it's a good idea for this to be able to be toggled via filter -- in particular for hosts that are handling upgrades either in a different way, or by a different interface.

I've reached out to see if there are any specific preferences at GD, and ​brought it up with the hosting team as well.

[knutsp]

If auto updates are controlled by constants or filters, what should be the purpose of the UI?

In case const WP_AUTO_UPDATE_CORE = true; (or whatever) it appears like changing the setting is possible, but changing the setting have no effect.

In case const AUTOMATIC_UPDATER_DISABLED = true; it seems to have no effect on the UI.

Disabling the checkbox, accompanied by a textual explanation, will properly visualize the state to the admin. The current WP Beta Tester plugin has similar.

I don't see the need for this UI removal, and it could be misused/misunderstood to just remove it without setting proper constants or filters to actually control core auto updates.

In case const DISALLOW_FILE_MODS = true; the entire admin page is gone. This is the best way to handle also this, IMO.

[desrosj]

I think adding a new filter here may be the wrong way to go.

I was just doing some testing locally and found some issues, that when addressed, could strengthen the argument against the need for a new filter.

When the WP_AUTO_UPDATE_CORE constant is defined (or the allow_major_auto_core_updates filter is used), the checkbox reflects the value defined in the constant. However, changing the checkbox state and clicking "Save" will change the value saved in the option, refresh the page, and display the "WordPress auto-update settings updated." notice. The checkbox will continue to reflect the value of the constant, though.

If the UI is respecting the value of the constant or the allow_major_auto_core_updates filter and the user cannot change the behavior of the feature, I think the form should be disabled with a note why they are unable to edit the form.

If that change is made (disabling the form when the constant is defined or allow_major_auto_core_updates filter is used), then I am not sure the UI should ever be hidden. As raised by @aaroncampbell in today's weekly meeting, the update page is only accessible to those with the update_core capability (trusted users). While there may be valid use cases for wholesale hiding the new feature, I haven't seen one yet. To me, disabling the form and explaining why the form cannot be used to update the desired behavior is more valuable to the site owner, as they would be better equipped to make an adjustment.

[jeherve]

I am not sure we need a new filter there right now.

That said, just like @desrosj mentioned above, I would expect the UI to take existing constants and filters into account.

We currently have 2 main ways to set a site's address: you can either use the UI under Settings > General, or you can use the WP_HOME and WP_SITEURL constants. When you use the constants, the UI remains visible, but is grayed out to show that those settings cannot be modified from within the UI anymore.

I think we could follow a similar approach for this UI: always visible, but disabled when one programatically controls the behaviour of the core updates (with the WP_AUTO_UPDATE_CORE constant, for example).

As an added bonus, we could show an explanation label when the UI is disabled, to let site admins know why.

[jeherve]

Related ticket: #47389

I would expect the UI to be disabled when one uses a VCS, to avoid accidentally overwriting files.

[GregLone]

Replying to jeherve:

I think we could follow a similar approach for this UI: always visible, but disabled when one programatically controls the behaviour of the core updates (with the WP_AUTO_UPDATE_CORE constant, for example).

Hi :)

I agree, imho a new filter is not needed since the constant should override the checkbox in the first place (if auto-updates are disabled programatically, the checkbox should have no effects). In that case the UI should be grayed-out or removed.

[SergeyBiryukov]

Replying to jeherve:

We currently have 2 main ways to set a site's address: you can either use the UI under Settings > General, or you can use the WP_HOME and WP_SITEURL constants. When you use the constants, the UI remains visible, but is grayed out to show that those settings cannot be modified from within the UI anymore.

I think we could follow a similar approach for this UI: always visible, but disabled when one programatically controls the behaviour of the core updates (with the WP_AUTO_UPDATE_CORE constant, for example).

As an added bonus, we could show an explanation label when the UI is disabled, to let site admins know why.

Just noting that would make the most sense for me too.

[audrasjb]

Thanks @jeherve @GregLone indeed, makes sense to me as well.

Just to share some information about the current state of this ticket. We are currently awaiting feedback from project lead so we can take the final decision about this.

[audrasjb]

Closed in favor of #51742.