WordPress.org

Make WordPress Core

Opened 3 weeks ago

Closed 2 weeks ago

#51698 closed defect (bug) (wontfix)

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

Reported by: audrasjb Owned by: audrasjb
Milestone: Priority: normal
Severity: normal Version: 5.6
Component: Upgrade/Install Keywords:
Focuses: Cc:

Description

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?

Change History (16)

This ticket was mentioned in Slack in #hosting-community by mike. View the logs.


3 weeks ago

#2 @mikeschroder
3 weeks ago

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.

Last edited 3 weeks ago by mikeschroder (previous) (diff)

#3 @knutsp
3 weeks ago

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.

This ticket was mentioned in Slack in #core-auto-updates by audrasjb. View the logs.


3 weeks ago

#5 @desrosj
3 weeks ago

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.

This ticket was mentioned in Slack in #hosting-community by mike. View the logs.


3 weeks ago

#7 follow-ups: @jeherve
3 weeks ago

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.

#8 @jeherve
3 weeks ago

Related ticket: #47389

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

#9 in reply to: ↑ 7 @GregLone
3 weeks ago

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.

This ticket was mentioned in Slack in #hosting-community by jadonn. View the logs.


3 weeks ago

This ticket was mentioned in Slack in #core by audrasjb. View the logs.


3 weeks ago

This ticket was mentioned in Slack in #core by hellofromtonya. View the logs.


3 weeks ago

#13 in reply to: ↑ 7 @SergeyBiryukov
3 weeks ago

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.

#14 @audrasjb
3 weeks ago

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.

This ticket was mentioned in Slack in #core by hellofromtonya. View the logs.


2 weeks ago

#16 @audrasjb
2 weeks ago

  • Keywords 2nd-opinion removed
  • Milestone 5.6 deleted
  • Resolution set to wontfix
  • Status changed from assigned to closed

Closed in favor of #51742.

Note: See TracTickets for help on using tickets.