Editor Chat Summary

This post summarizes the weekly editor chat meeting on August 21, 2019 at 1300 UTC held in the core-editor Slack channel.

The agenda can be found here.

Note: If you’re reading this summary async, please drop a comment if you can/want to help with something!

Priorities for the week

Slack transcript.


Being worked on / Needs more work:

Task Coordination

Slack transcript.

@youknowriad Refresh to reusable blocks that closes multiple issues, triagged issues and reviewed PRs.

@karmatosed Triagged, mainly issues/PRs that need design feedback.

@kjellr Improvements to the inserter help panel (1, 2), changes to NUX tips, and tidying up animations (1, 2).

@jorgefilipecosta Explored mobile viewport in the editor (1, 2). To work on text color formatting, gradient backgrounds, cover block resizing.

@mapk Looking into improving the sibling block inserter, helping on widgets work and @retrofox on a UI solution for screen height PR.

Components package reorganization and bundle sizes

Agenda | Slack Transcript | Issue

The issue created by @nerrad sparked a conversation on how to control bundle size and offer options to bundle “what you need”:

  • The `wp_enqueue_script` model encourages people to use the whole bundle for a package, not the specific pieces you want.
  • There are concerns over creating too many packages that make discoverability difficult.
  • Overrall, this ties into how to make WordPress play nicely with dynamically loading dependencies as you need them (the SPA model).

To be discussed more in the issue and/or in future core-js chats.

e2e test and block deprecations

Agenda | Slack Transcript | Issue

  • @isabel_brison raised the issue that e2e tests fail due to block deprecations triggering a `console.warning`.
  • The restriction have been very valuable when it came to deprecate APIs, as to make sure core wasn no longer using them. It is not that useful in other contexts.
  • There is a draft PR to address the deprecation issue.

#core-editor, #editor-chat, #summary

Editor Chat Agenda: August 14th

Note taker: @andraganescu

This is the agenda for the weekly editor chat scheduled for August 14, 2019 at 1300 UTC.

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

  • Gutenberg 6.3
  • Tasks Coordination
  • Open Floor

If you have anything to share for the Tasks 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

Editor Chat Agenda: August 7th

Note taker: @mikeschroder

This is the agenda for the weekly editor chat scheduled for August 7, 2019 at 1300 UTC.

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

  • Tasks Coordination
  • Open Floor

Last week it was suggested to post items for Tasks Coordination as comments on posts so that it’s easier to follow for folks that can’t attend the regular meeting.

So, let’s give it a try! If you have anything to share for the Tasks 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

Editor chat summary: Wednesday, 24 July 2019

This post summarizes the weekly editor chat meeting on Wednesday, 24 July 2019, 14:00 WEST held in Slack.

The agenda followed can be found here.

The meeting started with @youknowriad noting that we postponed this week’s Gutenberg release 6.2 to the next week due to a lot of AFKs and not enough shipped features/enhancements for a proper release. Next week we will resume the regular release schedule.

Task coordination

Note: If you’re reading this summary outside of the meeting, please drop a comment if you can/want to help with something!


  • Working on the settings page. It’s not finished yet, but @tellthemachines created a PR up to get feedback: https://github.com/WordPress/gutenberg/pull/16626
  • Started working on a caption for the gallery block: https://github.com/WordPress/gutenberg/issues/9342
  • Looking at http://gutenberg.run/ and other possibilities such as https://tugboat.qa/ for setting up preview environments for our PRs.


  • Worked mainly on “A11y Navigation mode” and “Live Drag and Drop experimentation”.
  • Reviewed: new PHP API to register style variations and some small reviews here and there (Gutenberg experiments settings page, Text alignments in the block heading, Improved preview component…).
  • Started thinking about Full Site Editing and what does it mean for Gutenberg to support editing the full site/page even outside post content.


  • Working on widget screens
  • Exploring some Block Template flows
  • Reviewing PRs


  • Plans to finish the work related to block style variations, some PR’s will need an update to avoid PHP anonymous functions.
  • Will submit some fix for issues opened affecting the blocks widget screen.


  • Plans on reviewing anything design stuck in the backlog.
  • Has been dipping into the ‘needs testing’ label a bit to keep that moving along.


  • Is working on ideas for “updating the publishing flow”. A PR https://github.com/WordPress/gutenberg/pull/16715/ is available, and feedback is welcome.


  • This week: Worked on improvements to the Gutenberg Starter Theme.
  • Next week: Will focus on the Patterns API + Tips.


  • Worked on a PR to add basic spacing/dimensions controls to the Group Block. https://github.com/WordPress/gutenberg/pull/16730
  • Improved BlockPreview component:
    • Autosizing / scaling previews – https://github.com/WordPress/gutenberg/pull/16113/
    • Updating the API of the component to accept multiple blocks as arguments – https://github.com/WordPress/gutenberg/pull/16033

Growing list of open PR’s

@youknowriad made a remark saying:

The list of open PRs is growing. That’s great, I’d like to thank you all for your contributions. This also means we’re having some trouble to keep-up with reviews… I’d like to ask everyone creating PRs / working on Gutenberg to help as much as needed with PR reviews (it doesn’t matter if you think you have the required knowledge or not, all reviews are helpful and help move things forward).
So please review PRs as much as you can and again thanks all for your work/help. If you’re hesitant for any reason, my DMs are open, happy to address your uncertainty.

@karmatosed flipped the question and asked if there are any hurdles to people reviewing.

@brentswisher pointed out that his hesitation (maybe shared with other contributors) is a fear of uncertainty about what would happen after something is reviewed and made the following questions:

  • Does it just get merged?
  • Does someone with more experience look at it again before merging?
  • Am I supposed to merge it?

@karmatosed  and @youknowriad answered that since @brentswisher is a member of the Github Gutenberg team, he can merge a PR after the review or review it anyway but not merge it right away and ask for a second opinion.
Both also mentioned that maybe there is space to iterate the docs and make that more clear.

Open Floor

@paaljoachim is wondering if other have some comments on PR https://github.com/WordPress/gutenberg/pull/16557 (Try: Always collapse block alignments), for @paaljoachim the PR seems a no brainer by placing alignment into a dropdown.

@karmatosed said that she would say “yes” to the PR if discoverable, but her concern is hiding usefulness.
@mapk said he liked it, adding that we have other items that work this way already.
@paaljoachim asked for comments on the previously referred PR and PR https://github.com/WordPress/gutenberg/pull/16682 (“added alignment to the toolbar for consistency”).
@karmatosed said we could add the comments and thanked @paaljoachim for championing these PRs.

@desaiuditd asked for comments on PR https://github.com/WordPress/gutenberg/pull/16244 (“Allow changing Block attributes dynamically in InnerBlocks template”.).
@jorgefilipecosta said:

The idea of the template is to provide a set of blocks that prefill a given InnerBlocks when it is empty.
If I pass a template when a block contains a given set of attributes, and later I pass a template where blocks contain different attributes, nothing should happen because the block is not empty anymore and there is no need to prefill it.

The discussion continued on the reason why sometimes the template updates the blocks. @jorgefilipecosta explained that it only happens when templateLock=all and only for cases where blocks changed positions or were removed/added because for this locking we know the user would not have made these actions.

@chrisvanpatten and @mcsf both pointed to a PR that may bring more control to templateLock https://github.com/WordPress/gutenberg/pull/16678 (Template Locking: read-only / disable editing attributes)

@jorgefilipecosta concluded that for now if there is a need to update the attributes of a child, from the parent, the best solution is the usage of updateBlockAttributes action in the parent, and not use the template mechanism.

#core-editor, #editor-chat, #summary

Editor chat summary: Wednesday, 3 July 2019

This post summarizes the weekly editor chat meeting on Wednesday, 3 July 2019, 14:00 WEST held in Slack.

The agenda followed can be found here.

Task coordination

Note: If you’re reading this summary outside of the meeting, please drop a comment if you can/want to help with something!


Implemented the first pass at a potential solution for the element interpolation i18n problem https://github.com/WordPress/gutenberg/pull/16374.


  • Worked on some performance related PRs. Mostly tried to make the getBlock selector more performant as it’s the bottleneck in terms of typing performance.
  • Reviewed a bunch of PRs. One of the most important is the Customizer Panel to edit block-based widget areas PR by @epiqueras.
  • Plans to land the block reordering animation soon.


Made a few small pull requests, reviews, focusing mostly on “custom” sources for blocks (reimplementing meta to start)
Referred that the issue with the publish button https://github.com/WordPress/gutenberg/pull/16303 has a significant impact and might be easy to review if someone wants to take a look.


Continues working on table block tasks. Has a couple of PRs ready for review:

Has a PR which changes the way the blocks.registerBlockType filter works. Would be happy for more testing on it: https://github.com/WordPress/gutenberg/pull/16348


Worked on some PRs related to SlotFill with https://github.com/WordPress/gutenberg/pull/13361 being the highest priority, followed by https://github.com/WordPress/gutenberg/pull/16384, in his opinion.


Has been posting some work on revised, less-intrusive tips:

He is hoping to get PR https://github.com/WordPress/gutenberg/pull/14961 merged, once we can figure out the mysteriously-failing test.

Did some initial work on the Patterns API, and hopes to get that posted until the end of the day: https://github.com/WordPress/gutenberg/issues/16283


Has been working to allow any Block to be registered to handle “Grouping” interactions. Received non-consensual feedback some people think that it is a good idea while others think the opposite.
Additional feedback is welcome:

Has been working on Block Previews component along with @joen to allow it to dynamically resize and handle scale a lot better: https://github.com/WordPress/gutenberg/pull/16113.


Continues the work on Snap to grid RFC.


Answered & debugged some issues and submitted bug fix PR’s. Reviewed some PR’s, including the blocks in the customizer and the custom parser options. Proposed a simple mechanism for themes to register styles and did updates to the image Link UI refactor PR, which was recently merged.


Has been doing some light PR reviews and issue replies… Is aiming to schedule a Gutendocs bug scrub session next week; if anyone has specific days/times that work and you want to join, feel free to comment! @chrisvanpatten would love to get good attendance.

Agenda: Non-code contributions

@youknowriad introduced the topic by referring that the idea is that we value code contributions (or PRs more precisely) more than other types of contributions: PR reviews, triage, discussions in issues… The consequence is a growing list of unreviewed PRs and untriaged issues.

@epiqueras proposed some ideas to explore:

  • draft documentation for what is good triage and reviewing, why it’s important, and where new contributors should start.
  • highlight some good live PRs to review for people to take a look at.
  • recognize these types of contributions so that their value is more obvious.

@karmatosed referred that design / technical feedback should be added to the previous list.

@youknowriad a small first step today was that he tried focusing more on “non-code” contributions during the Task Coordination and tried to highlight this work more.

@karmatosed noted that we could expand beyond ‘did you review PRs’ to say ‘did you leave feedback or offer insights’.

@nadir shared that:

being a new contributor, based on my experience in trying to review PR I would say it was really hard for me because sometimes you really need to understand the codebase, things that are agreed upon, the norms and what’s not.

the only PR that I could review are related to things I already solved issues on or had PR related to, but I felt that I wasted a lot of the core team time reviewing basic problems like how to document eslint disable rules and how to write code that matches the core team theme

@karmatosed made an essential point that every single moment investing in someone as awesome to try and contribute isn’t a waste

@mcsf thanked the share made by @nadir and said:

I think that’s a very real issue for anyone coming to the project. I have a suggestion for easing into reviewing other people’s work: recognise that you can still provide helpful feedback even when you’re not an “expert”. This, to me, means that you could define the scope of your review, or your abilities: “I can only speak about this component”, or “about the overall readability”,
Concluding by saying that a newcomer’s eye can reveal a lot of blind spots in PR’s.

@aduth also thanked the share made by @nadir referring that he is inclined to say that we need more documentation for the things @nadir referred. Followed with a set of questions: Is this documentation as it’s organized today very effective? Do you have any thoughts on what might be an effective way for you to become aware of norms and such?

@karmatosed continued the conversation by stating that: Docs are just docs. It’s surfacing and being in the right place counts.

@nadir added that triaging was also an excellent way for him to contribute since he worked on two components when he started (button & snack bar), filtering issues & PR by those components gave him a good ability to review and understand what is happening

@brentswisher joined the conversation and supported the idea of “draft documentation for what is good triage and reviewing”.

@youknowriad proposed a welcome bot that comments PR’s of new contributors. The discussion went on with people sharing insights regarding that idea and how a concrete bot implementation could like.

@karmatosed shared the following actions points as a discussion summary:

  • Recognize and highlight non-code contributions more during weekly meetings
  • Surface the docs better (how?).
  • Improve the docs. (can we create an issue to discuss what needs to be improved and how)
  • Add thoughts to welcome bot and project board: https://github.com/WordPress/gutenberg/projects/24#card-17518302
  • Consider what role of welcome contributor could be.

And ended with a reminder: “We are all human.”

Open Floor

The open floor started with a question by @joyously: How the editor can better support themes? She added:

The old editor has an easy interface to add “Formats” with a simple PHP filter that makes a button in the editor. When can we have that again? Why change the interface to the theme? (new API)

@youknowriad answered by saying:

I think there’s a difference in the paradigm that makes applying “random classNames” to “random HTML” not a good fit for the block editor. While in TinyMCE we’re adding content as HTML, in the block editor we’re adding content as blocks which means any markup we add should be meaningful for the block.

So the idea is that we have two use-cases here:
– Apply a style variation to the block (known block) (className + stylesheet)
– Apply an inline style variation (inline class name) in RichText. We don’t have an API for that one because it’s less common, but I think you should feel free to open an issue about this “Custom Format” (talking about the RichText Format API ).

#core-editor, #editor-chat, #summary

Editor Chat Agenda: June 5th

Note taker: @ajitbohra

This is the agenda for the weekly editor chat meeting on Wednesday, 5 June 2019, 13:00 UTC.

  • Tasks Coordination
  • Open Floor

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

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

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

Editor Chat Summary: May 29th

AgendaSlack Transcript


Gutenberg 5.8 was released today, congratulations to everyone who participated in this release!

The release agenda for WP 5.2.2 is out https://make.wordpress.org/core/2019/05/28/5-2-2-release-agenda/.

Regarding the WP 5.2.2 release, from the editor side, we have two PRs to be backported. https://github.com/WordPress/gutenberg/pulls?utf8=%E2%9C%93&q=is%3Apr+label%3A%22Backport+to+WP+Core%22+is%3Aclosed+milestone%3A%225.8+%28Gutenberg%29%22+.

@youknowriad volunteered to backport the PR’s.

Task Coordination

  • @aduth
  • @youknowriad wants to work on
    • Exploring grid helpers when resizing images.
    • Exploring more animations (snackbars, moving blocks…).
    • document the release tool.
    • automate npm releases.
  • @nerrad
    • Implemented useSelect hook and it’s powering withSelect.
    • Is working on the useDispatch hook.
  • @gziolo
    • Spent one full working day triaging issues last week
    • https://make.wordpress.org/core/2019/05/27/the-block-registration-api-status-update/ – Is still awaiting feedback for the block.json proposal, hopes to finalize it this week.
    • Is helping @joen with improved UX for nested blocks.
    • Wants to start on Bring consistency to block toolbar for text blocks .
  • @mapk
    • Is working on a few Table block issues.
    • Is looking at word breaks in the Media_Text block.
    • Will look into custom fields checkbox in the Options menu.
    • Will check spacer block clearing floats.
  • @andraganescu
    • continues to work on the media blocks update flow.
  • @kjellr
    • Still helping support the nested block work from @joen
    • Thinking about providing suggested column layouts: https://github.com/WordPress/gutenberg/issues/15663#issuecomment-496568894
    • Narrowing down the icons for the Group block: https://github.com/WordPress/gutenberg/issues/15602
  • @jorgefilipecosta
    • Past week:
      • Worked on the widgets screen endpoints and frontend rendering of blocks in the widget areas, a summary of the work was posted in https://github.com/WordPress/gutenberg/issues/13204#issuecomment-496934219.
      • Worked on other enhancements e.g.: text color in the heading, link UI on the images and some editor bug fixes.
    • Next week:
      • Will explore a short term very specific project board to make organizing PR’s and issues easier.
      • Continue the work to solve generic block editor problems affecting the widgets screen and probably external usages of the block editor.
      • Address reviews on the image link UI.
      • Work on some bug fixes and UI enhancements e.g. explore insert by URL on cover and media text blocks to make them more similar to the other media blocks.
      • Improve the contrast checking to make aware of parent colors (e.g: group block) and solve some bugs.
  • @iseulde
    • Plans to continue with this roadmap: https://github.com/WordPress/gutenberg/issues/13778.
    • Is a bit busy with conferences.

To anyone reading this, it is possible to participate in the task coordination in an async way. Feel free to comment in this post with the tasks that you worked on during the last week and/or what tasks you plan to work on during the next week.

Inline color support

@paaljoachim asked participants in the core editor chat to discuss his comment https://github.com/WordPress/gutenberg/issues/8171#issuecomment-496304938, that proposes the addition of inline color support.

@youknowriad said:

I think that is something we can consider, it should be tracked in its own issue separately from the block level color support tracked in 8171.

@mapk volunteered to create an issue to track this task.

@iseulde said that this task is on the rich text roadmap, but would be good if there’s a separate issue.

@mapk referred that @phpbits volunteered to implement this feature. Thank you @phpbits!

@youknowriad would like some design and API explorations and referred that the following questions should be considered:

  • What inline formatting do we want to support aside colors?
  • Do we want to gather these in a panel/popover?
  • In terms of API, how can we control the availability of these options?

Open Floor

@iseulde proposed a dedicated place (a specific meeting/a channel) to have conversations related to the RichText component.

@youknowriad asked why does it need to be separate from the current meeting? While adding that he not suggesting we don’t do it but was wondering if a section during the core editor meeting could be dedicated to RichText when needed.

@iseulde shared that in her opinion core-editor has become very broad and she thinks it might be good to have something smaller. She is not sure about set meeting times, she thinks that perhaps just a space where people can chat async is enough.

The conversation went on with some people trying to understand the current challenges communication related to RichText faces, and some people showing support to the idea of a RichTextspecific communication medium.

@youknowriad ended the meeting by saying that we should experiment and see what works and asked @iseulde to keep us updated.

#core-editor, #editor-chat, #summary

Editor Chat Summary, May 22nd

Agenda, Slack Transcript


  • WordPress 5.2.1 was released and comes with a few Block Editor bugfixes, including RTL keyboard navigation and Format API ones.

Task Coordination

Slack Transcript

Visibility of documentation

Agenda, Slack Transcript

@karmatosed raises the question of how we can make the User docs and Developer docs more visible. Raised from community engagement.

Action items:

  • Engage docs and marketing. @karmatosed and @chrisvanpatten
  • Publish a make post on existing doc resources. @karmatosed
  • Add links to docs in https://wordpress.org/gutenberg/ (to be discussed with marketing). @karmatosed
  • Idea worth exploring: how docs can be surfaced the Help tab in wp-admin. Unowned.

Open Floor

Slack transcript

@yannicki asks about the status of adding an inner container to the Group block. It’s in review status and there is some uncertainty around the approach. Will get more attention in the next weeks.

New package @wordpress/data-controls. To be released to npm in next Gutenberg release (expected in a week). @nerrad

Work continues to explore useSelect primitive in @wordpress/data package. @nerrad

Triage sessions: @youknowriad @nerrad @karmatosed

  • these group activities with a set schedule are valuable to bring new contributors and clarify the status of certain proposals
  • this can be resource expensive if they’re ran and attended by the core-team only
  • to be continued and evaluated after a while

#core-editor, #editor-chat, #summary

Editor chat summary: May 15

This post summarizes the weekly Editor meeting on Wednesday, May 15, 2019, 4:00 PM GMT+3 held in Slack.

The agenda followed can be found here.

Gutenberg 5.7

Gutenberg 5.7 was released today, congratulations to everyone who participated in this release!

Gutenberg Docs are now in the WordPress DevHub

You can check this out at: https://developer.wordpress.org/block-editor/  They have also been reorganized for better navigation and discoverability. Props to @nosolosw @chrisvanpatten @coffee2code @mkaz @kenshino.

WordPress 5.3 planning

During the previous dev chat the scope of the WordPress 5.3 was discussed. Today @youknowriad asked what can we get into that release from the Core Editor team.

@youknowriad, @aduth, @joen, @getdave proposed new Gutenberg features and updates to land in  WordPress 5.3 (to be released in late August):

Improvements we can safely expect:

  • Columns Block Resizing
  • Group Block (new block)
  • Nested Block Selection improvements
  • Table Block
  • UI improvements: Micro-animations, publishing flow tweaks, Snackbar notifications
  • Selecting parent blocks with clickthrough
  • Block Grouping

Big subjects and uncertain features:

  • A Navigation Block
  • A new widgets screen
  • The Block Registration API relying on block.json


  • @mapk expressed concern over committing to landing a Navigation Block in WordPress 5.3 because of a lacking clear place to use the block once it becomes available in the Inserter.
  • @youknowriad expressed hope that we’ll soon have a « widgets screen » prototype in the plugin and clarify whether this can be part of the release or not.
  • @gziolo: Beta 1 is the deadline for new features which means late July to have everything ready

Task Coordination

Explicit Draft statuses for RFCs

There is an increasing worry over the current state of the Widgets RFC because it is hard to make sense of it, or to follow developments as it’s now at over 170 comments. It became a good example that when trying to devise the perfect all-encompassing plan, discussion can become fragmented, we lose sight of the larger goal, and momentum halts.

There was as lively discussion about this and @youknowriad identified the following actionable steps:

To handle multiple merged RFCs @aduth proposed we’d have a Project board with a column for each RFC, and each column would contain issues or PR’s that affect that column’s RFC.

A second Gutenberg triage session that is more APAC timezones friendly

The proposal is to have a second Gutenberg triage session around 06:00 UTC, every two weeks, in the slack #core-editor channel, but no day is yet. @danr, @noisysocks and, @andraganescu would attend/run the sessions and we’d love it if others could join/help. The reasoning is that many struggle to attend meetings or triage sessions due to timezones, so this would be a chance to get involved at a more comfortable time of day.


  • the general feeling was that it’s a good idea and that it should happen.
  • @youknowriad suggested it could include new contributors help


Have thoughts on the above? Please leave a comment on this post!

The agenda for the next meeting, on Wednesday, May 22, 2019, 4:00 PM GMT+3 , is here; please add anything that you want to discuss.


Editor Chat Agenda: May 8th

This is the agenda for the weekly editor chat meeting on Wednesday, 8th May 2019, 13:00 UTC.

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

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

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