Auto-updates feature meeting summary: April 14th, 2020

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 coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.-auto-updates SlackSlack Slack 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, the Feature PluginFeature Plugin A plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins. is developed on GitHub and is available for testing on WordPress.org plugins repository.

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.

It fixes GitHub issue #71 and it is going to be addressed in pull request #74.

Replace “Enable” with “Enable auto-updates”

The team agreed that single word actions can be confusing, especially for small screens and for screen reader users.

It fixes GitHub issue #72 and it is going to be addressed in pull request #75.

Remove red links and green text

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.

It was already addressed in GitHub pull request #70.

Confirmation messages

Previously, the feature plugin was displaying the following messages after enabling auto-update for a theme or a pluginPlugin A 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 GitHubGitHub GitHub 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 conflictconflict A 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).

@paaljoachim tested this solution:

Icon on the upper-right of each theme.
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.

@audrasjb made a quick workaround:

Quick workaround: all action buttons are placed on a second row.

Remove auto-updates UIUI User 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.


Next meeting is scheduled on Tuesday April 21, 2020 at 17:00 UTC

#auto-update, #feature-plugins, #feature-projects, #feature-autoupdates

XML Sitemaps Meeting: April 14th, 2020

Meeting Recap: April 7th

For reference, check out the previous blogblog (versus network, site) post from April 7th:

What we’ve discussed last week:

  • PluginPlugin A 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 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 coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. standards, add safeguards so nothing breaks after merge – April
    • Publish Merge proposal – May
  • Extensibility
    It was suggested to add a filterFilter Filters 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. for the <urlset> element’s attributes so that plugins could easily add namespaced elements to a sitemap (e.g. for image sitemaps).

Agenda: April 14th

The next meeting will be held on Tuesday, April 14th at 16.00 CET.

Items on the agenda so far:

Want to add anything to the above? Please leave a comment here or reach out on SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/..

This meeting is held in the #core-sitemaps channel. To join the meeting, you’ll need an account on the Making WordPress Slack.

#agenda, #feature-plugins, #feature-projects, #sitemaps, #xml-sitemaps

Auto-updates feature meeting summary: April 7th, 2020

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 coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.-auto-updates SlackSlack Slack 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, the Feature PluginFeature Plugin A plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins. is developed on GitHub and is available for testing on WordPress.org plugins repository.

Current status of the project – version 0.4 🌹

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.

Version 0.5 scope and timeline

For the moment, there are 5 PRs merged into milestone 0.5.

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” filterFilter Filters 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 pluginPlugin A 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.

For reference, see issue #63 and pull request #66.

@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 enhancementenhancement Enhancements 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.

#auto-update, #feature-plugins, #feature-projects, #feature-autoupdates

XML Sitemaps Meeting: April 7th, 2020

Meeting Recap: March 24th & 31st

For reference, check out the previous blogblog (versus network, site) post from March 24th:

Things that have been discussed in the last two meetings:

  • PluginPlugin A 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 Conflicts (#146)
    We discussed the rewrite rules conflicts that might currently happen with certain plugins. A consensus hasn’t been reached so far, but it could actually be declared a non-issue: if plugin A overrides the default sitemap functionality, that might be intended behavior.
    Current status: needs decision.
  • 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.
  • Last modified date (#145)
    The PR to remove all traces of lastmod has been updated to include documentation.
    Current status: needs reviews.
  • Filterable query args
    #137 has been closed in anticipation of an improved solution to filterFilter Filters 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. query arguments.
    Current status: needs PR.
  • Private sites (#138)
    Current status: PR needs some work
  • Roadmap
    WordPress 5.5 is ought to be released in August. We need to continue working on the feature pluginFeature Plugin A plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins. so we have something merge-able in May or June. The tentative roadmap would be:
    • Fix remaining big issues – April
    • Refactor code to be closer to WP coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. standards, add safeguards so nothing breaks after merge – April
    • Publish Merge proposal – May

Agenda: April 7th

The next meeting will be held on Tuesday, April 6th at 16.00 CET.

Today’s agenda is rather straightforward so far:

  • Plugin conflicts
  • Last modified date (#145)
  • Road towards WordPress 5.5
  • Currently open issues and pull requests
  • Open floor

Want to add anything to the above? Please leave a comment here or reach out on SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/..

This meeting is held in the #core-sitemaps channel , to join the meeting, you’ll need an account on the Making WordPress Slack.

#agenda, #feature-plugins, #feature-projects, #sitemaps, #xml-sitemaps

Auto-updates feature weekly meeting agenda – April 7th, 2020

Next meeting is scheduled on Tuesday April 7, 2020 at 18:00 UTC and will take place on #core-auto-updates SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. channel with the following agenda:

  • Version 0.5 scope and timeline
  • 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 Plugin A 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?

See you tomorrow!

#agenda, #auto-update, #feature-plugins, #feature-projects, #feature-autoupdates

Feature Plugin Proposal: WP Consent API

As part of the core-privacy team’s roadmap the team has started development on a Consent APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. as a feature plugin.

We welcome all thoughts on this proposal, which you are welcome to leave as comments on this post, or share with us directly in the #core-privacy channel on Making WordPress SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/.. We host weekly office hours on Wednesdays at 19:00 UTC, see the meetings page for times in your timezone.

Introduction

A standard way for WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress., plugins, and themes to obtain consent from users should be established to provide a consistent and stable experience for administrators, developers, and users of all kinds.

Currently it is possible for a consent management pluginPlugin A 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 to blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. third party services like Facebook, Google Maps, Twitter, if a user does not give consent. But if a WordPress plugin places a PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher cookie, a consent management plugin cannot prevent this.                                         

There are also WordPress plugins that integrate tracking code on the client side in javascriptJavaScript JavaScript 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/. files that, when blocked by a consent management plugin, break the site. Or, if such a plugin’s javascript is minified, causing the URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org to be unrecognizable, it won’t get detected by an automatic blocking script.

Lastly, the blocking approach requires a list of all types of URL’s that place cookies or use other means of tracking. A generic API which plugins adhere to can greatly help a webmaster in getting a site compliant.

Does usage of this API prevent third party services from tracking user data?

Primarily this API is aimed at helping to achieve a compliant use of cookies or other means of tracking by WordPress websites. If a plugin or custom code triggers for example Facebook, usage of this API will be of help to ensure consent. If a user manually embeds a facebook iframeiframe iFrame is an acronym for an inline frame. An iFrame is used inside a webpage to load another HTML document and render it. This HTML document may also contain JavaScript and/or CSS which is loaded at the time when iframe tag is parsed by the user’s browser., a cookie blockerblocker A bug which is so severe that it blocks a release. is needed that initially disables the iframe and or scripts.

Third-party scripts have to be blocked by a blocking functionality in a consent management plugin. To do this in core would be too intrusive, and is also not applicable to all users: only users with visitors from opt in regions such as the European Union require such a feature. Such a feature also has a risk of breaking things. Additionally, blocking these and showing a nice placeholder, requires even more sophisticated code, all of which should not be part of WordPress core, for the same reasons.

That said, the consent API can be used to decide if an iframe or script should be blocked.

How does it work?

There are two indicators that together tell if consent is given for a certain consent categoryCategory The 'category' taxonomy lets you group posts / content together that share a common bond. Categories are pre-defined and broad ranging., e.g. “marketing”:

  1. The region based consent_type, which can be optin, opt out, or other possible consent_types;
  2. The visitor’s choice: not set, allow or deny.

The consent_type is a function that wraps a filterFilter Filters 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., wp_get_consent_type. If there’s no consent management plugin to set it, it will return false. This will cause all consent categories to return true, allowing cookies and other types of tracking for all categories.

If optin is set using this filter, a category will only return true if the value of the visitor’s choice is allow.

If the region based consent_type is opt out, it will return true if the visitor’s choice is not set or is allow.

Clientside, a consent management plugin can dynamically manipulate the consent type, and set the applicable categories.

A plugin can use a hook to listen for changes, or check the value of a given category.

Categories, and most other stuff can be extended with a filter.

Existing integrations

  • Cookiebot
  • Complianz
  • Example plugin. This plugin basically consists of a shortcodeShortcode A shortcode is a placeholder used within a WordPress post, page, or widget to insert a form or function generated by a plugin in a specific location on your site., with a div that shows a tracking or not tracking message. No actual data tracking 🙂

Demo site

Plugins used to set this up:

Technical Scope

The feature pluginFeature Plugin A plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins. should at least handle the following functionality:

  • PHP functions to set the consent level and consent type.
  • PHP functions to retrieve the consent level and consent type.
  • Javascript functions to set the consent level.
  • Javascript hook that fires when a consent level is set.
  • Javascript functions to retrieve the consent level.

Introducing the Feature Plugin

What’s next?

Once the plugin is confirmed as a feature plugin, the next steps would be:

  • To increase the number of users of the feature plugin.
  • To add other interested privacy team members and core developers as contributors of the plugin.
  • To have additional Third-Party consent management plugins to adopt the API.
  • To iterate on the feature plugin development.
  • To audit some specific aspects of the feature plugin:
    • security
    • coding-standards and documentation
  • To create a TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. ticketticket Created for both bug reports and feature development on the bug tracker. to handle a potential future merge proposal – if the feature plugin deserves it.

Post written by @rogierlankhorst / @paapst and reviewed by @garrett-eclipse / @carike

#consent-api, #core-privacy, #feature-plugins, #privacy, #privacy-roadmap

XML Sitemaps Meeting: March 24th, 2020

In case you were looking for an blogblog (versus network, site) post about the XML Sitemaps feature project last week, worry no more. Work on the pluginPlugin A 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 is progressing smoothly and steadily, we just didn’t publish an agenda post last week. That means it is time for a double update today!

Meeting Recap: March 10th & 17th

For reference, check my previous blog post from March 10th:

A lot has happened since then. Here’s the summary, not necessarily in the right order:

  • SimpleXML dependency
    We received great feedback from a variety of big hosting providers, all saying that this PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher extension is widely available and we can rely on it safely.
    Current status: no action needed.
  • Rewrite rule conflictconflict A 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 plugins
    As we realized that the new /wp-sitemap.xml URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org format clashes with big existing plugins, we decided to look into alternate names for both the rewrite rules as well as the query params. See GitHub issue for details.
    Current status: needs contributors.
  • Rewrite rule issues with custom providers
    It was reported that adding custom sitemap providers might require flushing rewrite rules. Ideally, that shouldn’t be needed.
    Current status: needs decision.
  • Last modified date (lastmod)
    We decided to continue with the proposed PR to remove lastmod from sitemaps (at least for now), but need to make sure there is appropriate documentation. It’s something that can always be added back if needed.
    Current status: has PR, needs documentation.
  • Query Filters
    Valuable feedback emerged from testing, which led to the decision to close the existing PR to make query instances filterable in favor of a simpler approach. In its place, we should make the query arguments filterable, and also add filters to short-circuit queries.
    Current status: needs contributors.

Please let me know in the comments if I got something wrong in this summary!

Agenda: March 24th

The next meeting will be held on Tuesday, March 24 at 16.00 CET.

Today’s agenda is rather straightforward so far:

Want to add anything to the above? Please leave a comment here or reach out on SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/..

This meeting is held in the #core-sitemaps channel , to join the meeting, you’ll need an account on the Making WordPress Slack.

#agenda, #feature-plugins, #feature-projects, #sitemaps, #xml-sitemaps

Dev chat summary, March 18, 2020

@marybaum facilitated the chat on this agenda.

Full meeting transcript on Slack

This devchat marked week 10 of the 5.4 release cycle.

Announcements

WordPress 5.4 Release Candidate 3 was released on Tuesday March 17th! 🎉Thank you to everyone that has contributed! @johannlinnarsson asked when we might expect the final 5.4 release and @marybaum confirmed that March 31 is the target release date. 

Upcoming releases WordPress 5.4

WordPress 5.4 About Page: @karmatosed shared that many many folks contributed to the design and creation of the About page. Thank you to everyone that contributed. Testing is very much appreciated at this point as we prepare for release candidaterelease candidate One 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). 4 on March 24.

@jorgefilipecosta mentioned that there are two pull requests that are in need of review for 5.4 and those can be found at this link.

 @clorith asked if there was any additional information regarding the recent changes to editor default views and there is currently no new information outside of the discussions in the blogblog (versus network, site) post. 

Components Check-In

@azaozz had some exciting Media updates showing off the now merged 1.1 changes for the Lazy Loading Feature Plugin and said that he will be working on a patchpatch A 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. to introduce in trunktrunk A directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running "trunk", then you are on the latest revision. (5.5.) More to come soon on this much anticipated feature! If you’d like to contribute here is a link to the GitHub repo.

@audrasjb introduced some new changes to WP Auto Updates saying, “WP Auto-updates Feature PluginFeature Plugin A plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins. version 0.3.0 was released with email notifications for plugins automatic updates. Next version will be focused on porting all the current features to themes screen.” A summary of this chat can be found at this link. If you would like to get involved in contributing to this feature, please feel free to jump into the Feature Plugin GitHub repo.

@pbiron mentioned another pluginPlugin A 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 that could benefit from some testing; Core Sitemaps plugin is aiming for an early inclusion into 5.5. Please feel encouraged to test it ahead of time! If you’d like to contribute to this feature, explore the GitHub repo!

@aduth provided a #core-js update around their processes. He said, “In the #core-js chat this week, it was suggested to share that our weekly meeting summaries are now including a “News Roundup” of JavaScriptJavaScript JavaScript 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/. and GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/-related items, for those who might be interested or think it helpful to keep in the loopLoop The Loop is PHP code used by WordPress to display posts. Using The Loop, WordPress processes each post to be displayed on the current page, and formats it according to how it matches specified criteria within The Loop tags. Any HTML or PHP code in the Loop will be processed on each post. https://codex.wordpress.org/The_Loop.. “ A link to that can be found at the end of this summary post.

Props to @garrett-eclipse for the peer review of this summary. 🙏🏼

#5-4, #core, #feature-plugins

Auto-updates feature meeting summary: March 17th, 2020

These are the weekly notes for the WP Auto-updates team meeting that happened on Tuesday March 17th, 2020. You can read the full transcript on the core-auto-updates Slack channel.

As a reminder, the Feature PluginFeature Plugin A plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins. is developed on GitHub and is available for testing on WordPress.org plugins repository.

Current status of the project – version 0.3 🦉

Version 0.3.0 was released on Monday 16th. This release addresses a number of issues and introduces Email Notifications.

Changelog:

  • Add functions to handle plugins updates notification emails – PR 54
  • 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’ filterFilter Filters 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 backportbackport A 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 GitHubGitHub GitHub 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.org The 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 UIUI User interface for a given pluginPlugin A 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-updates SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. channel.

#auto-update, #feature-plugins, #feature-projects, #feature-autoupdates

Dev Chat summary – February 12, 2020 (5.4 week 9)

@davidbaumwald facilitated the chat on this agenda.

Full meeting transcript on Slack

This devchat marked week 9 of the 5.4 release cycle.

Announcements

WordPress 5.4 Release Candidate 2 was released on Tuesday March 11th as expected 🎉

Feedback from hosts is needed on Make/Hosting regarding SimpleXML PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher extension usage.

@joemcgill shared that XML Sitemaps Feature Plugin version 0.2.0 was released this week and could continue to use feedback from folks testing.

@audrasjb shared that Plugins & Themes Auto-updates Feature Plugin version 0.2.1 was released this week. This feature now have a dedicated SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. channel, created right after the last devchat: #core-auto-updates. There will be weekly meetings on Tuesdays at 18:00 UTC. The kick-off meeting recap is available on Make/CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress..

@chanthaboune shared the roadmap to get an All-women Release Squad by the end of 2020.

Upcoming releases

WordPress 5.4 Release Candidaterelease candidate One 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). 3 is scheduled for Tuesday March 18th, 2020.

trunk is open for 5.5, but the priority is on 5.4 Release Candidate cycle. Polyglots TeamPolyglots Team Polyglots Team is a group of multilingual translators who work on translating plugins, themes, documentation, and front-facing marketing copy. https://make.wordpress.org/polyglots/teams/. already started to work on translationtranslation The process (or result) of changing text, words, and display formatting to support another language. Also see localization, internationalization. packages.

Components Check-In

@imath worked on Ticketticket Created for both bug reports and feature development on the bug tracker. #49236 and needs some feedback. @jeffpaul advised him to slate it to 5.5 with early keyword so it could be handled at the early stage of the development cycle.

@garrett-eclipse found a list of the components and sub-components without maintainers:

There’s the potential to merge some of the less active sub-components like Charset and Emoji into it’s parent Formatting component. But that would needs further discussion.

Open floor

The main discussion of the open-floor was the BlockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. Editor’s Full Screen Mode enabled by default since WP 5.4 Release Candidate 1.

Here is a quick transcript of the discussion. Please note that no decision has been taken during this chat.

@peterwilsoncc wanted to know when was this committed to the WordPress repository. @jorgefilipecosta answered it was introduced during BetaBeta A 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. 3, before WP 5.4 RCrelease candidate One 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). 1 was released.

@peterwilsoncc: “same for the release in which it was moved from experimental to stable (for want of a better word) GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/?”. @jorgefilipecosta answered that Full screen mode was not experimental, it was stabilized and working for a long time, it was just not enabled by default (although some hosts were doing it), and the Gutenberg team just had a small PR that enabled the mode by default.

@peterwilsoncc noted that in the discussion on the Make/Core blogblog (versus network, site), @matt mentions some user testing. @peterwilsoncc asked how much was done.

@joostdevalk proposed to revert and take another look for 5.5, given the negative feedback about this change.

@clorith pointed out that it is still being worked on, and even had a design change between RC1 and RC2. It feels like it’s not ready, and needs more UXUX User experience work before it goes in.

@chanthaboune asked how the feedback has been in support forums. @ipstenu answered that it’s hard to get feedback in support forums at this stage, since only people beta testing would see it and they tend to be a little more technical savvy than mainstream users.

@youknowriad wanted to clarify some of these questions:
– “I believe we should just the merits of the full screen on its own not whether it can be disabled or not. For instance the customizerCustomizer Tool built into WordPress core that hooks into most modern themes. You can use it to preview and modify many of your site’s appearance settings. is in full screen and it can’t be disabled.
– The UX work after RC1 was a bugbug A 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. fix for RTL languages.
– The feedback is balanced. There were good comments about it. Most negative feedback is about the fact that it becomes default.
– This feature has been on the Gutenberg pluginPlugin A 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 for more than a year now, It’s in before 5.0.”

@pbiron asked if it was enabled by default in the plugin before being merged into core.

@youknowriad answered that was a request from @matt as release leadRelease Lead The community member ultimately responsible for the Release. prior to the RC.

@joostdevalk added that it’s sounds good to say that @matt has every right to make that call. But he disagrees that this is a good idea in its current form, and he think it will be necessary to guide changes like this more. The Block Editor is changing its default behavior without explaining that in the interface.

For @peterwilsoncc, at this point the question is whether it should be enabled by default rather than whether the feature should exist.

@joemcgill’s main concern is that the reaction to this change will be for people to install code that permanently overrides the feature preference, which makes it harder to move to a fullscreen mode default in the future.

@nilovelez noted that it may seem daunting for existing users, as some part of the UIUI User interface will apparently be gone, but existing users are the ones that won’t even notice the change. Some attendees disagreed on that as the current behavior for existing users is saved with LocalStorage so it won’t stay for users that use different devices to connect to WordPress Adminadmin (and super admin).

@clorith also mentioned that Apple clears LocalStorage at set intervals, so users would lose their “don’t use fullscreen” option.

@johnbillion feels concerned that how to switch back to non full screen mode is not obvious.

@youknowriad answered the argument can be turned to the opposite direction for people preferring the full screen mode if it’s disabled. That’s why he think the core team should discuss whether it’s good not whether it can be disabled. For @clorith, given that it’s been off by default, then this is an unexpected change, and thus should not be used as the basis.

@joostdevalk proposed to show how to get out of full screen mode and how to set personal preference in the interface, and save preferences as a user metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. and not on the user’s browser.

@jorgefilipecosta pointed out that a new welcome modal is shown to new users. He asked if it would make sense to introduce full screen mode there. @joyously stated that most of the users wouldn’t see it. @jorgefilipecosta, answered that users that won’t see the new modal won’t switch to default FullScreen mode, their preferences will be kept unchanged.

@audrasjb added that users don’t necessarily come to the editor from the posts list. With fullscreen mode and the WP logo button, they can only go back to the Posts list instead of having the full Admin menu. This is the only Admin action/link directly available after editing/publishing a post.

@jorgefilipecosta raised that the development of database persisting mechanism is in progress and that should happen soon. @ipstenu added it really should be a requirement for this feature to land in WordPress Core. @jorgefilipecosta mentioned database persisting for user’s preferences is expected to land in WP 5.5.

In terms of actions, @peterwilsoncc suggested:

  • Setting full screen to off by default
  • Adding some onboarding for when the switch is made
  • Enable once the user’s preference is saved in the database
  • Clarifying exiting full-screen mode (currently active, stated for completeness)

@johnbillion pointed out Matt mentioned that some hosts enabled full screen mode. He asked what is the feedback been regarding not getting lost, switching modes, etc.

@chanthaboune tried to summarize the concerns raised by the attendees:

  • Consistency/persistency of the visual experience
  • More thoughtful user flows
  • Clearer introduction to the full screen functionality

#5-4, #block-editor, #feature-plugins