Bug Scrub Schedule for 5.4

Now that 5.4 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. 1/21/2020 19:00 UTC
  2. 1/29/2020 23:00 UTC
  3. 2/7/2020 05:00 UTC (APAC-Friendly)
  4. 2/10/2020 16:00 UTC
  5. 2/18/2020 20:00 UTC
  6. 2/27/2020 23:00 UTC
  7. 3/2/2020 16:00 UTC
  8. 3/11/2020 TBD (If Necessary)
  9. 3/17/2020 TBD (If Necessary)
  10. 3/27/2020 TBD (If Necessary)
  11. 3/30/2020 TBD (If Necessary)

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 17:30 UTC at #design
Gutenberg Design Triage: Every Tuesday 17:00 UTC at #design
Accessibility Scrub: Every Friday 14:00 UTC at #accessibility

Also, the ongoing APAC-friendly #core bug scrub session every Thursday at 06:00 UTC will continue during the cycle, alternating focus between core and editor.

Next, the Accessibility team has announced a few extra scrubs for the 5.4 cycle. You can read about those here.

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.4-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.4, 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-4, #bug-scrub

XML Sitemaps Kickoff Meeting Announcement

A few weeks ago an update was posted for the XML Sitemaps feature project to give everyone an idea of where it is heading.

Now, we want to gather more contributors around the feature plugin and get your feedback on the project. For this, we’re kicking off regular meetings in the brand new #core-sitemaps Slack channel.

The first meeting will be held on Tuesday, February 18 at 16.00 CET and will serve as an introduction to the project and an opportunity to discuss the next steps. As such, there is currently no formal agenda for this inaugural meeting.

However, if you have anything specific that you’d like to propose being discussed in this meeting, feel free to leave a comment below.

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

#feature-plugins, #feature-projects, #seo, #xml-sitemaps

WP Notify meeting update.

Due to technical problems last week, the meeting scheduled for Monday, February 10, 2020 will be happening today Monday, February 17, 2020, 14:00 UTC .

You can view the agenda here.

This meeting is held in the #feature-notifications channel , to join the meeting, you’ll need an account on the Making WordPress Slack.

#feature-notifications

#agenda

CSS Chat Summary: 13 February 2020

I (@isabel_brison) facilitated the meeting based on this agenda.

Full meeting transcript on Slack

First point: how to set standards for using CSS grid in core, especially regarding browser support

I launched the question: why use grid? 

And proposed its main advantage for us is in complex multi-column layouts, in particular if they have dynamically sized columns (such as the columns block).

@laras126 mentioned grid may be more performant in rendering versus flexbox, based on this blog post.

@peterwilsoncc suggested using grid with @supports-based fallbacks, whether using the non-standard IE implementation of grid or otherwise.

I suggested a progressive enhancement approach, assuring basic functionality for IE.

@laras126 pointed out that using the IE implementation of grid is not recommended, referring to this blog post.

@afercia mentioned we could simply wait until WP stops supporting IE, and questioned whether we actually need to use grid. 

I mentioned some complex, buggy flex layouts could be fixed by using grid, but there’s no need to refactor all our layouts.

@peterwilsoncc proposed some parts of the admin could benefit, as grid reduces complexity for responsive layouts.

@afercia showed support for a redesign/refactor of WP admin if implemented in a mobile-first way.

@itsjonq considered that grid makes for cleaner, easier to understand code, so improves maintainability and stability.

Second point: how to approach using CSS variables in core, also regarding browser support

I introduced the topic by sharing the global styles proposal as example of the benefits of variables for theming and user customisation, and lamented the total lack of IE support.

@afercia manifested concern that this discussion may be overly Gutenberg-centric, based on the global styles proposal.

@itsjonq added that the current polyfills for variables don’t work 100% for all cases.

@laras126 suggested leveraging the cascade and Sass variables as fallbacks.

@peterwilsoncc proposed that use of @supports and its JS equivalent could make a progressive enhancement approach easier than with grid, e.g. colour schemes could switch to variables and be available only where supported.

I raised the question of dynamic styles, and suggested variables are extremely useful to use in this case, because they are easier to override than inline styles. However, this approach could only be used as an enhancement, with no IE support.

@peterwilsoncc reminded us that for the front end, IE compatibility is crucial, as ignoring it would force all our users to stop supporting IE themselves. Bearing this in mind, inline styles cannot be fully removed from the front end.

@afercia showed concern that CSS variables have already been introduced in core (on the About page), with no prior discussion.

Third point: should we adopt CSS-in-JS? 

I introduced the topic by pointing to my list of prior experiments and discussions about CSS-in-JS and stating two perceived advantages to it: reducing specificity and making it easier to reuse components anywhere.

@peterwilsoncc advocated for the importance of using a library that allows “easily styling state based styles without a tonne of mucking around with helper classes”, but expressed a preference for libraries that allow for the CSS to be precompiled rather than modifying the styles in the document, such as CSS Modules or CSS Blocks. He added that toggling classnames requires less re-rendering than stylesheet changes.

@laras126 suggested utility classes as an alternative approach to specificity issues and bloated stylesheets.

I observed that we’re not likely see a reduction in specificity until most or all of our CSS is refactored to CSS-in-JS, something very unlikely to happen.

@itsjonq clarified that he proposed CSS-in-JS specifically for wordpress/components because that package has unique style requirements: its components need to work everywhere, without additional styling. 

@afercia mentioned that CSS-in-JS is too coupled with proprietary JS library implementations, so it’s not future-proof enough in terms of conforming to web standards. He also pointed out that these solutions break the cascade in CSS, which is a fundamental aspect of the technology.

@itsjonq mentioned that there are attempts from these libraries to standardize approaches, though the proprietary aspect is indeed a concern. He reminded that we already use Sass, which is also a “non-standard” tool.

I reminded that standards can change in response to proprietary implementations, if they prove popular enough.

At this point, we reached the hour, but the discussion continued.

@peterwilsoncc pointed out the benefit of pre-compiled CSS files for future compatibility: the generated code can still be used if a technology changes.

I asked if it’s possible to precompile CSS-in-JS, to which @itsjonq answered there’s no good solution to do so yet.

@laras126 shared a movement to standardise design tokens that could be incompatible with a CSS-in-JS approach.

@afercia elaborated on his concern that CSS-in-JS breaks the cascade, as each individual element would need to be styled separately.

I suggested that issue can be avoided by using a combination of global and component-specific styles.

@afercia asked where CSS-in-JS can actually be helpful? To which @timothybjacobs replied: being able to reuse the Gutenberg wordpress/components outside of Gutenberg with reliable styling.

@itsjonq also replied that a lot of the internal Gutenberg styles are messy and overly specific, and that it’s difficult to reliably target UI that render at different locations in the DOM tree, e.g. Popovers.

@afercia reminded that specificity in Gutenberg is often because it needs to override wp-admin styles.

@itsjonq pointed out that the low specificity enforcement only works when starting from a clean slate, but there are workarounds available for integrating with legacy code (such as namespacing new styles to bump up specificity if needed). He shared his own helper library for this.

@afercia replied that this would create more specificity bloat, and @itsjonq observed that although that is the case, they would be sure to render correctly, i.e. there would be no clashes between old and new styles.

@laras126 made a helpful summary of needs that CSS-in-JS can help us meet:

  • Enforcing low specificity
  • Scoping styles
  • Bundling CSS with components
  • Enabling developers with varying backgrounds to write CSS safely

and offered to write up some notes about using single-declaration utilities as an alternative .

I also pointed out that CSS-in-JS makes it easier for JS devs, but harder for more UI-focused devs and designers to touch the code.

@laras216 asked if we should make this meeting a regular one, or at least have a follow-up. It was agreed to make it regular, and @noisysocks suggested same time next week.

@laras126 also shared a w3c proposal for selectors to reset specificity.

And that was it for this time!

WordPress 5.4 introduces apply_shortcodes() as an alias for do_shortcode()

WordPress 5.4 introduces apply_shortcodes() – a new function which is an alias for the current do_shortcode() function.

The semantics of do_* implies the function displays the result of the shortcode. But that’s not actually the case. In fact, do_shortcode() needs to be echoed to display its result.

Here is the current implementation:

echo do_shortcode( '[wporg]My Text[/wporg]' );
// Displays the result of the shortcode

Semantically, we should be able to do this:

do_shortcode( '[wporg]My Text[/wporg]' );
// but it doesn’t display anything…

As you may know, do_shortcode() is used in countless plugins and themes. So there is currently no option to deprecate it. But if the community can start building a consensus around the alias, apply_shortcodes(), then deprecation may eventually become a real option in the future.

There is a precedent for making this move. It’s the same process the core team followed with get_permalink() and get_the_permalink().

apply_shortcodes is meant to get better semantics: instead of performing an action and outputting to the current buffer, the idea is to apply filters to the input and return a result. The process is simpler, cleaner and more maintainable – not to mention easier to teach new developers.

apply_shortcodes() can be used the same way do_shortcode() is currently used:

echo apply_shortcodes( '[wporg]My Text[/wporg]' );
// Displays the result of the shortcode

Themes/Plugins authors and WordPress developers are invited to start using apply_shortcodes() instead of do_shortcode().

To be clear, there is no plan for deprecating the former function right now. But the sooner developers can all switch to the much more semantic apply_shortcodes(), the sooner the core team can plan to deprecate the old function. With WordPress 5.4, apply_shortcodes() is now the recommended way to display the result of a shortcode.


For reference, see the related Trac ticket: #37422

Copy review: @marybaum

#5-4, #dev-notes, #shortcodes

An updated Button component in WordPress 5.4

The Button component is a central piece of any Design System. As the WordPress design system implemented by the @wordpress/components package matures, its set of components get updated to gain in consistency and coherence. In WordPress 5.4, the Button component has been enhanced with several changes and additions.

Button sizes

To align with the overall design direction of the project, the button default height has been increased and is equal to 36px. This means the previous isLarge prop variation is unnecessary and should not longer be used.

The Button still support the isSmall variation.

import { Button } from '@wordpress/components';

const regularButton = <Button>My Button</Button>;
const smallButton = <Button isSmall>My Button</Button>;

Also, for consistency between the design of all the button variations, the buttons now have an explicit height in their CSS style. If you were relying on the fact that the height of buttons is dynamic and should adapt to its content, make sure to override the style of your button and add the following CSS rule.

height: auto;

Icon support

In previous versions, the components package used to offer a Button component to be used for regular buttons and an IconButton to be used for buttons with icons.

In WordPress 5.4, you can pass an extra icon prop to the regular Button component to display buttons with icons, you can also mix text and icons.

import { Button } from '@wordpress/components';

const myIcon = (
  <svg xmlns="http://www.w3.org/2000/svg" viewport="0 0 20 20">
    <path r="M5 4l10 6-10 6V4z" />
  </svg>
);

const SimpleIconButton = <Button icon={ myIcon } label="Button label" />;

const IconAndTextButton = (
  <Button icon={ myIcon }>
    Button Text
  </Button>
);

Note that the IconButton is still available but is officially deprecated.

Classname changes

In previous versions, the icon buttons used to rely internally on the components-icon-button. Now that the Button and IconButton components are merged into a single component, this class name has been removed and is replaced with .components-button.has-icon.

Note that it is recommended that you don’t rely on any internal className used by the different components. if you want to target a specific component, prefer providing your own className prop and use it instead.

Going further

If you want to try and play with the Button component or all the other wordpress/components, check out the components Storybook.

#5-4, #block-editor, #components, #dev-notes

Dev Chat summary – February 12, 2020 (5.4 week 5)

@davidbaumwald facilitated the chat on this agenda.
@audrasjb and @marybaum took care of publishing the meeting notes.

Full meeting transcript on Slack

This devchat marked week 5 of the 5.4 release cycle.

Announcements

WordPress 5.4 Beta 1 was released on Tuesday 11 as expected 🎉

Highlighted posts

Upcoming releases – 5.4

As mentioned, WordPress 5.4 Beta 1 was released on February 11th, 2020.

Please help by testing the Beta and reporting any bugs on WordPress Trac (or Gutenberg GitHub repository).

The Docs squad has published the first two dev notes:

The idea is to publish dev notes as soon as possible during the beta cycle and then publish the Field Guide before Release Candidate.

@audrasjb offered a quick update on Automatic Updates for Plugins and Themes. Because there is still work needed, along with extensive testing, decision is to start by managing autoupdates in a feature plugin and then merge into Core for 5.5.

Work on this feature plugin will start in the coming weeks.

Components check-in

@valentinbora is the new Administration Component maintainer.

In 2014, Administration was proposed to be moved from a component to a focus so it wouldn’t end up as a dumping ground for tickets. That decision led to its removal from the Components page, but not anywhere else.

Recently, this component returned to the Components page as per this Meta ticket, and it turned out that Administration still has a lot of tickets. The long term idea is to triage all the tickets that are there and, as part of that process, move those tickets to other components with the administration focus.

@whyisjake is now a Security Component maintainer.

Open floor

@whyisjake told the group that he’s going to help Two-Factor Authentication, currently developed on GitHub, move toward becoming a feature plugin for WordPress Core.

A first step: a proposal on Make/Core. @desrosj and @clorith are also interested in the project, which has been a discussion topic in the core-passwords Slack channel and in this GitHub pull request.

@whyisjake shared that he attended the CMS Security Summit last week, and Two-Factor Authentication was a major takeaway from the event, as was bringing automatic updates into Core.

@xkon added that #49200 needs input, so the team asks for yours. If you have any interest at all in cryptographic signature for plugins and themes, please follow the discussion on the dedicated Slack channel, core-signatures, and consider helping out.

#5-4, #auto-update, #security, #two-factor

Dev Chat Agenda for February 12, 2020 (5.4 Week 5)

Here is the agenda for the weekly meeting happening later today: Wednesday, February 12, 2020, at 09:00 PM UTC.

Announcements

  • This week marks week 5 of the 5.4 release cycle 🙌

Highlighted Blog Posts

Upcoming Releases – 5.4

  • Beta 1 Released

Components Check-in

  • News from components
  • Components up for adoption (Filesystem API and Rewrite Rules)
  • Components that need help
  • Cross component collaboration

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-4, #agenda, #core, #devchat

Changes related to Calendar Widget markup in WordPress 5.4

The HTML 5 specification permits the <tfoot> to precede the <tbody> element. That changed in HTML 5.1 and now <tfoot> must follow <tbody>.

Historically, the Calendar Core Widget used the <tfoot> element to display the calendar’s navigation links. But since the HTML 5.1 spec has changed, WordPress 5.4 moves the navigation links to a <nav> HTML element that comes right after the <table> element.

Moving navigation links outside of the <table> element offers better accessibility, with clearer distinction between elements. And a <nav> element is the semantically correct element for any navigation system, in any context.

Here’s a sample of the Calendar Widget’s former HTML markup:

<div id="calendar_wrap" class="calendar_wrap">
	<table id="wp-calendar">
		<caption>February 2020</caption>
		<thead>
			<tr>
				<!-- Day Names -->
			</tr>
		</thead>
		<tfoot>
			<tr>
				<td colspan="3" id="prev"><a href="https://example.com/2020/01/">« Jan</a></td>
				<td class="pad"> </td>
				<td colspan="3" id="next" class="pad"> </td>
			</tr>
		</tfoot>
		<tbody>
			<!-- Calendar Grid -->
		</tbody>
	</table>
</div>

And here’s a sample of the Calendar Widget’s new HTML markup:

<div id="calendar_wrap" class="calendar_wrap">
	<table id="wp-calendar">
		<caption>February 2020</caption>
		<thead>
			<tr>
				<!-- Day Names -->
			</tr>
		</thead>
		<tbody>
			<!-- Calendar Grid -->
		</tbody>
	</table>
	<nav aria-label="Previous and next months">
		<span id="prev"><a href="https://example.com/2020/01/">« Jan</a></span>
		<span class="pad"> </span>
		<span id="next" class="pad"> </span>
	</nav>
</div>

If you’re a site owner, and especially if you’re a Theme author, you are invited to test this change thoroughly. You may need to make some CSS adjustments.

For example, here are the visual differences for Twenty Twenty, the current Bundled Theme.

Before this change:

After this change:


For full details, see the related ticket on Trac: #39763

#5-4, #dev-notes, #widgets

Editor chat summary: 12 February 2020

This post summarizes the latest weekly Editor meeting, held in the #core-editor Slack channel, on Wednesday, February 12, 2020, 14:00 UTC. These meetings coordinate collaboration in the development evolution of the Gutenberg project. Moderated by @youknowriad.

WordPress 5.4 

Update from @jorgefilipecosta: Beta 1 was released 11 February, 2020 and it highlights a big number of Block Editor Features. From now on, all PR’s tagged with backport to wp core, will be included on the next WordPress release. We don’t have an automatic process for this, as a bug fix may be to a feature not part of WordPress 5.4. PR authors should try to be aware if the bug fix they are submitting is present in WordPress 5.4. If that’s the case the tag should be added, or when In doubt or if the user has no permissions to manage labels, please ping me in the PR so I can have a look. In some special cases or if we find the potential risk of the fix is high we may decide otherwise, but this would be an exception.

Gutenberg 7.5

Update from @youknowriad: Gutenberg 7.5 had a shorter lifecycle than regular Gutenberg releases. A one week release. This was needed to adapt as closely as possible to the WordPress release dates (beta 1). That doesn’t mean it had fewer features though. The changelog is really exciting and includes:

  • Social links blocks marked stable
  • Support for tiktok embeds
  • Inline text color support
  • Support adding featured images to Latest Posts block
  • and a lot more

The release will happen late on 12 February, 2020.

Weekly Priorities

WordPress 5.4 is still a big priority for us. I believe we’ll be working on bug fixes and any critical issues raised during the release cycle. Other than that, the priorities are listed on the monthly roadmap post.

Task Coordination

@mkaz  I have open questions around an approach for making Social Links extendable: PR 19888

@karmatosed Focusing on global styles, now about to do a few things:

  • Update sidebar designs for v1.
  • Explore beyond v1.
  • Spent some time auditing the block styles used and as a result about to create an issue to add some to v1 styling (specifically line height).
  • Working on some component focused iterations.
  • Continuing to work on triage as needed and whilst been a little in deep with 5.4 surfacing to keep that going.

Continuous props to @jorgefilipecosta @itsjonq and @nosolosw for being fearless global styles squad peeps.

@youknowriad

  • Working on the icons package, trying to complete the refactor but still some work ahead
  • Opened a PR to add more tips to the block inserter
  • Trying to help with G2
  • Focusing a bit on writing dev notes on the next days

@jorgefilipecosta  During the last week, I performed an audit to experimental APIs, triaged issues, reviewed PR’s and patches, submitted multiple bug fixes, updated packages in core, added/removed blocks from the core, checked the PR’s needing dev notes and proposed a structure for the notes, and continued involved with part of the global styles conversations and provided some feedback. For the next week, I will focus on writing some dev notes, submit some bug fixes, review PR’s, triage issues and PR’s to make sure we backport the PR’s to core and I will extend the edit-site module to support a sidebar extensibility mechanism like edit-post does.

@nosolosw  My main focus this week has been in consolidating the server-side data mechanism for global styles v1. It’s going to land in the next days under the FSE experimental flag PR 20047. Next, I’m starting work on making something useful with that data: theme integration & block styles, connect it to the UI controls PR that @itsjonq  put together, etc.

@itsjonq As others have mentioned, I’ve been focused on Global Styles. Coordinating with various folks, planning, thinking through things, and implementing the initial integration with FSE via the “Edit Site” page

@retrofox  Navigation Block

  • Merged the new design for sub menus (very significant)
  • Improve color handling: custom and colors by ID. light/dark styles as default.
  • Improve propagation data <Navigation /> and <NavigationLink />
  • Consolidate styles between front-end and editor-canvas
  • Fixing many visual issues
  • just in case and as usual, developing dashboard: https://github.com/WordPress/gutenberg/projects/31 (edited) 

@aduth I’ve been helping push for some final tasks for WordPress 5.4 / Gutenberg 7.5, notably: Fixing up some link editor workflow regressions, removing columns auto-adjusting behavior. There’s a bit more follow-up work to that. Also looking at some issues with polyfills needed for WordPress 5.4, and generally trying to focus on a few known bugs that were let slip.

@andraganescu

  • continued with the author block
  • did reviews and some small PRs
  • learning more on FSE
  • will pick up something from the Iterations on “Latest Posts” Block – version 2 Issues 20046  which I invite you all to check 

@mapk 

  • Digging into G2 more.
  • Working on Templates and Template Parts UX.
  • Taking a gander at Block Patterns UX as well.

@jeryj Added an `onFocus` handler for the LinkControl that will fetch the current input search suggestions (if there is an input value). This lets the suggestions list be fetched when people are editing an existing link.

  • Helping @getdave with smaller tasks on the massive Create new Page from within the Nav Block PR 19775
  • Various Navigation Block UX improvements in the last couple weeks

Open Floor

Resizeable Editor

@isabel_brison wants to highlight the resizable editor PR 19082 that was just merged. CSS transformations don’t work in two cases at the moment: for theme editor styles because they are loaded as inline styles and for CSS in JS styles. @youknowriad responded for the theme editor styles it’s important to support the resizing but said he believes the issue could be solved since we control that inline style; it’s included by the block editor itself and it already has some transforms support, so a way to rewrite it can definitely be found.

@jorgefilipecosta added  For theme editor styles because they are loaded as inline styles, I think as long as themes add the marks required the mechanism may work well. The API’s used to transform the media queries should also work for inline styles. Our code may need to be aware that the marks we used may be wrapped inside a class in editor styles.

@itsjonq added CSS-in-JS styles I took a look at the implementation. Since it’s working with document.styleSheets, we can perhaps adjust the logic to include CSS-in-JS generated StyleSheet instances to be included for enhancement. However, it’ll only affect styles upon trigger. Any dynamic styles added in between trigger phases won’t be enhanced (this applies to any dynamically generated styles though, not exclusive to CSS-in-JS).

@youknowriad replied the CSS in JS problem is good to raise but it still remains to be seen whether that’s a problem or not. I don’t expect block styles to use CSS in JS anytime soon and @jorgefilipecosta agreed saying he’s  not seeing how blocks would use css in js for the markup they produce. @itsjonq mentioned the CSS-in-JS implements may (and probably should) be limited to just wordpress/components, so in that case, it may be okay.

Easier PR Testing Methods

@paaljoachim asked for an easier way to test PRs before they get merged. @aduth has a site at http://gutenberg.run and developed on GitHub. He also reminds the team about answering in the Gutenberg forums @youknowriad agrees pointing out a lot of developers and users struggle and those on Core team probably have  the best answers for them. So if you need to take a break from PRs and issues, do take a look at the forums from time to time. More coordinated efforts will be organized on the forums especially after WP stable releases.

Global Styles and Full Site Editing (FSE)

@itsjonq highlighted work on Global Styles. The team started off by building the initial foundations for the system (huge props to @jorgefilipecosta + @nosolosw), which involve things at the PHP layer. Since Global Styles is still under development, it has been built so that it cannot be activated (unless you follow a series of steps). That way, it ensures regular Gutenberg as well as FSE does NOT get affected. The team is progressing to the stage where they are implementing things in the UI, specifically the Gutenberg Edit site editor. Still very early days! But it’s coming along.

Backported Bug Fixes

@aduth regarding the earlier comment from @jorgefilipecosta We don’t have an automatic process for that as a bug fix may be to a feature not part of WordPress 5.4 — are we expecting that the only bug fixes which will be backported must have been introduced as part of WordPress 5.4? Or just merely that it is “present in” (i.e. could we still include bug fixes for things already present in 5.3?) @youknowriad responded it applies to all bug fixes and to all features already in Core (not just the ones introduced and @aduth replied he’d like to try get Isssue 18416 fixed.

Integrating Hooks in Blocks

@markhowellsmead  asked if there are there any plans to integrate hooks to server-side rendered blocks (e.g. latest posts), so that their output can be modified by a Theme? @youknowriad said there are already hooks available render_block to alter the server-side rendering of any block. If you’re asking about specific hooks for specific blocks, that’s probably unlikely to happen unless there’s a generic use-case we can extract from it.

Trac Tickets and Release

@jorgefilipecosta  reminds everyone with in progress trac tickets to verify if they are assigned to 5.4 milestone and, in that case, try to bring them to the finish line, if needed pinging people for reviews. When we are releasing a beta/RC tickets with 5.4 milestones that are not bugs or blessed tasks are a blocker for the release so if possible verify if you have any tickets on this list some time before the WordPress releases, if there are tickets on this list, please try to remove them by changing the milestone, type (if it could be considered a bug fix), or committing/ asking a committer to review it and commit it.

What’s new in Gutenberg? (12 February)

This is the last release that is going to be fully included in WordPress 5.4, containing one week of updates from 45 contributors. The release cycle was temporarily shortened to align features with WordPress 5.4 Beta 1.

The Social Links block has been in the works since a few releases, but now it’s a stable (no longer experimental) block.

Adding a Social Links block.
Adding a Social Links block.

Rich text can now be coloured!

Adding inline colour to text.
Adding inline colour to text.

It is now also possible to display featured images in the latest post block.

Latest post with featured images.
Latest post with featured images.

7.5 🇹🇭

Features

  • Mark the Social Links block as a stable block 20134 19887 20074 20150 20101
  • Support adding featured images to Latest Posts block 17151
  • Add support for TikTok video Embeds 19345
  • Add inline text color support 16014
  • Add text color support to Columns block 20016

Enhancements

  • Add type and angle picking to the custom gradient component 19582
  • Add transform for button to buttons block 20063
  • Navigation block:
    • Implement new design for sub-menus 19681
    • Set inherit color to anchor elements 20038
    • Fix getting Navigation parent block 20032 20057
    • Set width in order to show caret 20075
    • Improve colors handling 20022
    • Rename background color CSS class 20018
  • Block Library: Avoid column width auto-adjustment when sibling width changes 19515 20169
  • A11y:
    • Incorporate settings in the edit state of the LinkControl component 20052
    • Announce all Notice components messages 15745
    • Button block: Remove title attribute 19735
    • Navigation block: Remove title attribute 19990
  • Image block: Keep existing caption if the stored one is empty 19641
  • Enhance the custom gradient picker UI 20099

New APIs

  • Allow third-party keyboard shortcuts registration in the keyboard shortcuts modal 19965
  • Stabilize the AnglePickerControl component 20118
  • Add .wp-env.json config file support to wordpress/env 20002
  • Blocks: Promote block variations to stable API 20068
  • Mark the gradients theme API as stable 20107

Experimental

  • Add ability to disable the block popover through __experimentalUIParts.hasPopover option 19922
  • Add the __experimentalEditorSkeleton component to the block-editor package 20050 20132

Bug Fixes

  • A11y: Show open button when the sidebar is closed and tabbing out of the content 19726
  • IE11 Compatibility: Add DOMRect polyfill 20110
  • Block Editor: Fix warning when rendering InnerBlocks 20082
  • Featured image appears cropped 20128
  • Fix predefined text colors used in the Group block on the frontend 20119
  • Use array form for contrast checkers. 20143
  • i18n: make experimentalUseColors labels translatable 20112
  • Multi select: remove inserter between selected blocks 20096
  • Remove alignment options from nested Button blocks 19824
  • URL: Conform to URL Living Standard definition of valid URL 19871
  • Select the correct media in the media modal when replacing existing media 20100
  • Avoid resizing the editor canvas when opening the publish panel 19843
  • Fix Media & Text block styling when media is set to show on the right 20125
  • Fix excerpt rendering in the Latest posts block 19669

Documentation

  • Docs: Contributor Guide update subpages 19939
  • Prettier: Update format-js to use default config, and update editor docs usage 20036
  • Target docs to manifest.json 15639
  • Update main project README 19743
  • Update the Getting Started Docs to use wp-env 20044
  • Typos and tweaks: 20055 20077 20025 20060 19470

Various

  • Block Editor: Update BEM syntax to CSS modifer guidelines 19738
  • Block Library: Standardize PHP function names used 20085 20039
  • Project Management Automation:
    • Log skipped tasks and retain wrapped task names. 20034
    • Support adding milestones for fork PRs. 20058
    • Avoid gracefully handling error 20009
    • Avoid milestone task for forks 20049
    • Call core setFailed with error message 20012
    • Check error object for parsed errors 20014
    • Guard against non-matching commits in addMilestone. 20147
    • Tolerate duplicate milestone 20011
    • Pull Request Automation: Avoid automation tasks for forked repository 20021
  • wordpress/env:
    • Fix GitHub source pattern 20131
    • Fix syntax error where spread operator could fail 20113
  • Move existing icons to the wordpress/icons package 20091 20072 19959 20094 20087
  • Ensure the default Prettier config is used with lint-js when needed 20071
  • Data: Log first-pass useSelect errors 20122
  • Compat: Social Links: Remove legacy renderers from packages 20098
  • Core Data: Mark the getEntityRecordNoResolver selector as experimental. 20053
  • Core Data: Remove unused __experimentalUseEntitySaving hook. 20148
  • Hide the navigation block behind feature flag 20133
  • Fix Intermitent e2e test failures 20065
  • Move the e2e tests to the right folders 20135
  • Switch social link icons to import svg parts from primitives 19877

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.5.0 6.491s 34.695ms
Gutenberg 7.4.0 6.413s 36.81ms
WordPress 5.3 6.331s 75.19ms

#core-editor, #editor, #gutenberg