WordPress.org

Make WordPress Core

Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#28707 closed enhancement (invalid)

Expand WP_AUTO_UPDATE_CORE option to automatically do major+minor updates

Reported by: lovingboth Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.9.1
Component: Upgrade/Install Keywords: has-patch
Focuses: administration Cc:
PR Number:

Description

At the moment, there are three options for the WP_AUTO_UPDATE_CORE constant:

true - updates to dev, major and minor releases
'minor' - updates to minor releases (only)
false - does no automatic updates.

There should be a fourth option to allow auto updating to major as well as minor releases. This would give auto updates to all tested releases, but not the less tested beta / release candidates.

It is possible to do this by adding an allow_major_auto_core_updates filter, and the Background Updates For Major Releases plugin does this. But it would be better to have this as configuration option too.

Adding 'major' as an option tested in wp-admin/includes/class-wp-upgrader.php is easy and simple (see attached diff file).

Attachments (1)

also-major.diff (320 bytes) - added by lovingboth 5 years ago.
Diff file for wp-admin/includes/class-wp-upgrader.php

Download all attachments as: .zip

Change History (6)

@lovingboth
5 years ago

Diff file for wp-admin/includes/class-wp-upgrader.php

#1 @lovingboth
5 years ago

  • Focuses administration added
  • Keywords has-patch added

#2 @JDTrower
5 years ago

When I first saw this ticket, I was like, "that makes perfect sense." However, as I have thought about it, I realized that it makes sense for it to be an option but that if this patch gets committed, I do think it would be best if 'major' isn't the default setting. I envision numerous support issues and complaints about broken web sites if WordPress automatically updated to major releases silently. Minor releases rarely break a person's theme or plugins, but a major release can, and often times have broken themes and/or plugins. I love having automatic minor releases for personal and client sites, but I don't know if I would want automatic major releases being done on client sites. I closely follow WordPress development and test client sites on a local server with RCs but I want the opportunity to test with final before going live.

#3 @lovingboth
5 years ago

I am not suggesting - and this patch does not make - 'major' be the default option.

There are indeed good reasons for choosing not to do major updates automatically. It's more likely that plugins and themes can break with major updates rather than minor ones for example.

But if you're prepared to take that chance, as I personally am, then it should be as easy as possible to do so. A simple addition to wp-config.php is easier than adding a plugin. An easier alternative for users would be to add something to the settings menus, but this is beyond my PHP skills.

Allowing easy automatic dev updates - much more likely to break something and generate those tickets - but not easy automatic official major release ones makes no sense to me. Especially as those dev updates happen if you set AP_AUTO_UPDATE_CORE to something as innocent sounding as 'true'.

Having said that, if major+modern were the default, then at least a lot of abandoned sites would be kept up to date rather than being left at the last minor update. But the length of time major releases get security updates is another issue.

#4 follow-up: @lovingboth
5 years ago

  • Resolution set to invalid
  • Status changed from new to closed

Looking a bit more closely at the code, I wonder if it is the documentation that is at fault in implying that you can't already have major+minor upgrades without the dev ones:

should_update_to_version..

.. finds out the installed version
.. and the latest offered version
.. and whether the installed version is a dev version.

It then defaults to

$upgrade_dev   = true;
$upgrade_minor = true;
$upgrade_major = false; 

before processing WP_AUTO_UPDATE_CORE, which may change those.

Then..
// 1: If we're already on that version, not much point in updating?

// 2: If we're running a newer version, that's a nope

Also no if previous attempt failed.

Then I now think that
if ( $current_is_development_version ) {
and the consequent filter and test of $upgrade_dev means that can only be true iff the current version is a development version.

Otherwise, the minor and major updates are filtered and tested.

Ahhh. You have to update to a dev version yourself before it will automatically update to (another) one. If I'm right, which I think I am as this is the behaviour if WP_AUTO_UPDATE_CORE isn't set, this ticket can be marked as invalid (there are no sensible circumstances where you would be using a dev version, and want updates to major+minor but not later dev versions, and if there are you are presumably smart enough to set the filters up to achieve that).

I'll file a bug against the documentation which doesn't make this behaviour clear.

#5 in reply to: ↑ 4 @SergeyBiryukov
5 years ago

  • Milestone Awaiting Review deleted

Replying to lovingboth:

Ahhh. You have to update to a dev version yourself before it will automatically update to (another) one.

Correct.

Last edited 5 years ago by SergeyBiryukov (previous) (diff)
Note: See TracTickets for help on using tickets.