#50052 closed enhancement (fixed)
Plugins & Themes Auto-Updates ๐ค
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | 5.5 | Priority: | normal |
Severity: | normal | Version: | 5.5 |
Component: | Security | Keywords: | needs-testing needs-design-feedback needs-docs has-patch has-dev-note |
Focuses: | ui, administration | Cc: |
Description (last modified by )
WordPress Auto-updates ๐ค
With the maturity of the โWordPress AutoUpdates plugin, let's get this merged to core for WordPress 5.5.
Recent Changes
0.7.0 ๐ฆข
May 6, 2020
- PHPCBF fixes - โ#114
- Remove constants from the feature plugin - โ#112
- Various i18n fixes/optimizations - โ#109
- Simplifies Ajax on both the JS and PHP sides - โ#103
0.6.0 ๐ฆ
April 22, 2020
- Add Ajax to Plugin and Themes Screen - โ#61
- Accessibility: Communicate AJAX enabling/disabling changes to screen readers - โ#85
- Add Better Handling to Ajax Errors - โ#90
- Prevent CSS from being enqueued on sub-site plugins & themes screens in multisite - โ#91
0.5.1 ๐ฆ
April 16, 2020
- Add the plugin version when enqueueing styles, for cache busting - โ#79
0.5.0 ๐ฆ
April 15, 2020
- Replace Disable strings with Disable auto-updates - โ#78
- Update confirmation message wording - โ#77
- Remove Automatic Updates column from the Network Admin > Sites > Edit > Themes screen - โ#76
- Replace "Enable" string with "Enable auto-updates" - โ#75
- Remove dashicons from the UI - โ#74
- Fix documentation and comment standards - โ#73
- Remove green and red colors on texts and links - โ#70
- Don't display the Enable/Disable link in the Theme Details modal on a subsite in multisite - โ#68
- Documentation: Improve DocBlocks - โ#62
- I18n - Merge with similar string - โ#60
- Add filters and constant to allow developers to disable plugins and themes autoupdate email notifications - โ#57
- Switch disable link to red on Multisite Themes Screen - โ#54
- Wrong kick off year in readme.txt - โ#42
0.4.1 ๐บ
April 2, 2020
- Network > Sites > Edit > Themes screen doesnโt have the Autoupdates column - โ#50
0.4.0 ๐น
March 30, 2020
This release brings full support for Themes auto-updates.
It also changes the plugin structure to allow self deactivation when the feature gets merged into WordPress Core.
Please note: the development repository was also migrated from @audrasjbโs personal GitHub account to WordPress.org official GitHub account.
Other changes:
- Change plugin structure to ensure it can self-deactivate when the feature is merged into Core - โ#37
- Handle both themes and plugins email notifications - โ#36
- i18n: Merge similar translation strings - โ#35
Add and populate Automatic updates column, add and handle enable/disable auto-updates bulk actions to the multisite themes list * table - โ#33
- Avoid duplicate Updatingโฆ dialog - โ#32
Attachments (4)
Change History (54)
#1
@
5 years ago
- Keywords needs-patch needs-testing needs-design-feedback needs-codex needs-docs added
- Milestone changed from Awaiting Review to 5.5
- Type changed from defect (bug) to enhancement
- Version set to trunk
#6
follow-ups:
โย 7
โย 8
@
5 years ago
One of the criteria to merge features-as-plugins into core is that the new code meets the WordPress coding standards.
The code conforms to the WordPress coding standards.
Looking at the latest version of the plugin on GitHub, I see the main JS file needs quite a bit of adjustments to meet the coding standards. See โhttps://github.com/WordPress/wp-autoupdates/blob/3c7032b7310569e830a9dadcab0fdb06cacba23e/js/wp-autoupdates.js
#7
in reply to:
โย 6
@
5 years ago
Replying to afercia:
Looking at the latest version of the plugin on GitHub, I see the main JS file needs quite a bit of adjustments to meet the coding standards.
Agreed. See โPR: Fix enabled/disabled count updating for the first step towards that goal.
#8
in reply to:
โย 6
@
5 years ago
Replying to afercia:
Looking at the latest version of the plugin on GitHub, I see the main JS file needs quite a bit of adjustments to meet the coding standards.
See โSimplifies Ajax on both the JS and PHP sides. for a more complete attempt to correct that (which is intended to superseded the other PR I linked to yesterday).
#9
@
5 years ago
@pbiron thanks for clarifying. I was concerned โthe post published on Make 3 days ago claimed the feature plugin as "ready for a core merge", while it appears it's not ready, yet.
This ticket was mentioned in โSlack in #core by audrasjb. โView the logs.
5 years ago
#11
@
5 years ago
Some things worth testing that I remember from Shiny Updates v1 (though not super well, it's been a while):
1) make sure to test plugins who's update contains syntax errors. โhttps://plugins.trac.wordpress.org/browser/this-plugin-should-not-be-used exists for this purpose. You can install version 0.1 and then if you update to 0.2, there is a syntax error.
2) There are some JS events that plugins rely on with updates. Should make sure that there are adequate replacements if needed. See #37216 #37512
3) There is alot of logic for ftp/ssh credentials in the existing workflow. Obviously won't matter for autoupdates, but we should ensure it's not broken for manual updates
#12
@
5 years ago
@jorbin Thank you. Can you also open an issue on the โFeature Plugin repo so we have your thoughts there as well?
#13
@
5 years ago
@pbiron no. This isn't an issue with the plugin, this is thoughts of what needs to happen for core which is developed here.
#14
@
5 years ago
- Description modified (diff)
Updated the description of the ticket to add last plugin version.
#15
@
5 years ago
- Keywords has-patch added; needs-patch removed
50052.diff contains all the functionality from version 0.8.0 of the feature plugin (to be released shortly), except for the help tabs, because the copy for those isn't ready yet.
#16
@
5 years ago
50052.diff looks good here.
Can see couple of tiny optimizations/improvements, like setting __( 'Auto-updates enabled' )
to a var as it is used in two loops in WP_Debug_Data
, but really minor thing. Also perhaps breaking up the long lines for printf()
in WP_List_Table
for better readability, another minor thing :)
This ticket was mentioned in โSlack in #core by azaozz. โView the logs.
5 years ago
#18
follow-up:
โย 28
@
5 years ago
- Keywords needs-dev-note added; needs-codex removed
I tested/compared each feature with the feature plugin ones, and I didn't see any issue on the proposed patch.
Thanks for putting this together @pbiron!
I also took the time to list all those who contributed to the development of this feature from version 0.1.0 to 0.8.0, so they can get props on the first commit of this ticket:
audrasjb, xkon, azaozz, desrosj, pbiron, gmays, pedromendonca, javiercasares, karmatosed, mapk, afercia, gmays, knutsp, whodunitagency, passionate, nicolaskulka, bookdude13, whyisjake, nielsdeblaauw, mukesh27, wpamitkumar, netweb, afragen, davidperonne, paaljoachim
Thanks y'all for your contributions!
This ticket was mentioned in โSlack in #core-site-health by pbiron. โView the logs.
5 years ago
@
5 years ago
refreshes against trunk and adds a few changes from the forthcoming version 0.8.1 of the feature plugin
#20
@
5 years ago
This is looking great, and I think we are ready for merge. @azaozz anything else to add?
This ticket was mentioned in โSlack in #core by whyisjake. โView the logs.
5 years ago
#22
@
5 years ago
Seems like wp_is_auto_update_enabled_for_type
would be useful in wp-includes/update.php
since it seems like it isn't just about the admin UI.
The logic in the WP_Automatic_Updater
seems wrong to me. As far as I can tell, this will stop autoupdates being triggered from the API if the corresponding filter is disabled. I think it should be...
<?php $update = ! empty( $item->autoupdate ); if ( ! $update && wp_is_auto_update_enabled_for_type( $type ) ) { $auto_updates = (array) get_site_option( "auto_update_{$type}s", array() ); $update = in_array( $item->{$type}, $auto_updates, true ); }
This ticket was mentioned in โPR #279 on โWordPress/wordpress-develop by โwhyisjake.
5 years ago
#23
PR to bring auto-updates to WordPress themes and plugins.
This is an extension of โhttps://github.com/WordPress/wp-autoupdates
Trac ticket: https://core.trac.wordpress.org/ticket/50052
This ticket was mentioned in โPR #280 on โWordPress/wordpress-develop by โwhyisjake.
5 years ago
#24
PR to bring auto-updates to WordPress themes and plugins.
Closing #279 in favor of this updated PR.
This is an extension of โhttps://github.com/WordPress/wp-autoupdates
Trac ticket: https://core.trac.wordpress.org/ticket/50052
โwhyisjake commented on โPR #279:
5 years ago
#25
Thanks to @ocean90 and @TimothyBJacobs for their comments here. Moving over to #280 for a proper forked pull request.
This ticket was mentioned in โPR #281 on โWordPress/wordpress-develop by โazaozz.
5 years ago
#26
Trac ticket: https://core.trac.wordpress.org/ticket/50052
This is an extension/additional PR to @whyisjake branch: โhttps://github.com/whyisjake/wordpress-develop/tree/auto-updates-50052 that contains the core patch for "Plugin and Theme Auto-Updates".
#27
@
5 years ago
Thinking 50052.3.diff is ready for commit. There may be few places where the code perhaps can be a bit more readable or simplified, but it overall follows the way the pre-existing/surrounding code was written.
#28
in reply to:
โย 18
@
5 years ago
Replying to audrasjb:
I also took the time to list all those who contributed to the development of this feature from version 0.1.0 to 0.8.0, so they can get props on the first commit of this ticket:
audrasjb, xkon, azaozz, desrosj, pbiron, gmays, pedromendonca, javiercasares, karmatosed, mapk, afercia, gmays, knutsp, whodunitagency, passionate, nicolaskulka, bookdude13, whyisjake, nielsdeblaauw, mukesh27, wpamitkumar, netweb, afragen, davidperonne, paaljoachimThanks y'all for your contributions!
passionate
should be passoniate
โwhyisjake commented on โPR #281:
5 years ago
#30
Merged!
โwhyisjake commented on โPR #280:
5 years ago
#31
Merged!
#32
follow-up:
โย 35
@
5 years ago
- Resolution fixed deleted
- Status changed from closed to reopened
Great work, everyone! Reopening for some minor cleanup.
Could these two filters use a consistent naming pattern?
auto_plugin_update_send_email
send_theme_auto_update_email
For reference, here are the other three new filters:
auto_plugin_theme_update_email
wp_plugins_auto_update_enabled
wp_themes_auto_update_enabled
Do the latter two need the wp_
prefix?
#34
@
5 years ago
@SergeyBiryukov 's question mimicks the one I posted to #core-auto-updates, for reference;
โhttps://wordpress.slack.com/archives/CULBN711P/p1589999882115000
#35
in reply to:
โย 32
;
follow-up:
โย 36
@
5 years ago
Replying to SergeyBiryukov:
Great work, everyone! Reopening for some minor cleanup.
Could these two filters use a consistent naming pattern?
auto_plugin_update_send_email
send_theme_auto_update_email
For reference, here are the other three new filters:
auto_plugin_theme_update_email
wp_plugins_auto_update_enabled
wp_themes_auto_update_enabled
Do the latter two need the
wp_
prefix?
send_theme_auto_update_email
should be changed to auto_theme_update_send_email
.
For reference, the existing filter for whether to send core auto-update notifications is auto_core_update_send_email
. I changed the filter name for plugin auto-update notifications (from what is in the feature plugin) to have that form, but it looks like I just forgot to change the one for themes.
As for the wp_
prefix, they have that prefix in the feature plugin and since there are ALOT of existing filters in core with that prefix I didn't think to remove it. I have no objection to removing it. @audrasjb what do you think?
#36
in reply to:
โย 35
@
5 years ago
As for the
wp_
prefix, they have that prefix in the feature plugin and since there are ALOT of existing filters in core with that prefix I didn't think to remove it. I have no objection to removing it. @audrasjb what do you think?
No objection either ๐
#38
@
5 years ago
Great work here everyone! Great to see this get merged. I did some testing today, and have a bit of feedback.
First, a bug that I found on the themes page.
- Click on Theme Details for a theme.
- Click "Enable auto-updates".
- Auto-updates are correctly enabled.
- Close that theme's overlay.
- Click on Theme Details for the same theme and note that it says "Enable auto-updates" again.
- Refresh the page and view that theme again to see auto-updates is correctly enabled.
The emails also feel like they are lacking a bit of context. For example, the site is not linked to anywhere in the email. It's also not clear if any action is required when receiving the email, and there's no direction where they should navigate if they experience issues.
I think the first two sentences in the Core update email could be repurposed a bit:
Howdy! Some plugins and/or themes on your site at โhttps://site.com have been updated automatically to new versions.
No further action is needed on your part. Here are some helpful links for managing plugins and themes on your site:
- Plugins screen: โhttps://site.com/wp-admin/plugins.php
- Themes screen: โhttps://site.com/wp-admin/themes.php
It's possible that this could have been discussed previously and I missed it while I was out on leave.
I also agree with @SergeyBiryukov and @pbiron above that send_theme_auto_update_email
should be changed to auto_theme_update_send_email
and I don't think that the wp_
prefix is necessarily needed.
The filters could also be moved into the if( ! empty( $update_results['type'] ) )
checks. This is probably a micro-optimization, but this would ensure the filters only run when there are actually updates for that filter type.
I'll continue testing and update with anything else I find!
#39
@
5 years ago
I missed giving props to @ronalfy on the commit. Going to work that in on an update.
This ticket was mentioned in โSlack in #core by whyisjake. โView the logs.
5 years ago
#43
@
5 years ago
- Resolution set to fixed
- Status changed from reopened to closed
I am going to close this ticket again since we covered the filter name changes. Future issues, like #50268, can be opened as needed.
Related: #48850, #49199