The WordPress core development team builds WordPress! Follow this site for general updates, status reports, and the occasional code debate. There’s lots of ways to contribute:
These are the weekly notes for the WP Auto-updates team meeting that happened on Tuesday April 14th, 2020. You can read the full transcript on the core-auto-updates Slack channel.
The team focused on making decisions concerning design and wording changes in WP Auto-updates version 0.5:
Remove “cycle” dashicons from the interface
The team agreed the current use of dashicons is not strictly necessary. It appears on every row and it can be too much. Also, the current update system (known as “shiny updates”) doesn’t use any dashicon except for notification messages of available updates.
The decision is to remove it from the user interface to keep it pure text + text links.
In the previous versions of WP Auto-updates, red color were used for “Disable” action links, and green color were used for “Auto-updates enabled” information texts. Last week the team agreed to replace it with standard blue links (as red is used for destructive actions) and black text.
Previously, the feature plugin was displaying the following messages after enabling auto-update for a theme or a plugin:
“The selected plugins will now update automatically.”
“The selected plugins won’t automatically update anymore.”
The team agreed to simplify confirmation messages, and to replace them with:
“Selected plugins will be auto-updated.”
“Selected plugins will no longer be auto-updated.”
This change brings consistency with plugins and themes existing activation message.
A pull request is going to be opened on GitHub to handle the related changes.
Provide information about themes with auto-updates enabled on single-site Themes screen
On a single-site Themes screen (Appearance > Themes), there is currently no way to quickly know what themes have auto-updates enabled. The user needs to open the theme’s modal, and this is a poor user experience.
During the meeting, two solutions were discussed:
Use an icon on the upper-right corner of each theme in the list. It does the job, but there is a question for when the theme have an update available (there is a notification message on the top of the theme screenshot, and it may conflict with the auto-update icon).
Problem: what to do when there is an update notice?
Add auto-update information (or even an enable/disable auto-updates action link) at the bottom of the theme screenshot and put all the action links on a second row.
@pbiron pointed out that as a general rule, auto-updates content should not appear on any screen where updates can not be performed.
Everyone agreed and Paul will add a pull request to handle this issue (#69) and remove auto-updates user interface from Network Admin > Sites > Edit > Themes.
Plugin Conflicts (#146) We reached the conclusion that such conflicts are actually a non-issue. Plugins are expected to override the default sitemap functionality. For consistency reasons, we keep the wp- prefix.
Last modified date (#145) There is one open question on the PR to keep lastmod for object types that support it out of the box (i.e. posts). Current status: needs reviews.
Rewrite Rules (#147) A change was proposed to improve the way rewrite rules are registered for sitemaps. This would avoid having to flush rewrite rules when custom providers are added. Current status: needs contributors / reviews.
Roadmap WordPress 5.5 is ought to be released in August. We settled on the following roadmap for sitemaps:
Fix remaining big issues – April
Refactor code to be closer to WP core standards, add safeguards so nothing breaks after merge – April
Publish Merge proposal – May
Extensibility It was suggested to add a filter for the <urlset> element’s attributes so that plugins could easily add namespaced elements to a sitemap (e.g. for image sitemaps).
That’s because all the countries who switch to Daylight time have done that. The US is traditionally the beginning of a four-week process that ends early in April. The process reverses in the fall.
The Core devchat will start at 20:00 UTC, or 8 pm UTC, on Wednesdays.
That in turn will push the New Contributor meeting and the Release Model Working Group meeting, which alternate Wednesdays immediately beforehand, to 19:00 UTC, or 7:00 pm UTC.
The Release Model Working Group will meet on April 15, and the New Contributor meeting will see you on April 22.
So mark your calendar accordingly, and the teams hope to see you there!
In the meantime, if you celebrate a spring holiday, please accept the community’s wishes for a happy, healthy and safe occasion.
@audrasjb pointed out that the Auto-updates team needs a cross-team discussion about wording and specifically concerning the action links text labels. Design and Accessibility teams could help, and of course everyone interested. Design & Wording validation is the main goal for the next version of the feature plugin.
@garrett-eclipse shared that the Privacy team has a multisite focus in 5.5 so any people from Network/multisite component is welcome to assist.
Daylight saving time: devchat meeting time change
As Daylight saving time already started for every countries/locales on our planet 🌏 the devchat meeting time will be adjusted from 21:00 UTC to 20:00 UTC.
With 5.4 released, let’s officially kick-off 5.5! As we do with each release, we want to fix bugs, add new tools and make WordPress the best user experience. The blocker editor (and full site editing) are still at the top of the WordPress goals list, but what other tickets do you think need some attention in this release cycle?
Share Your Feedback!
What do you want to see included in 5.5?
What are current UX pain points?
What features can we add or iterate on?
Component Maintainers: what tickets of yours do you think will be ready to ship in 5.5 and need some review/feedback/approval/etc?
Note: Adding your ticket here won’t necessarily guarantee inclusion. But no one can fix things they can’t see, so bravely share your thoughts!
