Bug Scrub Schedule for 5.3

Now that 5.3 has been officially kicked off, bug scrubs will happen weekly all the way up to the final release. Keep an eye on this schedule – it will change often to reflect the latest information.

  1. 8/27/2019 18:00 UTC
  2. 9/5/2019 14:00 UTC
  3. 9/12/2019 05:00 UTC (APAC-Friendly)
  4. 9/18/2019 23:00 UTC
  5. 9/25/2019 17:00 UTC
  6. 10/2/2019 16:00 UTC
  7. 10/9/2019 17:00 UTC Led by @marybaum
  8. 10/17/2019 17:00 UTC
  9. 10/23/2019 TBD (If Needed)
  10. 10/30/2019 TBD (If Needed)

These scrubs are separate and in addition to the normal scrubbing and triage by individual components. Some of those sessions include:

Design Triage: Every Monday 16:30 UTC at #design
Gutenberg Design Triage: Every Tuesday 16:00 UTC at #design
Accessibility Scrub: Every Friday 14:00 UTC at #accessibility

Also, @pento recently announced a new, ongoing APAC-friendly #core bug scrub session every Thursday at 06:00 UTC.

As the release date nears, one-off, “flash” scrubs pop up for individual components. These are typically focused on a specific group of tickets or an individual feature. Some of these sessions include:

Twenty Twenty Theme Scrub: 9/20/2019 16:00 UTC at #core-themes
Media Accessibility Scrub: 9/23/2019 06:00 UTC at #core-media (APAC-Friendly)
Media Accessibility Scrub: 9/25/2019 14:00 UTC at #core-media
Accessibility Scrub: 10/1/2019 16:00 UTC at #accessibility

Finally, a reminder that anyone — Yes, you! — can host a bug scrub at anytime. You can work through any tickets you’re comfortable with. In fact, if you plan one that’s 5.3-focused, we’ll add it to the schedule here along with your name. Finally, you’ll get well deserved props in the weekly Dev Chat, as well as in the #props Slack channel!

All open tickets for 5.3, in order of priority, can be found here. Tickets that haven’t seen any love in a while are in particular need. Those can be found in this query.

If you’d like to lead a bug scrub or have any questions or concerns about the schedule, please leave a comment or reach out to me directly.

#5-3, #bug-scrub

Core editor chat summary October 30th, 2019

This post summarizes the weekly editor chat meeting agenda here. Held on Wednesday, 30th October 2019 held in Slack, moderated by @mcsf, notetaker: @pbarthmaier.

Weekly Priorities

Gutenberg 6.8 and WordPress 5.3RC3

Gutenberg 6.8 had its RC on Monday and is ready to be released. @ella has offered to wrangle the release and release post! (edited)  

The third release candidate for WordPress 5.3 is now available! WordPress 5.3 is currently scheduled to be released on November 12 2019, but we need your help to get there—if you haven’t yet tried 5.3, now is the time!

A few things that might be good to fix in time for a potential WP 5.3 RC4:

I’d appreciate some eyes on these! I believe @jorgefilipecosta had something prepared for the latter.

November Gutenberg Priorities

Priorities for the coming month are categorized into these three headings: 

  • Block Content Areas,
  • Menu Navigation Block, and 
  • Tightening up existing interactions

For more details, consult this recent post.

Task Coordination

Note: Anyone reading this summary outside of the meeting, please drop a comment in the post summary, if you can/want to help with something.

@getdave

Related to Nav Menus – a new experimental Link UI to standardise the interface for adding links has been merged.

Also merged experimental `DimensionControl` to provide a standardized user interface for controlling Block dimensions.

This is closely linked to the ongoing PR for `ResponsiveBlockControl` which enables per device/viewport settings for a given control https://github.com/WordPress/gutenberg/pull/16790. These are both related to the wider goal of enabling padding/margin adjustment on the Group Block via the editor. Looking for input and feedback on the later PR.

@joen addresses a frustration with the complex left and right margins and paddings that every block gets in this PR: this should make things easier for block developers and themers, ie styling the editor and building delightful blocks without complex CSS. The downside is, it’s a complicated refactor, and it will create issues in some existing editor styles, like TwentyNineteen. But I would argue it’s worth it, and a perfect candidate for kicking off the 5.4 cycle once 5.3 lands.

@mcsf  I’ve been targeting a good deal of my reviewing to the monthly priorities. Folks have worked a lot on improving the block appender and other pieces crucial for the Menu Navigation block, kudos to them

@andraganescu I am working on adding a link to the media and text block, fixing the selection when switching inspector tabs and reviewing/testing everything open for the navigation menu block

@gziolo I’m slowly learning about Patterns API for block and I plan to start development later this week. I also spent a lot time reviewing new stories for the Storybook and further polishing the integration with snapshot testing

@jorgefilipecosta Since the last week, we iterated and merged many of the gradient related PR’s. We now use the class mechanism on the button gradients. I helped the new experimental colors hook to land, and I have been involved in refactoring some blocks to be functional components so we can use hooks there. For the next week, I will focus on some enhancements to inner blocks that allow removing parts of the standard block UI. And try to apply these features in the buttons block.

@brentswisher Following up on old/stalled PRs – If I could get some new eyes on https://github.com/WordPress/gutenberg/pull/11070 specifically it would be great to wrap up, it’s been going about a year…Continuing to work on Storybook and file some related 

@gziolo and @getdave give props  to @itsjonq @mkaz @brentswisher and @enej for working on adding stories to Storybook too which makes testing a pleasure and helps us uncover all incompatibilities that folks can have when integrating components into their own project.

@retrofox Working now integrating https://github.com/WordPress/gutenberg/pull/18062 and https://github.com/WordPress/gutenberg/pull/18172 – apply colors correctly in editor mode

@jorgefilipecosta For the next week, I will focus on some enhancements to inner blocks that allow removing parts of the standard block UI. And try to apply these features in the buttons block. and improvements to the standard block UI can ultimately also improve the experience with Nav Menus

@mkaz Over the next week I hope to work with Joen to iterate on SVG loading. Hopefully one step for unsticking the Social Links.

@mcsf Relaying async updates from our APAC friends:

  • @tellthemachines: “I’ve been working on and reviewing nav menu issues. Current PR for showing appender only when item has submenu
  • @noisysocks: I’m focused on reviews this week: particularly Nav block PRs and this Widgets PR.

Open Floor

@marek asked if the screenshot on the Editor Component page needs updating https://make.wordpress.org/core/components/editor/ @mcsf proposed anyone with a more current screenshot to add it to a future Agenda post in the comments and anyone on the team with write-access to the component page can edit it

Specific Area Blocks

@aristath asked if the plan is to have blocks specific for these areas (like for example a branding block for the header block-area)? If so then these blocks will only be usable is the block areas for which we register them and won’t be available in the content? 

@jorgefilipecosta replied this could fit into the concept of child block where a block specifies it only makes sense inside a specific parent. It may be possible to use the current API’s and specify a branding block needs to be child of a header block, but that you may need to also use a branding block in the footer.

@mcsf I suggests this may work with block categories so that certain categories (“Page Layout Elements”?) aren’t meant to show up in post content.

@aristath from the theme team asks if there is code for review so the team can begin thinking about what needs to be done for themes (how they can override templates for registered blocks, what/how can be registered etc)

@poena I am seeing a lot of different screenshots in various github issues but is there actual example code for us to test?

@mcsf Are you asking more about block insertion and management UI, or about the front-end / template rendering aspects? There’s a few issues on different aspects

@aristath I’m asking about the template-rendering aspects, how they can be overridden (not all themes have the same branding components), if themes can register blocks for block-area A/B, if there’s anything we can start looking at. The UI doesn’t really matter, what we need at this point is to get an idea of what a theme can/should do code-wise to implement a feature. Even if it’s just a rough draft or an idea of where we’re headed .

@mcsf I think this a good starting point. A lot of issues and PRs, some of which merged, point to it, so be sure to scroll down to find some of the merged work around wp_template too. From the standpoint of overall user experience, this issue is a good aggregator.

@vindl Currently we already have a concept of child block. Where a block specifies it only makes sense inside a specific parent.  FSE-related (Full Site Editing) – would it make sense to extend this beyond blocks and make it possible to declare parent post type limitations (e.g. template-part block can only be inserted in wp_template CPT or similar)

@marek It might be interesting to see those Site blocks being styled based on the area they are in. In the header, Site Title would be big and prominent while in the footer it might be more subtle by default. Not sure how much this was explored so far.

@williampatton It might be interesting to see those Site blocks being styled based on the area they are in. In the header, Site Title would be big and prominent while in the footer it might be more subtle by default. Is the idea that the editor would be responsible for styling this?

@mcsf I personally see this is going beyond styling. Rather, we should have an editor (and blocks!) smart enough about block semantics that they a block can mean (and behave?) differently depending on where it’s inserted.

@marek I would think the editor provides classnames for areas and blocks and themes will handle those.

@williampatton I would prefer this aspect to be agnostic of the editor it. Ideally the editor doesn’t know/care where the items were and the frontend could handle all styling.

@poena This gives us an overview, how do we practically (and realistically) help move this forward?

@mcsf This gives us an overview, how do we practically (and realistically) help move this forward? Maybe some of those most involved in recent full-site editing efforts can weigh in? If not, this can be something to follow up via P2 comments — would that be acceptable, @poena?  I’d say that the November post would also be a strategic place to follow along and align.

@poena  I don’t know how you normally introduce new contributors

@mcsf that’s a great question. And, by the way, welcome and thanks for wanting to help! My personal impression is that full-site editing has been moving through different pieces that can be explored separately, which is good for velocity and collaboration, but also makes it much harder to jump in and get an immediate lay of the land. There doesn’t seem to be a single branch we can check out and start working on. it’s bits and pieces scattered all over the place. I’m sorry there was no super conclusive answer, @poena and @aristath but hopefully this is a starting point.

Thanks everyone for joining and for all the work!

JavaScript chat summary, October 29nd, 2019

Below is a summary of the discussion from last week’s JavaScript chat (agendaSlack Transcript)

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

React prerelease channels

Slack Conversation

There was an announcement from the React team about official prerelease channels:

The long story short is they are promoting react@next prereleases and share some guidelines on how to test projects with the upcoming changes to their libraries. If you want to get involved and explore how the Gutenberg project could participate please comment on the corresponding issue.

Time of the meeting

Slack Conversation

Weekly meetings discuss JavaScript in the context of the WordPress ecosystem and we value the input from people working with JavaScript in WordPress. We wanted to survey people whether they would like to participate in the weekly chat if there was a different time?

As of today, we expect you’ll come to the meeting prepared to contribute your perspectives and help influence direction. You can also share in comments what would you expect from such meetings.

Testing components

Slack Conversation

There is an ongoing discussion about different approaches to testing UI components on GitHub. It isn’t a new topic. We have already considered removing enzyme in the past when some React APIs weren’t covered, but we gave up because of its wide usage.

We agreed that we can live with enzyme in old files following Code Refactoring guidelines, but we should plan to make it easier to contribute with tests when working on new features. @nerrad emphasized that it would be good to iron out what testing approach we want to recommend going forward. If anything the discussion in that issue highlights, we should include it in the Testing Overview documentation as the very first step.

@gziolo proposed we consider the E2E testing approach with the instance of Storybook as the testing environment given that it is a static site working like a single page application. @itsjonq shared that he’s done storybook E2E testing using Cypress in the past. It was something that could be automated by CI (Travis) and it worked great.

#core-js, #corejs, #javascript, #js, #meeting-notes

Dev Chat Summary: October 30th 2019

This post summarizes the weekly dev chat meeting from October 30th 2019 (agenda / Slack Archive).

Announcements

WordPress version 5.3 Release Candidate 3 was released on Tuesday. Everyone please help by testing out the RC.

Core editor team released Gutenberg version 6.8.

Dev chat meeting time

Like every year, with end of DST (daylight saving time), the meeting time should be moved from 20:00 UTC to 21:00 UTC.

Two options are proposed:

  • Moving on Wednesday November 13th (the day after WP 5.3 is going to be released)
  • Moving on Wednesday November 20th (one week later)

Please share your thoughts in this post’s comments.

WordCamp US Contributor Day

WordCamp US’s contributor day is planned for Sunday 3rd November.

5.3 was branched last week, so contributors will be able to work on WordPress 5.4 milestone since trunk is now version 5.4-alpha.

@earnjam and @wpscholar will be leading the core table, Helping people get set up, learn how to get started, find places to focus on work, etc. They also should have several component leads present that can split off and focus on their areas for people who are interested.

Upcoming Releases

WordPress 5.3 Release Candidate 4 is scheduled next Tuesday if needed.

There is still 7 tickets open in the milestone.

@azaozz regrets that things weren’t reported much earlier, during beta. By the way, two tickets have patches already, one is almost there, and one may be a candidate for 5.3.1. As 5.3 was branched, all fixes are probably going to be committed to trunk (5.4-alpha) but hold on on merging to 5.3 for couple of days to allow easier testing and review. All are (possible) regressions with the way some plugins use particular hooks around image post-processing and image meta updates.

@joyously reported a feedback found in Alpha/Beta support forum. It was already merged to Gutenberg and looks fixed in 5.3 block editor code. @youknowriad was pinged as Editor focus lead for WP 5.3.

Open floor

@joyously asked about backporting security fixes to old versions request’s status.

@clorith and @audrasjb noted there will be a panel session at WordCamp US. For those who are not attending WordCamp US, questions can be sent via Twitter.

@desrosj added that there was a very large amount of feedback. @chanthaboune and others are working to compile all that feedback so that all of it can receive proper consideration.

#5-3, #contributor-day, #wcus

What’s new in Gutenberg? (30 October)

Work on block content areas and the navigation menu block is accelerating in this release.

In the meantime, this release continues the work on Gradients support and expand it to the Cover block while relying on classnames instead of inline styles

Screenshot 2019-10-17 at 14 59 27

Block Nested selection and interactions is still being improved with a new Block Breadcrumb Bar allowing to quickly navigate the block hierarchy of . the current selection.

Capture d’écran 2019-10-16 à 11 34 50 AM

6.8

Features

Enhancements

Bugs

Experiments

New APIs

Various

Add knobs to the ColorIndicator Story.

Documentation

Performance Benchmark

The following benchmark compares performance for a particularly sizeable post (~ 36000 words, ~ 1000 blocks) over the last releases. Such a large post isn’t representative of the average editing experience but is adequate for spotting variations in performance.

Version Loading Time KeyPress event (typing)
Gutenberg 6.8.0 5.68s 47.28ms
Gutenberg 6.7.0 5.83s 47.92ms
WordPress 5.2 6.1s 63.22ms

👏 Kudos to all the contributors. Thank you.

#core-editor, #editor, #gutenberg

Dev Chat Agenda for October 30, 2019 (5.3 week 11)

Here is the agenda for the weekly meeting happening later today: Wednesday 30 October 2019 at 20:00 UTC. Please share any items you’d like to include in the comments below!

  • Announcements
    • Highlighted posts
    • Move Dev chat meeting time (end of daylight saving time)
  • WCUS/contributor day
  • Upcoming Release Discussions
  • Calls from component maintainers
  • Open Floor

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

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

#5-3, #agenda, #devchat

Editor Chat Agenda: October 30th

Note taker: @pbrocks

This is the agenda for the weekly editor chat scheduled for Wednesday, 30th October 2019, 13:00 UTC.

This meeting is held in the #core-editor channel in the Making WordPress Slack.

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

As always, 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

What’s next in Gutenberg? (November)

This is a monthly update containing the high-level items, Gutenberg contributors are and should focus on for the next month.

Block Content Areas

In previous Gutenberg releases, a new wp_template Custom Post Type has been created to store block content areas and enable using Gutenberg outside the post content. In the next weeks, contributors will be working on expanding on this work:

  • Render the frontend template loader to support wp_templates 17626.
  • Add a temporary UI to edit these templates 17625.
  • Experiment with blocks targeting site options (title) 17207.
  • Work on a UI to save multiple entities (post, site, template…) from the same interface. 18029.
  • Nested template areas.

Menu Navigation Block

The Menu Navigation is also one of an important focus for this month. You . can follow all the related work on this project and the overview issue.

Tightening up

Existing interactions and blocks will be iterated on:

  • Gradients support across blocks 18001.
  • Theme API for gradients. 17841, 18008, 18028.
  • Improvements to the Media Flows. 16200.
  • Improve nested block navigation through a block hierarchy breadcrumb and explore selection tools. 17838 17088.

#core-editor

JavaScript chat summary, October 22nd, 2019

Below is a summary of the discussion from last week’s JavaScript chat (agendaSlack Transcript)

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

Agenda: Node LTS

Slack Conversation

Recently, Node 12 became the new LTS version for Node. A pull request to make WordPress scripts compatible with Node 12 was merged.

Agenda: Code style

Slack Conversation

A change to the JSDoc plugin triggered new ESLint warnings. These were fixed in a pull request: https://github.com/WordPress/gutenberg/pull/18025.

Another PR tries to bring WP Prettier into WP Scripts. WP Prettier is a Prettier fork that follows the WordPress code conventions that allows to easily reformat all of WordPress JavaScript but also enable other developers in the community who leverage WP scripts to do the same.

Agenda: Storybook

Slack Conversation

In September, Storybook was added to Gutenberg. There’s an issue open discussing next steps, which includes adding stories for all @wordpress/components and adding support for React Native components. @mkaz published a tutorial video on his blog on how to code a storybook story.

The following questions could be explored:

  • How can we enable plugin and theme developers to leverage storybook in their own workflows? It was suggested storybook could be added to WP scripts.
  • How can we integrate storybook into https://developer.wordpress.org/block-editor/? Storybook could be a replacement for the components reference.

A few concerns were raised with regard to using storybook on wordpress.org:

– How do we keep the WP dev site header?
– How do we avoid iframes (and include the header) to keep routing?
– How do we keep the READMEs (or some aspects of them) as there’s a lot of good info there?

It seems storybook allows for enough customization to be able to address these concerns. Some help from the meta team would be required.

Open floor: Card component

Slack Conversation

@itsjonq worked on a PR for a new Card component. There’s still some ongoing discussion about the introduction of css-in-js and Enzyme in that PR. Feedback appreciated!

#core-js, #corejs, #javascript, #js, #meeting-notes

WP Notify meeting for 28 October 2019 cancelled.

With WCUS just around the corner, the WP Notify meeting for 28 October 2019 is canceled.

If anyone wants to chat about WP Notify, @hrmervin will be available to connect with folks at the WCUS Contributor Day.

#feature-notifications

WP Notify – Meeting Recap – Oct 21, 2019

This is a recap of a meeting held October 21 for a Core project related to WordPress Admin Notifications. Meetings on this task are held every Monday at 14:00 UTC and 22:00 UTC respectively.

Related Links

Google Doc: WP Notify Project Requirements Document

Notes Per Agenda

Open Floor for Feedback

Our discussion this meeting further refined the focus of this project, to be a solution “… plugin and theme developers can leverage, again instead of using admin_notices.”

Present handling of admin_notices will require distinction between immediate (core) based notifications such as successful saves, and a queue of notifications to be followed up on at a later time.

This project seeks to pave the way so future projects can build upon the new notifications handling. Enhancement such as mail or push notifications handling, will be able to leverage the processing we create here.

Next Steps

We welcome feedback on the project either here in this post, or in the requirements (via Google Doc, comments). 

We invite you to attend our next meeting, held in Slack > #feature-notifications

  • Monday, October 28 2019 at 14:00 UTC 
  • Monday, October 28 2019 at 22:00 UTC

#summary