Editor chat summary: 14 August 2019

This post summarizes for the weekly editor chat meeting on Wednesday, August 14, 2019 at 1300 UTC held in Slack.

The agenda can be found here.

Gutenberg 6.3 

  • @riad noted that this release is a very important release in terms of Accessibility because it introduces the Navigation Mode

Priorities for next week

Please don’t hesitate to help there. Provide a11y and design feedback. Help with tests… Let’s move these forward.

Task Coordination

Based on the links in Task Coordination, Riad extracted a list of PRs where feedback is needed:

Open Floor

There was a discussion about new core blocks being developed. The central idea is that some ideas, while good, are low priority, for example the gists block or the multi select dropdown.

Riad explained that the ideas for the blocks themselves are good but “we added components as we needed them in Core and Core blocks. Doesn’t mean we can’t add components for third-party authors if they prove to be useful for a lot of persons but we’d need contributors to champion these”

There is also a list of new blocks that are high priority and considered “blessed tasks” and the list includes: icons, menu, social icons, divider and other Full site editing related blocks (site title, post title, post categories).


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

The agenda for the next meeting, 21 August 2019 13:00 UTC is here, please add anything you want to discuss.

#core-editor, #core-restapi, #editor, #gutenberg, #meeting-notes

What’s new in Gutenberg? (14 August)

The Gutenberg 6.3 release is an important milestone in terms of accessibility of the editor.

Gutenberg comes with a lot of features by default, each block can be manipulated with custom controls in its toolbar and inspector panel, block movers, a drag handle. The block UI also includes the content of the block itself which can be complex from block to another. This makes it very challenging for screen reader users to navigate the content of their posts.

To address that issue, we’re introducing the Navigation Mode. By default the editor is loaded in this mode, it allows you to move from block to block using a single Tab press. You can also use the arrow keys to navigate between blocks. Once you reach the block you want to edit, you can enter the Edit Mode by hitting the Enter key. The Escape key allows you to move back to the Navigation Mode.

It’s very important for us to make the editing experience as enjoyable as possible for all the users with different accessibility needs. This feature is very early, please help us test it and we’re looking forward to taking your feedback into consideration.

This feature includes dozens of improvements and bug fixes including:

  • support for text alignments in table block columns.
  • Border color support for the separator block.

For developers, new APIs are available such as the BlockPreview component that allows you to render and preview blocks in any context.

6.3

Features

Enhancements

Experiments

New APIs

Bug Fixes

Various

Documentation

Mobile

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.3.0 4.8s 53.5ms
Gutenberg 6.2.0 4.5s 49.7ms
Gutenberg 5.3 (WordPress 5.2) 5.6s 60.1ms

👏 Kudos to all the contributors. Thank you.

#core-editor, #editor, #gutenberg

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 summary: 7 August 2019

This post summarizes for the weekly editor chat meeting on Wednesday, August 7, 2019 at 1300 UTC held in Slack.

The agenda can be found here.

Task Coordination

Open Floor

@karmatosed and @chrisvanpatten brought up the need for leadership in user focused documentation for Gutenberg.

Graphics requested for Gutenberg documentation can be found on the Design team’s board.

@paaljoachim offered to reach out to the docs team for assistance in moving forward. If you’re interested in helping with user-focused docs for Gutenberg, please reach out in the comments here or in the #core-editor channel!

@kadamwhite mentioned that the REST API team is working on catching up with requests for feedback on tickets and invited folks to the the #core-restapi channel to connect.


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

The agenda for the next meeting, 14 August 2019 13:00 UTC is here, please add anything you want to discuss.

#editor, #gutenberg, #meeting-notes

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

What’s new in Gutenberg? (31 July)

The number of Gutenberg contributors is growing significantly and it’s a pleasure to see how people from all around the world come together to build and improve the software. I’d like to take this opportunity to thank the 48 contributors that participated in this release.

Among the improvements of Gutenberg 6.2, a feature that might seem small but which a lot of people were waiting for: the possibility to customize the target of the Button block (open the link in a new tab).

We also had a lot of people asking for the possibility to use all kinds of block types in the Cover and Media & Text blocks, so we’ve removed their nested block restrictions.

From a Developer Experience perspective, this release introduces a new PHP API to simplify the registration of block styles variations.

// Registering a style variation using a registered WP style.
register_block_style(
	'core/quote',
	array(
		'name'         => 'fancy-quote',
		'label'        => 'Fancy Quote',
		'style_handle' => 'myguten-style',
	)
);

// Registering a style variation using an inline style.
register_block_style(
	'core/quote',
	array(
		'name'         => 'not-fancy-quote',
		'label'        => 'Not Fancy Quote',
		'inline_style' => '.wp-block-quote.is-style-not-fancy-quote { color: blue; }',
	)
);

6.2

Enhancements

New APIs

Bug Fixes

Documentation

Divers

Mobile

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.2.0 4.8s 67.2ms
Gutenberg 6.1.0 5.9s 67.2ms
Gutenberg 5.3 (WordPress 5.2) 7.6s 80.13ms

👏 Kudos to all the contributors. Thank you.

#core-editor, #editor, #gutenberg

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!

@tellthemachines

  • 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.

@youknowriad

  • 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.

@mapk

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

@jorgefilipecosta

  • 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.

@karmatosed

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

@brentswisher

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

@kjellr

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

@getdave

  • 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

What’s new in Gutenberg? (10 July)

A few weeks ago, Matías shared a post about using motion to express change in reactive UIs. This release is a first step in implementing those ideas. It introduces motion to block changes, creation, removal, reordering.

In addition to a number of other improvements and bug fixes, the contributors also worked on typing performance. As of this release, typing is 30% faster on long posts.

6.1

Enhancements

Experiments

Bug Fixes

Performance

Documentation

Various

Mobile

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.1.0 5.2s 56.89ms
Gutenberg 6.0.0 5.4s 80.2ms
Gutenberg 5.3 (WordPress 5.2) 4.9s 66ms

👏 Kudos to all the contributors. Thank you.

#core-editor, #editor, #gutenberg

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!

@nerrad

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

@youknowriad

  • 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.

@aduth

Made a few small pull requests, reviews, focusing mostly on “custom” sources for blocks (reimplementing meta to start)
https://github.com/WordPress/gutenberg/pull/16402.
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.

@danr

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

@welcher

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.

@kjellr

Has been posting some work on revised, less-intrusive tips:
https://github.com/WordPress/gutenberg/issues/16315.

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

@getdave

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:
https://github.com/WordPress/gutenberg/pull/16278.

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.

@nadir

Continues the work on Snap to grid RFC.

@jorgefilipecosta

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.

@chrisvanpatten

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

Introducing the WordPress e2e tests

The purpose of e2e (end to end) testing is to simulate the real user scenario and validate the different flows. In concrete, running an e2e test involves setting up a production-like environment, opening a browser and interacting with the application as it was a real user manipulating the interface. This is one of the best testing methodologies to avoid regressions.

Gutenberg has been successfully using this kind of tests for some time now. Reusable packages to setup and run e2e tests have been built in the repository. Starting today, this setup was brought into WordPress and included in our CI pipeline.

Local Environment

The e2e tests require a production-like environment to run. The current setup relies on Docker to provide a built-in environment.

You can run the environment locally on your own WordPress Core clone.

First, make sure you have Docker installed (instructions on this link).

Then, you should be able to run the environment by running these commands on your own WordPress repository clone.

npm install
npm run env:start

This command will make sure you have the right node/npm versions installed, triggers docker containers for your web and mysql servers and installs WordPress using the build folder.

You can also reset the environment with a testing website using:

npm run env:reset-site

You should be able to access your environment on http://localhost:8889. The default username is admin and the password is password.

Running the e2e tests

Once your environment ready, you can launch the e2e tests suite by running:

npm run test:e2e

This will run the test suite using a headless browser. For debugging purpose, you might want to follow the test visually. You can do so by running the tests in an interactive mode.

npm run test:e2e -- --puppeteer-interactive

you can also run a given test file separately

npm run test:e2e tests/e2e/specs/hello.test.js

Writing e2e tests

The e2e tests live in the tests/e2e/specs folder and should be follow the following naming format my-file.test.js.

The e2e tests use Jest as a testing/asserting framework, and rely on Puppeteer to communicate with the browser.

A typical e2e test looks like that:

// Load utilities from the e2e-test-utils package.
import { visitAdminPage } from '@wordpress/e2e-test-utils';

// Name of the test suite.
describe( 'Hello World', () => {

	// Flow being tested.
	// Ideally each flow is independent and can be run separately.
	it( 'Should load properly', async () => {
		// Navigate the admin and performs tasks
		// Use Puppeteer APIs to interacte with mouse, keyboard...
		await visitAdminPage( '/' );

		// Assertions
		const nodes = await page.$x(
			'//h2[contains(text(), "Welcome to WordPress!")]'
		);
		expect( nodes.length ).not.toEqual( 0 );
	} );
} );

e2e test utilities

When writing e2e test, you’ll notice that some actions are repeated across tests. Things like:

  • Login into the dashboard
  • Go to a page
  • Activate/Deactivate a plugin
  • Create a new post
  • Create a dummy page

A number of these utilities is already available in the @wordpress/e2e-test-utils package, in the Gutenberg repository. You’re encouraged to use and share reusable utilities across tests.

In addition to these utilities, you can checkout the Puppeteer API Docs to manipulate the browser.

We need you

Please give it a try, the more we add tests, the more stable our releases will be. If you need support, ask in the #core-js Slack channel.

#core-editor, #core-js, #testing