Auto-update (plugin/theme) needs option to restrict to point or patch release

[jqz]

Ref: ​https://make.wordpress.org/core/2020/07/15/controlling-plugin-and-theme-auto-updates-ui-in-wordpress-5-5/

Sorry, late to the party. Auto-update is a good idea, but no responsible web host would allow automatic updates to a live site that could include breaking changes (e.g. an update from 5.4.3 to 6.0.0).

For this feature to be usable, it needs to be restricted to at least point releases only by default, with an option to restrict to patch releases only, on a per-plugin/theme basis (perhaps depending on whether the particular plugin/theme supposedly follows semantic versioning). Only the brave and/or 24/7-on-the-ball would allow automatic updates to a new major version with potential breaking changes.

Apologies if this is a duplicate, I could not find anything by searching.

[desrosj]

This seems like a duplicate of #40663.

Unfortunately this would be nearly impossible to implement. The plugins and themes in the directories are not required to follow any specific versioning practices, so version numbers vary wildly.

Some plugins do follow semantic versioning, but most do not. Some even use 1.2.3.4 versions.

I'm going to suggest that this is closed. Please feel free to add more details if you feel anything I have stated or referenced is incorrect.

Related: ​Meta-trac-3236, #42376, #43495 (for Core).

[jqz]

Replying to desrosj:

This seems like a duplicate of #40663.

No it is not. #40663 relates to version suffixes like -beta, -RC1, etc. I would not expect such releases to be available via automatic update, only final releases with a standard-looking version number, whether X.Y, X.Y.Z or X.Y.Z.N.

Unfortunately this would be nearly impossible to implement.

I strongly disagree. It would be quite simple. It just requires a slightly more flexible range of settings for automatic updates on a per-theme/plugin basis beyond the current binary allow-all/disallow-all.

Perhaps I did not make my suggestion clear. Let me explain.

There are currently two options for automatic updates on a per-theme/plugin basis:

• Allow: any update will be automatically installed;
• Disallow: no update will be automatically installed, they must be installed manually (by clicking on 'Update') as has historically been the case.

I suggest the range of options be extended, on a per-theme/plugin basis as follows:

• Allow all: any update will be automatically installed;
• Allow only point upgrades (this should be the default 'allow' setting): updates will be automatically installed provided the first digit in the version number does not change (i.e. 1.2 -> 1.3 is fine but not 1.2 -> 2.0);
• Possibly another option between the above and below which caters for 4-digit version numbers;
• Allow only patch upgrades: updates will be automatically installed provided only the final and at-least-thirdmost digit of the version number changes (i.e. 1.2 -> 1.2.1 is fine but not 1.2 -> 1.3);
• Disallow: updates must be installed manually (by clicking on 'Update') as has historically been the case.

The plugins and themes in the directories are not required to follow any specific versioning practices, so version numbers vary wildly.

This does not matter, because, with my suggestion, the update policy can be set per theme/plugin by the website administrator based on their knowledge of how that particular theme/plugin uses versioning.

I'm going to suggest that this is closed.

Please re-open this. It would be a shame for the work on automatic plugin/theme updates to have mostly gone to waste and/or otherwise cause website failures due to breaking changes being automatically installed.

[jqz]

Replying to jqz:

Replying to desrosj:

The plugins and themes in the directories are not required to follow any specific versioning practices, so version numbers vary wildly.

This does not matter, because, with my suggestion, the update policy can be set per theme/plugin by the website administrator based on their knowledge of how that particular theme/plugin uses versioning.

Moreover, because plugin/theme "version numbers vary wildly" is why a more flexible finer-grained webadmin-controlled approach to automatic updates is needed, IMO :)

[Adding UI as focus but really mean UX from webadmin POV.]

[audrasjb]

Hello and thank you for opening this ticket,

Replying to jqz:

Replying to desrosj:

Unfortunately this would be nearly impossible to implement.

I suggest the range of options be extended, on a per-theme/plugin basis as follows:

• Allow all: any update will be automatically installed;
• Allow only point upgrades (this should be the default 'allow' setting): updates will be automatically installed provided the first digit in the version number does not change (i.e. 1.2 -> 1.3 is fine but not 1.2 -> 2.0);
• Possibly another option between the above and below which caters for 4-digit version numbers;
• Allow only patch upgrades: updates will be automatically installed provided only the final and at-least-thirdmost digit of the version number changes (i.e. 1.2 -> 1.2.1 is fine but not 1.2 -> 1.3);
• Disallow: updates must be installed manually (by clicking on 'Update') as has historically been the case.

This would add a super hard to understand option in the administration, which would require pro-maintainer-level skills. For me, this is clearly plugin territory and not core territory. Moreover, the current path is to encourage the whole ecosystem to jump into automatic updates for everything, not to case-by-case updates. Not that this is a bad idea: your proposal is a very specific workflow that may interest WordPress maintainers, so it would make sense to develop a plugin for this :)

The plugins and themes in the directories are not required to follow any specific versioning practices, so version numbers vary wildly.

This does not matter, because, with my suggestion, the update policy can be set per theme/plugin by the website administrator based on their knowledge of how that particular theme/plugin uses versioning.

I'm going to suggest that this is closed.

Please re-open this. It would be a shame for the work on automatic plugin/theme updates to have mostly gone to waste and/or otherwise cause website failures due to breaking changes being automatically installed.

I'm following @desrosj in suggesting closing this ticket in favor of a dedicated plugin. For now, the path to handle "website updates failures" is to introduce automated rollback features to Core.

I'm adding back the close keyword but don't take it as it was a bad/wrong idea. It's a nice proposal, but it would be better if implemented in a dedicated plugin.

Also, feel free to attend the next #core-auto-updates weekly meeting on Slack, so your proposal could be discussed :)

(removing version 5.8 as this is not related to WP 5.8)

[chesio]

This can be quite easy implemented with ​auto_update_plugin filter (I use something similar on my websites):

<?php
add_filter('auto_update_plugin', function ($update, $plugin) {
    if (!$update) {
        // Auto updates for this plugin are (already) disabled.
        return $update;
    }

    if (!$plugin->current_version || !$plugin->new_version) {
        // Sanity check: if current or new version number is not available, do not update.
        return false;
    }

    $current_version_parts = explode('.', $plugin->current_version);
    $new_version_parts = explode('.', $plugin->new_version);

    // Only update if major version does not change.
    return $current_version_parts[0] === $new_version_parts[0];
}, 10, 2);

Anyway, I also think it's plugins' territory.

[jqz]

I also think it's plugins' territory.

OK.

This can be quite easy implemented with ​auto_update_plugin filter.

Thanks for pointing this out and providing a good example. I had scanned through the documentation but did not spot that this hook could be used in this way.

[chesio]

@jqz Btw. I'm a big fan of semantic versioning too and I share your sentiment, but as have been said already, WordPress does not enforce it (I would say not even encourage it as WordPress core itself does not adhere to it), so having something like this in core would bring more confusion than utility...

[peterwilsoncc]

I agree with the earlier comments that this is best left to a plugin. It's for much the same reasons so I won't restate them.

@chesio thank you for providing the code sample; @jqz I hope this will give you a head start on limiting updates for plugins that do use semantic versioning.