What’s new in Gutenberg? (27 November)

More than 51 contributors helped shape the 7.0.0 Gutenberg release. It’s one of the biggest number of contributors we’ve ever had.

The release includes a big number of fixes and enhancements to the Navigation block and marks it as a stable feature.

Navigation block in action

In terms of APIs, developers will be happy to know that this PR introduced some new APIs like allowing the internationalization of strings containing safe HTML, a new Card component in wordpress/components and a few other enhancements we encourage you to try and provide feedback.

7.0

Features

Enhancements

Bug Fixes

New APIs

Experiments

Documentation

Various

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 7.0.0 5.1s 67.7ms
Gutenberg 6.9.0 6.6s 53.5ms
WordPress 5.3 6.3s 61.44ms

👏 Kudos to all the contributors. Thank you.

#core-editor, #editor, #gutenberg

Media Meeting Recap – November 14, 2019

The following is a summary of the weekly media component meeting that occurred on Thursday, November 14, 2019. Weekly media meetings are held every Thursday at 14:00 UTC. A full transcript can be found here in the #core-media room in the Make WordPress Slack.

Attendees: @sergeybiryukov , @pbiron, @spacedmonkey, @afercia, @dinhtungdu, @azaozz

Post 5.3 Triage

There were a few issues that came to light after folks updated to the 5.3 release.

Issues discussed:

  • #48632 : Cannot upload images directly from blogpost – Meeting participants attempted to replicate but were unable. Related issues were #48620 and #48604 in which one of the issues were due to a plugin.

That’s all that was reported as of meeting time last week! Thank you to everyone that contributed to WordPress 5.3! It really is a great update.

Meeting Scheduling Discussion

As you may have noticed, the time for the meeting was adjusted for Daylight Savings Time and moved later by one hour. There was some discussion in the meeting around adding a second meeting to the week allowing folks from both sides of the planet to participate. If you are in the AMEA region, please leave your thoughts on when the day and time of the week that works best. This topic will be revisited in the next meeting on Thursday, November 21, at 14:00 UTC

It was also mentioned that in this new scheduling model, it would be desired to move the currently scheduled meeting later one hour. This is of course only if there is another AMEA friendly meeting scheduled.

New Issues Triage

The meeting transitioned to a bug scrub after discussion about scheduling.

  • #48562 : Audio keeps playing on closing of media/attachment details popup in WP Admin – This was reproducible via the Media Library page in grid view. This issue has been around since 5.2 also so this is not a regression. Work is happening in the ticket to fix it up. The remainder of the meeting was filled with bunnies and discussion around a fix for the issue.

Feedback

If you have any feedback on the above, please feel free to leave a comment, join in #core-media for a chat, or attend the next meeting on November 21, 2019 at 14:00UTC!

#core, #core-accessibility, #core-media, #media, #summary

Core Editor Summary for November 20

This post summarises the weekly editor chat meeting (agenda), held on Wednesday, November 20, 2019, 14:00 UTC in core-editor Slack channel.

Weekly Priorities

Slack transcript.

See November Priorities post. Good to focus on these things as the month wraps to an end and start thinking on next steps.

  • Block Content Areas: expected to still be a focus for a while.
  • Navigation block (board): is close to get out of the experimental phase into the plugin.
  • Tightening up (board):
    • Polish to blocks and different parts of the UI is continuing.
    • Gradients are coming along nicely.
    • Some progress is being made to the Block Selection Tools.
    • Add color to specific text inside RichText (16014) is blocked by 17617 It’d be good to unblock those.

Triage role for GitHub

Slack Transcript.

GitHub has recently created a few new roles with more fine-grained permissions. One of those is the Triage Role that enables people to manage issues and pull request, and well as other actions. There was a consensus that this new role could help onboard new contributors and less technical folks who are not part of the Gutenberg group already.

Tasks:

If you’re interested in joining the Triage group, please, leave a comment in the agenda or the GitHub issue.

Task Coordination

Slack Transcript.

If you’re reading this asynchronously, please, add your notes as comments.

Open Floor

Slack Transcript.

Welcome feedback on this exploration of hover/selection states for Full Site Editing concepts by @shaunandrews

Request For Comments experiment. A few months ago Gutenberg started doing a RFC for major features following this post. @youknowriad noted that it didn’t get as much traction as expected. Many agreed. To close this experiment and the open RFCs is being considered.

If you have any feedback about the RFC experiment, please, comment on this post or reach out to people involved. Feedback channels will be opened until next week when a decission will be made.

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

Dev Chat Agenda for November 20, 2019

Here is the agenda for the weekly meeting happening later today: Wednesday, November 20, 2019, 09:00 PM UTC.

Agenda

  • Announcements
    • Highlighted posts
  • Upcoming releases
  • 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.

#agenda, #core, #devchat

REST API Chat Summary: November 14

This post summarizes the weekly REST API chat meeting for November 7, 2019. (Slack transcriptAgenda). Weekly REST API component office hours are held every Thursday at 18:00 UTC in the #core-restapi room in the Make WordPress Slack.

Authentication

A new wp-api/authentication GitHub repository was created last week to facilitate the design & development of a REST API authentication solution for WordPress Core.

We continue to be in the information gathering stage. For all interested in contributing to this effort, we will be using part of our weekly REST API office hours each Thursday at 18:00 UTC (Thursday, November 14, 2019, 01:00 PM EST) as a weekly standup to coordinate work.

We also invite you to log issues describing use cases the authentication solution should support.

Registered Block Types REST API

#47620 aims to create REST API routes to discover the list of registered block types. It is based off the Gutenberg Block Type Registration RFC. @spacedmonkey worked on a patch and is in the process of soliciting feedback from the Gutenberg team, Mobile team, and other members of the REST API team.

A particular point of concern @spacedmonkey brought up was the difficulties about handling the asset fields ( editorScript, script, editorStyle and style ). The RFC defines the fields as either absolute URLs or relative paths to the source files. However the WP_Block_Type class defines those fields as asset handles.

Further the asset URL or handle is not sufficient to make the asset functional. The list of dependencies, inline scripts, translations, and localized data are all necessary for the script to work.

@timothyblynjacobs mentioned that the RFC discusses statically discovering that information from an associated .asset.json file located “next” to the script file. @aduth mentioned that section is slightly out of date since @wordpress/scripts now outputs a .php file instead of a JSON file.

The participants discussed whether it would be better to include this additional information inline in the Block Type response, or to develop a separate wp/v2/dependencies API.

@timothyblynjacobs suggested that including this information inline would be simpler. @spacedmonkey pointed out that then we’d be including full data from a separate resource within the block type response. Elsewhere in the REST API that would be handled by creating a separate API and linking to it.

Additionally, @timothyblynjacobs pointed out that just exposing the list of dependencies isn’t sufficient. The client needs access to the entire dependency graph to ensure each dependency’s dependencies are loaded, and that all scripts are loaded in the correct order.

This all points to a dedicated REST API endpoint being a better solution. The team then discussed the potential privacy and security ramifications about retrieving this information about any registered asset.

A developer may include sensitive data in a wp_localize_script or wp_add_inline_script after registering the script with wp_register_script. Currently, this data would only be exposed when the script is enqueued, which may be protected by a current_user_can or $hook-suffix check. If the REST API allowed returning information about an arbitrary asset handle, this data may be exposed.

Additionally, a developer may conditionally registers asset based on a plugin’s settings. By allowing a user to check if a handle is registered via the REST API, it may be possible to determine the setting configuration of a plugin. This may not be desirable for security or privacy related plugins.

@kadamwhite mentioned that historically the REST API has been pretty conservative about what data is exposed. If possible, he’d like to continue along that path. Or theoretically authentication could be required for some pieces of the API since the use case seems to mostly be for editorial interfaces which would require auth anyway. @spacedmonkey also suggested a capability check.

@spacedmonkey and @timothyblynjacobs proposed limiting the assets exposed to ones registered via WP_Block_Type and all WordPress Core assets. Additional assets could be exposed via a registration flag of some kind, like show_in_rest.

Both @aduth and @youknowriad mentioned that this functionality would not just be useful for blocks. As WordPress moves more and more to JS powered interfaces, the ability to lazy load assets will become increasingly important. The problem here could be generalized to “retrieve all the information necessary to properly load a handle”.

@youknowriad opened a ticket, #48654, to continue the discussion on Trac.

Agenda for November 21

The next REST API meeting is happening in #core-restapi at Thursday, November 21 at 18:00 UTC. Agenda:

  • REST API Authentication project weekly meeting
  • Menus API discussion
  • WP Dependencies API
  • Review open tickets which should be provisionally milestoned for 5.4
  • Open floor

#meeting-notes, #rest-api

REST API Chat Summary: November 7

This post summarizes the weekly REST API chat meeting for November 7, 2019. (Slack transcript, Agenda). Please note that this meeting did not change time for daylight savings, and Weekly REST API component office hours continue to be held every Thursday at 18:00 UTC in the #core-restapi room in the Make WordPress Slack. 🙂

Authentication

The first half of the meeting discussed the newly-created wp-api/authentication GitHub repository, a follow-up to discussions at WCUS contributor day around rebooting work towards a canonical, core Authentication solution to permit the Mobile team to use the REST API instead of XMLRPC.

Our target for a merge proposal some time next year is to have an use the OAuth 2 handshake flow with dynamic client registration, which issues revocable, long-lived JWT tokens. The repo has no content so far, but we will start work by focusing on UX and the desired user-facing and technical flow rather than diving immediately into code.

@spacedmonkey, @derekherman, and others intend to drive this project over the coming months. If you who is reading this or any colleagues of yours are interested in contributing to this effort, we will be using part of our weekly REST API office hours each Thursday at 18:00 UTC (Thursday at 18:00 UTC) as a weekly standup to coordinate work.

Priorities & Goals

Priorities for Next Release

Key tickets highlighted for consideration as part of the next release cycle include, but are not limited to,

  • Improve performance in route matching #48530
  • Support registered default meta values #43941
  • Permit schema filtering #47779

If you have a ticket to highlight or propose for the next bugfix or major release, please leave it as a comment below or raise it in #core-restapi. Thank you once more, as well, to everybody who helped drive our API improvements in 5.3!

Documentation

We are behind schedule in updating the REST API handbook to cover the recent changes in WordPress 5.3. @timothyblynjacobs and @kadamwhite will be working to roll these updates out over the coming week. Handbook content is managed at github.com/wp-api/docs.

Open Floor

@timothyblynjacobs raised #44568 and #44886. Because WordPress operations are non-atomic, these race condition issues are not limited to the REST API and were determined to be out-of-scope, so #44886 was closed as wontfix.

Several bugs were raised and have been provisionally milestoned for 5.4, with the option to backport as needed once addressed.

To increase contributor awareness of REST API tickets, we discussed holding periodic component scrub meetings in the main #core channel.

Agenda for November 14

The next REST API meeting is happening shortly in #core-restapi at Thursday, November 14, 18:00 UTC. Agenda:

  • REST API Authentication project weekly meeting
  • Review open tickets which should be provisionally milestoned for 5.4
  • Open floor

#meeting-notes, #rest-api

Dev Chat Agenda for November 13, 2019 (Post 5.3 week 1)

Here is the agenda for the weekly meeting happening later today: Wednesday, November 13, 2019, 09:00 PM UTC.

Agenda

  • Announcements
    • Highlighted posts
  • 5.3
    • Housekeeping
  • 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

Core editor chat summary November 13th, 2019

This post summarises the weekly editor chat meeting, agenda here, held on Wednesday, November 13th 2019, 13:00UTC in Slack, moderated by @jorgefilipecosta, notetaker: @andraganescu

Next week’s Core editor chat time: 14 UTC

Because of DST there was a decision to move the meeting one hour later. The async discussion is still open until Monday, November 18th to decide if people, other than those present at he core editor chat want it differently.

WordPress 5.3 was released yesterday

@youknowriad: Big kudos to all the contributors. It’s a huge release for the block editor

@jorgefilipecosta I would like to thank all the people that contributed and made all this improvements and bug fixes possible!!

There is some current effort to iron out issues that may appear.

Gutenberg 6.9 will be released today

A Release Candidate is already available at https://github.com/WordPress/gutenberg/releases/tag/v6.9.0-rc.1

@aduth and @ella are working on that (release post and performing the release)

Weekly priorities

The main priorities are the same ones highlighted in the November post What’s next in Gutenberg? (November) – Make WordPress Core

Also, one of the priorities is to fix WordPress 5.3 regressions as they come up.

Task coordination

@youknowriad

  • I was AFK for some days post WCUS
  • I worked on the WordPress 5.3 release a little bit
  • I’ll be focusing on support, triage and reviews for the next week.

@karmatosed

  • Navigation block: styling, reviews and testing
  • Triage: I want to dig in a bit and try and clear down low hanging tasks
  • Begin working out sprints for Tightening Up board. I have an idea to for 1-2 weeks focus on an area, move on and repeat.
  • Support is for me next week so last point won’t happen until week after.

@retrofox

@getdave

  • I’ve been focused mainly on Nav Block related PRs.
  • In particular, I’d draw attention to this one I created to allow parent Blocks to “consume” the toolbar of their children via InnerBlocks https://github.com/WordPress/gutenberg/pull/18440

@pbrocks

@michaelarestad

  • starting in on full site editing – largely research/information gathering at this point

@mapk

  • Helped review some of the Nav block work.
  • Worked on the Media replace flow.
  • Reviewed linking media in Media+Text block.
  • Helped @michaelarestad with some full site editing research.

@andraganescu

  • continued on the navigation block
  • need a code review on the media replace control here: https://github.com/WordPress/gutenberg/pull/16200

@nerrad

@jorgefilipecosta

  • I finished a big refactor for the legacy widgets, made some improvements on the custom gradient picker, worked on some PR reviews, continue the work around having configurable inner block settings to allow a parent block to absorve the child, and continued the iterations on some PR’s I had open.
  • For the next week, I’m hoping to merge the simulated media queries mechanism; I want to get involved again in the navigation block work, so I hope to do many reviews there and maybe pick up some tasks, besides that I will continue the buttons block and innerblocks UI work.

@tellthemachines

  • For task coordination: I’ve mostly been reviewing nav-related PRs this week and will be away from the 14th to the 24th November. (In case anyone wonders why I’ve gone strangely silent :D)

@noisysocks

  • I’m still looking at nav-related PRs and working on the Welcome Guide as time permits.

@gziolo

@youknowriad highlighted the new Storybook available at: https://wordpress.github.io/gutenberg/

It is also important to note for people reading this async: it is possible to participate on the task coordination by commenting on the agenda.

Open floor

  • Embedding Multilingual ability as standard core functionality: seems a bit early for implementation but it’s definitely being considered.

Let’s review more PRs!

Just a note to everyone. Do please also spend a little time going through older PR’s. As there are many just hanging waiting for a comment, a review etc. We’re definitely falling behind in terms of reviews.

The number of open PR’s increasing which in part is a good signal it means the project is getting more interest, but we should try to review these PR’s as soon as possible so new contributors keep the interest in contributing and we get the features/fixes sooner.

#core-editor, #editor-chat

Javascript Chat Summary – November 12, 2019

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.

Switching to Prettier

Slack | Github Issue

Some discussion ensued on what is needed to merge this pull.

  • Post on make.wordpress.org regarding any code standard changes affected by this pull (and to inform about the change). This will need further feedback from core lead devs, core committers and contributors.
  • There are some rule removals from the es-lint plugin package, some discussion ensued about how to handle that and are those changes necessary. At a minimum, there seems to be some agreement that the ESLint rules should match the standards.

Tasks:

  • Check how many of the existing eslint rules could stay unmodified and what can be tweaked to work with Prettier and which need to be disabled. Should align with whatever standards are for the project (including any necessary modifications to those standards)
  • We should also seek a way so that the eslint plugin can continue to be used without prettier so folks can have the benefit of styling standard checks the same way as of today.
  • Once the above is done, write a post on make.wordpress.org/core outlining the changes and inviting feedback.

__experimentalCreateInterpolateElement

Slack | Github

This is a new function that makes it possible to interpolate elements within a translated string and have those rendered as react elements. Currently, doing something like the following can’t be done in react.

const MyLinkComponent = ( { href } ) => {
    return wp.i18n.__( 'This is a <a href={ href }>link</a>' );
};

In order to have <a> render, you’d need to split up the string, which in turn breaks context for translations. The solution is __experimentalCreateInterpolateElement:

const MyLinkComponent = ( { href } ) => {
    return __experimentalCreateInterpolateElement(
        wp.i18n.__( 'This is a <a>link</a>' ),
        { a: <a href={ href } /> }
    );
};

If you have any feedback or concerns with the proposed api please give feedback in the pull.

In the meeting:

  • generally seems to be approval around the api
  • concerns over whether the parsing should be cached.
  • wondering whether there’d be value in introducing a useInterpolation hook (that could also take care of some of the caching)
  • adding some sort of performance testing (although since it’s not used anywhere, there’s nothing currently in the project that can help with this).

Upcoming React Features

Slack

In this portion of the meeting there was mostly just some resource and link sharing around upcoming react features:

  • https://reactjs.org/docs/concurrent-mode-adoption.html
  • https://reactjs.org/blog/2019/11/06/building-great-user-experiences-with-concurrent-mode-and-suspense.html
  • https://www.youtube.com/playlist?list=PLPxbbTqCLbGHPxZpw4xj_Wwg8-fdNxJRh (React Conf 2019 playlist)

#javascript, #meeting-notes

WordPress 5.3 RC 5

The fifth release candidate for WordPress 5.3 is now available for testing.

WordPress 5.3 is currently scheduled to be released on November 12 2019.

There are two ways to test WordPress 5.3 release candidate 5:

For details about what to expect in WordPress 5.3, please see the first,  secondthird and fourth release candidate posts.

Release Candidate 5 contains some bug fixes for the new default theme, Twenty Twenty – for reference, see #48557 – and addresses the following tickets:

  • #47708 – 5.3 about page
  • #48312 – Fix a typo in an inline comment
  • #48542 – In wp_default_packages_inline_scripts(), make sure the root URL middleware is registered before using the media middleware
  • #48543 – Comments: check if comment form element exists before adding a key handler to detect the cmd/ctrl-enter key press.
  • #48517 – Bundled themes: several changes to ensure consistency and accuracy for default theme headers
  • #48518 – Upload: When an image was scaled because it is larger than the big image threshold, use the originally uploaded image’s dimensions in wp_get_missing_image_subsizes(). Fixes an edge case/inconsistent behaviour when a registered image sub-size is also larger than the big image threshold.

Plugin and Theme Developers

Please test your plugins and themes against WordPress 5.3 and update the Tested up to version in the readme to 5.3. If you find compatibility problems, please be sure to post to the support forums so we can figure those out before the final release.

The WordPress 5.3 Field Guide has also been published, which details the major changes.

How to Help

Do you speak a language other than English? Help us translate WordPress into more than 100 languages!

If you think you’ve found a bug, you can post to the Alpha/Beta area in the support forums. We’d love to hear from you! If you’re comfortable writing a reproducible bug report, file one on WordPress Trac, where you can also find a list of known bugs.

#5-3, #testing