The WordPress coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. development team builds WordPress! Follow this site for general updates, status reports, and the occasional code debate. There’s lots of ways to contribute:
Found a bugbugA bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority.?Create a ticket in the bug tracker.
After making the auto-updates project a feature plugin, the #core-auto-updates team is excited to announce that the plugins and themes auto-updates feature is ready for a coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. merge.
Here are the main features that have been developed:
The ability for website administrators to opt-in to automatic updates for plugins and themes.
Ability to enable/disable auto-updates on a pluginPluginA plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party-by-plugin and theme-by-theme basis.
MultisitemultisiteUsed to describe a WordPress installation with a network of multiple blogs, grouped by sites. This installation type has shared users tables, and creates separate database tables for each blog (wp_posts becomes wp_0_posts). See also network, blog, site support for both themes and plugins auto-updates.
Email notifications to send auto-update summaries to website administrators.
HooksHooksIn WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same. and constants to help developers programmatically define auto-updates settings.
To be clear, plugin and theme auto-updates already exist in WordPress core, but these new features add a fully-featured user interface to allow administrators to opt-in to these features.The feature was developed on WordPress GitHub repository and tested for a few months as a feature plugin available on WordPress repository.
@audrasjb and @pbiron hosted weekly meetings on #core-auto-updatesSlackSlackSlack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. channel, and those meetings allowed the feature to be developed at a good pace. While there are still some details currently discussed on GitHub, the feature pluginFeature PluginA plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins. has been a great success, with more than 700 active installations. The plugins and themes auto-updates team is now excited to bring this feature to WordPress users and ship this feature in WordPress 5.5.
Site security is integral for modern website hosting, and bringing auto-updates to plugins and themes is a much-awaited feature in WordPress. This will allow website owners to more easily keep their site up-to-date and more secure. The core plugin team has also added a number of hooks that can be used by plugin authors and WordPress developers to customize the feature, including email notifications.
These are the weekly notes for the WP Auto-updates team meeting that happened on Tuesday April 28, 2020. You can read the full transcript on the coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress.-auto-updatesSlackSlackSlack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. channel.
@whyisjake previously started a document to draft the merge announcement, and it should be ready be the end of the week.
Concerning the core merge itself, there are already two existing TracTracAn open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. tickets (#48850 and #49199), but the team agreed that closing those tickets and opening a new one is the best option. We’ll ensure that the new ticketticketCreated for both bug reports and feature development on the bug tracker. has a quick recap of what has been done in the feature plugin, and properly references the previous Trac tickets.
Feature plugin: next releases
While working on the Core merge patchpatchA special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing., @pbiron noticed a few minor differences in the behavior of how some things in the feature plugin work compared to how similar things in the plugins/themes list tables work in core (specifically concerning bulk edits). They aren’t really bugs or enhancements, but it would make things more consistent. For example, WP_Plugins_List_Table doesn’t add the Activate bulk action to the dropdown if the current view is Active plugins, and we are currently always adding Enable Auto-updates even when on the Auto-updates enabled view. Those small changes can also be directly addressed in the Trac ticket.
@pbiron also raised this issue, which aims to discuss how plugins that have auto-updates enabled could be visually identified in WordPress adminadmin(and super admin). @apedog suggested to implement auto-updates action links into pluginPluginA plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party row actions section. @audrasjb answered it was previously discussed, and the conclusion was that it is not the best choice, given that “Activate” (plugin) and “Enable” (plugin auto-update) links would introduce confusion, especially on Locales that don’t have any difference between those two terms.
@pbiron raised an issue in the Plugins screens using small viewports, but it appeared it was related to another plugin.
These are the weekly notes for the WP Auto-updates team meeting that happened on Tuesday April 21, 2020. You can read the full transcript on the coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress.-auto-updatesSlackSlackSlack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. channel.
Last minute edit: WP Auto-updates 0.6 was released earlier today 💥
Next step: Core merge proposal
The idea is to start to work on the core merge proposal once version 0.6 is released.
Concerning the core merge itself, @audrasjb two approaches:
Merging the feature in a single TracTracAn open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress.ticketticketCreated for both bug reports and feature development on the bug tracker.
Pros: Easier testing of the overall scope.
Cons: A single ticket could be a potential rabbit hole, with endless discussions on the overall feature, so it could be more efficient to manage small and self contained tickets.
Merging the feature step by step, with several tickets
Pros: It’s more efficient to ship the feature step by step so the steps that are potential blockers could land later, in other releases, if they deserves more discussion. This is the process we used for the development of the feature plugin so it won’t be so difficult to reproduce those steps in several Trac tickets.
Cons: It’s a way more difficult to test the overall feature when there are several tickets to test.
Please feel free to comment this post to share your thoughts!
As noted by @whyisjake and @sergeybiryukov, both approaches makes sense. @pbiron noted that Lazy-loading Feature was done in one commit. However, the feature doesn’t bring any UIUIUser interface change.
For @whyisjake, WP Auto-updates is pretty light as well and could fit with the single patchpatchA special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing. option.
For @afragen, if the merge tickets can be made in logical, non-dependent code blocks, then it would probably be good to do it this way. Otherwise as a single patch.
@whyisjake pointed out that even if the feature is a goal for 2020, it will necessarily need an approval from @matt / @chanthaboune, first.
As it’s a mandatory first step, @whyisjake proposed his help on the Core merge proposal post and started a collaborative Google Doc.
The idea is to publish this post next week, to fit with WordPress 5.5 Alpha development planning.
@pbiron added that once our work is merged into core, we should all be prepared for some things to be reverted/changed after the first “real world” betaBetaA pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. tests.
Open floor
@ronalfy asked if there is any plan to handle translations auto-updates, like email notifications. @sergeybiryukov answered that when language packs were added to core, the idea was that they should always update automatically in the background and do not need a specific UI or notifications.
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 coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress.-auto-updatesSlackSlackSlack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. 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 pluginPluginA plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party:
“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 GitHubGitHubGitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ 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 conflictconflictA conflict occurs when a patch changes code that was modified after the patch was created. These patches are considered stale, and will require a refresh of the changes before it can be applied, or the conflicts will need to be resolved. 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.
Quick workaround: all action buttons are placed on a second row.
Remove auto-updates UIUIUser interface from Networknetwork(versus site, blog)Adminadmin(and super admin) > Sites > Edit > Themes
@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.
These are the weekly notes for the WP Auto-updates team meeting that happened on Tuesday April 7th, 2020, based on this agenda. You can read the full transcript on the coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress.-auto-updatesSlackSlackSlack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. channel.
As a reminder, version 0.4 was released one week ago and contains all the core functionalities of the project. The team opened a call for testers on Make/Tests.
The main goal of version 0.5 is to iterate on design and wording. There is a bunch of design focused issues, but the idea is to iterate on links colors and wording first.
All the attendees think all the links should be blue and text should be black. Indeed, red links are used for destructive actions in WordPress core, and it’s not relevant for auto-updates disabling. So let’s get rid of red links and green “Auto-updates enabled”. Let’s just use blue for links and black for text. This change will be part of 0.5.
About wording, @audrasjb wanted to point out that “auto-update” (don’t forget the hyphen) is the official wording for the feature in WordPress as it has been validated ahead of the Feature Plugin with WP project leads.
@pbiron pointed out his concerns about removing any filters on the plugins screens, especially the “Auto-update disabled” filterFilterFilters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output., as it’s really useful to see what plugins are not auto-updated. The team agreed that this filter is not going to be removed.
How to avoid conflicts with third party plugins?
@ronalfy pointed out, from a third-party standpoint, that if a pluginPluginA plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party uses a custom option for storing updates, it’d be nice to be able to sync the two through actions and filters. So if WordPress enables an auto-update, the plugin can hook into that action and update their own list accordingly. The same would be useful for filters when retrieving options so the plugin could theoretically merge the two. Ideally third-parties could just use WordPress options, but there’s backwards compatibility issues there.
@timothyblynjacobs added that being able to add bits to the auto update column itself would be useful as well.
Next steps:
Add an action hook on auto-update enabling and disabling for each theme/plugin.
Add a hook to filter the auto-update column content itself.
Discussion/decision concerning AJAX handling in the Feature Plugin
While this is not a top priority, it’s a nice to have. The team agreed to target version 0.6 for this enhancementenhancementEnhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature..
Discussion about the labels used for enabling/disabling auto-updates
There is a proposal to change the current action links labels.
@pbiron and @audrasjb pointed out that on/off and “plain” Enable/Disable (without “auto-updates”) could be too easily confused with Activate/Deactivate (even with them being in the Automatic Updates column).
There is definitely a need for a cross-team discussion about the best wording for those links.
Meeting time and Daylight Saving Time
The team agreed to move the meeting time from 18:00 UTC to 17:00 to follow Daylight Saving Time.
Homework: @pbiron asked attendees to think about how can we avoid conflicts with third party plugins
Discussion/decision concerning AJAX handling in the Feature PluginFeature PluginA plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins.
Discussion about the labels used for enabling/disabling auto-updates
Daylight Saving Time: should we move the meeting time?
Remove update time text after manual update – PR 43
Ensure “Automatic Updates” column is not added if no content would be output in the column – PR 57
Specific messages for delayed or disabled cron events – PR 58
Prevent mis-match between count in Auto-updates Enabled view and the number of plugins displayed for that view by applying ‘all_plugins’ filterFilterFilters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. before computing that count. – PR 59
Thanks @pbiron for his invaluable help on version 0.3.
@audrasjb shared a screenshot with an example of email notification:
Please feel free to propose string changes to this first implementation of email notifications.
Version 0.4.0 will focus on backporting every auto-updates features to Themes.@audrasjb to merge this pull request as a first step for the work on themes support. Then, the idea is to open pull requests for each function/feature to be backported, so it’s easier to track progress on themes support.
@bookdude13 asked whether it’s better to open up issues to break up the work on the themes port, or to directly address them with pull requests.
@audrasjb will open an issue to list all the functions/feature that need proper backportbackportA port is when code from one branch (or trunk) is merged into another branch or trunk. Some changes in WordPress point releases are the result of backporting code from trunk to the release branch. and to track the team’s progression.
There is also a few background tasks opened by @jeffpaul concerning the GitHubGitHubGitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ repository.
Concerning Email notifications, @joostdevalk proposed to add links to the plugins changelog in those emails. @pbiron answered that it might be hard for plugins/themes not in the WordPress.orgWordPress.orgThe community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ repo. @joostdevalk proposed to make it filterable. @audrasjb proposed to make the notification entirely filterable. @joostdevalk felt concerned about plugins that would override the email even when multiple plugins are updated at once.
@afragen proposed to use a filter that could be specific for each, like for example: apply_filters( 'wp_autoupdates_email', $text, $slug )
This item will be discussed again during the next team meeting.
@pbiron wanted to discuss a specific pull request. It proposes to add filters to control whether the Enable/Disable buttons appear in the UIUIUser interface for a given pluginPluginA plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party. @pbiron and @audrasjb agreed that having a filter that is specific to the UI is not the way to go and it is to be filterable then the existing auto_update_plugin hook should be used. For now, the pull request will stay open for further discussion.
Next meeting is planned on Tuesday March 24, 2020 at 18:00 UTC and will take place on #core-auto-updatesSlackSlackSlack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. channel.
It was the first meeting for the Plugins & Themes Auto-updates feature, and this kick-off meeting was really efficient and worthwhile for the project 🚀
WP Auto-updates feature general scope
Here is the current general scope of the Feature PluginFeature PluginA plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins.:
Ability for website administrators to opt-in to automatic updates for plugins and themes in the related WP-Adminadmin(and super admin) screens
✅ Done for plugins
🔲 Themes: needs to be ported. Slated for milestone 0.4.
Ability to enable/disable auto-updates on a pluginPluginA plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party-by-plugin and theme-by-theme basis
✅ Done for plugins
🔲 Themes: needs to be ported. Slated for milestone 0.4.
Email notifications to send regular auto-update summaries to website administrators
🔲 Plugins: Slated for milestone 0.3.
🔲 Themes: Slated for milestone 0.4.
HooksHooksIn WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same. and constants to help developers disable or programmatically define auto-update settings
✅ Done for plugins
🔲 Themes: needs to be ported. Slated for milestone 0.4.
For the moment, the team started with plugins autoupdates, then all this work will have to be ported to Themes screen.
Last week, version 0.2.0 was released with a lot of enhancements and bugfixes. Here is the complete changelog:
Remove auto-updates column from must-use and drop-ins screens – PR #39
Ensure the the enable/disable bulk actions appear in the dropdown and are handled in multisitemultisiteUsed to describe a WordPress installation with a network of multiple blogs, grouped by sites. This installation type has shared users tables, and creates separate database tables for each blog (wp_posts becomes wp_0_posts). See also network, blog, site – PR #38
Remove dashicon from “Enable” text in plugins auto-updates column – PR #36
Replace “Automatic Updates” with “Auto-updates” in filters – PR #35
Display only filters with at least one available plugin – PR #33
Remove setting from site option when deleting plugin – PR #32
Populate site health with plugins auto-updates informations – PR #24
In multisite, only add the “Automatic Updates” column on the plugins-networknetwork(versus site, blog) screen – PR #21
Add auto-update-enabled and auto-update-disabled views on the plugins screen – PR #18
@pbiron noticed some PHPPHPThe web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher notices on version 0.2.0 and made a pull request to fix them. It is milestoned for version 0.2.1, later this week.
@audrasjb shared some screenshots of the current design of WordPress Admin screens:
Click images to open them in full size (it will opens in a new tab).
@mclancy3 will open GitHubGitHubGitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ issues to provide some feedback on the Plugins screen’s user interface.
Work in progress
@pbiron raised an issue with a premium plugin that assumes there is no extra column on the plugins list table and add its own column with a colspan attribute. As mentioned by @clorith, this is not a bugbugA bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. in WP Auto-update feature plugin but rather a bug in this particular plugin. @jeffpaul proposed to add this to a Known Issues/Caveats section in readme files.
@jeffpaul also proposed to port the Features/to-do list section from readme.md into GitHub issues. @audrasjb already ported Email notifications and Themes auto-updates into issues, and @jeffpaul will take care of the remaining ones.
@jeffpaul pointed out that 10up uses two GitHub Actions to help deployDeployLaunching code from a local development environment to the production web server, so that it's available to visitors. plugins to WordPress.orgWordPress.orgThe community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ as well as readme/asset updates. He proposed to submit a PR to add those here and help streamline deploys to WordPress.org. For the moment, @audrasjbgenerates releases from the GitHub repository and deploy them manually on the plugin repository, using SVNSVNSubversion, the popular version control system (VCS) by the Apache project, used by WordPress to manage changes to its codebase.. If it’s not a top priority, it would be nice to improve this workflow.
As proposed earlier in coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress.-sitemaps meeting, @pbiron suggested to add a label to issues when something different will have to be done to the plugin code when it gets merged into core. @audrasjb stated that it would be nice to introduce this kin of labels and also to use DocsBlocks comments to point out things that will need specific implementation on WP Core. @jeffpaul proposed to use a GitHub pull request template for that.
About next development steps, @audrasjb is currently implementing email notifications. It shouldn’t be a problem given there is an useful automatic_updates_complete action to hook on.
Porting auto-updates features from Plugins to Themes will probably be a way more difficult, as there is not so much hooks in the Themes screen template. Themes in multisite is fairly straightforward, since a list table is used there, but for single sites there is no list table so what we’ve done for plugins won’t really apply. We’ll probably end up with JavaScriptJavaScriptJavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/. hacks to include the interface opt-in buttons and informations. @jeffpaul proposed to expand the focus of 5.4.x to include those hooks in the themes screen, which sounds like a perfect option right now.
@audrasjb thinks this issue is out of the feature plugin’s scope. @clorith added that if auto-updates are off by default, yes this would be out of scope for the first release, but definitely something to look into in the future. If they are on by default, this would be a blockerblockerA bug which is so severe that it blocks a release.. @audrasjb answered that Plugins, Themes and Core (major) auto-updates are all meant to be opt-in, in the 2020 general roadmap. The team agreed to keep this issue open for the moment.
@audrasjb said Postponing updates is a great feature, but it’s not on this feature plugin scope, and not sure it’s even in Core scope. @clorith pointed out that the core solution should facilitate by providing filters and such, but not add all those options. The team agreed to keep this issue open for the moment.
Next steps
@audrasjb will focus on email notifications development and grant GitHub commit access to @pbiron.
A call for testing will be published on Make/Test once 0.2.1 is released with the PHP notices fixes.
@jeffpaul will work on improving the GitHub repository organization.
Now, the idea is to gather more contributors around the feature pluginFeature PluginA plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins. and get your feedback on the project.
The first meeting will be held on Tuesday March 10th, 2020 at 18:00 UTC and will serve as an introduction to the project and as an opportunity to discuss the next steps.
Proposed agenda:
WP Auto-updates feature general scope
Current status
Next steps
Openfloor / issues and pull requests reviews
If you have anything specific that you’d like to propose being discussed in this meeting, feel free to leave a comment below.
WordPress 5.4 BetaBetaA pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. 1 was released on Tuesday 11 as expected 🎉
The Docs squad has published the first two dev notesdev noteEach important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include a description of the change, the decision that led to this change, and a description of how developers are supposed to work with that change. Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase.:
The idea is to publish dev notes as soon as possible during the beta cycle and then publish the Field GuideField guideThe field guide is a type of blogpost published on Make/Core during the release candidate phase of the WordPress release cycle. The field guide generally lists all the dev notes published during the beta cycle. This guide is linked in the about page of the corresponding version of WordPress, in the release post and in the HelpHub version page. before Release Candidaterelease candidateOne of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta)..
@audrasjb offered a quick update on Automatic Updates for Plugins and Themes. Because there is still work needed, along with extensive testing, decision is to start by managing autoupdates in a feature pluginFeature PluginA plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins. and then merge into CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. for 5.5.
Work on this feature plugin will start in the coming weeks.
In 2014, Administrationwas proposed to be moved from a component to a focus so it wouldn’t end up as a dumping ground for tickets. That decision led to its removal from the Components page, but not anywhere else.
Recently, this component returned to the Components page as per this Meta ticket, and it turned out that Administration still has a lot of tickets. The long term idea is to triagetriageThe act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. all the tickets that are there and, as part of that process, move those tickets to other components with the administration focus.
@whyisjake told the group that he’s going to help Two-Factor Authentication, currently developed on GitHub, move toward becoming a feature plugin for WordPress Core.
@whyisjake shared that he attended the CMS Security Summit last week, and Two-Factor Authentication was a major takeaway from the event, as was bringing automatic updates into Core.
@xkon added that #49200 needs input, so the team asks for yours. If you have any interest at all in cryptographic signature for plugins and themes, please follow the discussion on the dedicated Slack channel, core-signatures, and consider helping out.
You must be logged in to post a comment.