Editor chat Summary: 25 March, 2020

This post summarizes the weekly editor chat meeting agenda here. Held on Wednesday, 25th March 2020 held in Slack. Moderated by @get_dave.

WordPress 5.4 Upcoming Release

  • WP 5.4 RC 4 was released yesterday (Wednesday, 24th March)
  • WP 5.4 RC 4 adds the Editor packages (Trac: 49688)
    • The editor PR’s that were cherry-picked into 5.4 can be checked on PR: 21083
    • Remaining issues can be checked and triaged on this board

Monthly Plan & Weekly Priorities

  • Revisit March master plan
  • @youknowriad Progress is good
    • Global Styles: We’ve added CSS vars to multiple blocks and more coming
    • Full Site Editing (FSE): still some challenges (Context API) and we’re improving the Edit Site screen at the same time
    • Patterns: Thanks to @nrqsnchz we have a dozen patterns on the works and the UI is being iterated on
  • Check out some of the Overview issues here for a better outlook

Task Coordination.

  • @nosolosw will work on global styles for edit-siteand reviewing related PRs
  • @youknowriad worked on CSS var support for multiple blocks, Edit Site improvements and PR reviews
  • @isabel_brison worked on Navigation block and Triaging the a11y audit board
  • @Johnston Philip wants to help review things
  • @Jon Q has been working on adding more style controls to Blocks.
  • @karmatosed has been focusing on navigation, global styles and triage
  • @Bart Kalisz has been reviewing some Good first review PRs
  • @get_dave worked with @andraganescu to allow Navigation Blocks to be created from existing WP Menus: PR 18869
  • @michael-arestad works on multi-entity saving and navigation methods within the editor
  • @Brent Swisher will continue working on storybook stories

Open floor

  • @soean asked that we announce WPBlockTalk – a free, online event for all things block editor happening on April 2nd
  • @paaljoachim asked about a progress with the Reusable Block feature. Progress can be monitored here.
  • @paaljoachim also raised awareness on PR 18718 about refactoring cover background controls.
  • @paaljoachim asked if we have a “how to create a PR info area: in the Core Editor handbook. Closest match is here.

Post Meeting discussion

There has been some discussion post meeting between @matveb, Pablo Honey and @mapk about the limitations of designing more complex block patterns.

To sum up the way forward is to provide the best patterns we can which don’t don’t suffer from the lack of tools and when we run into limitations to distill them down to improvements on the blocks themselves.


CSS Chat Agenda: 26th March 2020

This is the agenda for the upcoming CSS meeting scheduled for 26th March, 21:00 UTC.

This meeting will be held in the #core-css channel  in the Making WordPress Slack.

If there’s any topic you’d like to discuss, please leave a comment below!


  • CSS audit status update
  • Open floor

#agenda, #core-css

JavaScript Chat Summary – March 24, 2020

Below is a summary of the discussion from this week’s JavaScript chat (agenda, Slack Transcript)

Have a topic for discussion for the next meeting? Leave a suggested edit on next week’s agenda.

Agenda: Date module dateI18n gmt parameter (added by @davilera)

Slack | Pull Request

This is a pull request that has been around for a while and David has addressed all the feedback given so it’s ready for merge.

Action: @iandunn pinged to verify the latest round of changes and that it tests good.

Agenda: Module naming and deprecations (added by @aduth)

Slack | Github and Comment including links to previous discussions

Topic concerns aligning naming conventions for wp globals on package exports.


  • Merge pull #18722 that documents how to use ServerSideRender from the wp.serverSideRender export. (Done)
  • Create an issue to track the broader effort of “fixing” the names for these globals. (Done)

News Roundup

This roundup contains a few links for Gutenberg and JavaScript related news curated (and commented on) by @nerrad

Other Random Stuff

#javascript, #meeting-notes

XML Sitemaps Meeting: March 24th, 2020

In case you were looking for an blog post about the XML Sitemaps feature project last week, worry no more. Work on the plugin 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 PHP extension is widely available and we can rely on it safely.
    Current status: no action needed.
  • Rewrite rule conflict with plugins
    As we realized that the new /wp-sitemap.xml URL 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 Slack.

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, #xml-sitemaps

Editor Chat Agenda: 25th March 2020

Note taker: @andraganescu.

This is the agenda for the weekly editor chat scheduled for Wednesday, March 25, 2020, 14:00 UTC. This meeting is held in the #core-editor WordPress Slack channel.

If you have anything to share for the Task Coordination section, please leave it as a comment on this post.

If you have anything to propose for the agenda or other specific items related to those listed above, please leave a comment below.

#agenda, #core-editor, #editor-chat

WP Notify weekly meeting suspended, call for proposals for new meeting times or new meeting hosts.

At the present moment, due to various circumstances, the Monday 14:00 UTC time slot for the WP Notify weekly meeting has become problematic for me. This means it is becoming more and more difficult for me to attend, let alone host these meetings.

I am therefore putting these meetings on hold until we can agreed on either a new meeting time, or chose a new meeting host to drive the weekly meetings forward.

I will leave the post open for comment for the rest of the week, or until we can agree on a way forward.



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.


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 candidate 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 blog 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 patch to introduce in trunk (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 Plugin 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 plugin 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 JavaScript and Gutenberg-related items, for those who might be interested or think it helpful to keep in 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

Updating the Coding standards for modern PHP

Until May last year, contributions to WordPress Core were bound to PHP 5.2 syntax and most plugins and themes stuck to the PHP 5.2 minimum requirement as well.

However, with the change to PHP 5.6 as the minimum PHP version for WordPress Core, new PHP features have become available for use in WP Core and with the outlook of a minimum version of PHP 7.x in the (near) future, even more interesting language features will soon become available for use in WordPress Core, plugins and themes.

With that in mind, we’d like to define coding standards for a number of these constructs and propose to implement automated checking for these in the WordPress Coding Standards tooling in the near future.

While it may still be a while before some of these features will actually be adopted for use in WordPress Core, defining the coding standards in advance will allow for a consistent code base when they do get adopted and will allow for plugins and themes, which are not necessarily bound to the PHP 5.6 minimum, to safeguard their code consistency when they start using more modern PHP already.

To be honest, none of these proposals are terribly exciting and some may not even seem worth mentioning. Most follow either prior art in WordPress Core or industry standards for the same, but in the spirit of openness, we’d like to verify our take on these before implementing them.

Continue reading

#modernizewp, #codingstandards, #php, #wpcs

CSS Chat Summary: 19th March 2020

Full meeting transcript on Slack: https://wordpress.slack.com/archives/CQ7V4966Q/p1584651672176800

I (@isabel_brison) facilitated the meeting. 

CSS audit updates

  • I tested some automated tools we might use for the audit and updated 49638 with my findings;
  • @notlaura attended the design meeting and asked what designers would find useful with this audit (summary here).


  • Create a doc for the audit outline.
  • Ask the accessibility folks what they would find useful as an audit outcome.

We also discussed and agreed on reviewing, as part of the audit, where we are using px units and others that might have a detrimental effect on responsive behaviour. 

Coding standards

I asked about the history of stylelint-config-wordpress, which is used in Gutenberg but predates it by a few years. 

@netweb later replied with some informative context that I will add here:

  • The Stylelint config was created with Core in mind, based on existing styles and in alignment with PHP and JS standards.
  • It was then updated when added to Gutenberg, especially the Sass-specific rules.
  • It wasn’t added to Core because it was picking up lots of errors that would need to be fixed, so needed a committer to own the work.

The discussion then shifted to use of Grunt and Sass in Core. Sass is mainly used for theming in wp-admin, and the design team are looking at replacing its use with CSS custom properties. 

(@netweb later added that because Sass is widely used in Gutenberg this may be up for discussion, but likely Core will be dropping Grunt and moving to native npm scripts and @wordpress/scripts.)

This led to a discussion on IE support and graceful degradation. I suggested defining a set of rules for what is essential functionality that we need to support in IE, so we can be more confident in using shiny new tech for non-essential functionality. @michael-arestad suggested creating a ticket for that.

@michael-arestad expects that the biggest challenge post-audit will be implementing a predetermined selector format in a way that doesn’t break plugins with custom admin sections that depend on wp-admin styles. 

#core-css, #summary

Associating GitHub accounts with WordPress.org profiles

In an effort to make tracking all contributions to the WordPress project across multiple locations easier, a new option is available when editing your WordPress.org profile that allows you to connect your GitHub account.

WordPress.org profile with GitHub profile link highlighted.

In recent releases, the process of collecting props for non-WordPress.org contributions (namely Gutenberg) has been highly manual and error prone, occasionally resulting in contributors not receiving proper credit. Connecting your WordPress.org and GitHub accounts will allow automatic tooling to be built which reduces the burden on release teams to maintain a credit list.

How it works

The feature uses an oAuth flow to grant a WordPress GitHub application read-only access to your GitHub account’s public information. This proves that you own both the GitHub account and the WordPress.org account and links the two accounts.

This has been available and tested for several months now, and many contributors have connected their accounts. But, because it was never officially announced, adoption has been low.

If you have not already, please take a moment to connect your GitHub account to your WordPress.org account by going to https://profiles.wordpress.org/me/profile/edit/.

Below are some screenshots of how the process works.

1. Edit WordPress.org profile

WordPress.org profile edit screen with the GitHub Username section highlighted.
Click “link your GitHub account” to initiate the process.

2. Authorize WordPress.org Profiles application

The authorization screen on GitHub for the WordPress.org Profiles application.
Grant the WordPress Profiles GitHub application read-only access to your public information.

3. Verify connection

WordPress.org profile edit screen showing a linked GitHub profile.
Access can be revoked at any time on the Edit Profile screen on WordPress.org.

Huge props go out to @dd32 for implementing this feature. For more information on this feature and the ongoing effort to make collecting props easier, see Meta-#4447.