What’s new in Gutenberg? (25 March)

This release is mostly focused on polish work for the Block UI redesign.

Screen Capture on 2020-03-16 at 15-49-00

It also includes an official API to register custom Block patterns from themes and plugins. The API is still a work-in-progress and might evolve before reaching WordPress Core.

        'title'   => __( 'Two buttons' ),
        'content' => "<!-- wp:buttons {\"align\":\"center\"} -->\n<div class=\"wp-block-buttons aligncenter\"><!-- wp:button {\"backgroundColor\":\"very-dark-gray\",\"borderRadius\":0} -->\n<div class=\"wp-block-button\"><a class=\"wp-block-button__link has-background has-very-dark-gray-background-color no-border-radius\">Button One</a></div>\n<!-- /wp:button -->\n\n<!-- wp:button {\"textColor\":\"very-dark-gray\",\"borderRadius\":0,\"className\":\"is-style-outline\"} -->\n<div class=\"wp-block-button is-style-outline\"><a class=\"wp-block-button__link has-text-color has-very-dark-gray-color no-border-radius\">Button Two</a></div>\n<!-- /wp:button --></div>\n<!-- /wp:buttons -->",



  • Add visible labels to BlockPatternPicker pattern selection buttons 19789
  • Adds always on display of media URL 19504
  • Adds current menu class to navigation block 20076
  • Block: Outline when interacting with Toolbar Block Type/Movers 20938
  • Create block: Improve how prompts and values provided are handled 20756
  • Expand create block options and add readme.txt template 20694
  • Patterns: Make adding patterns easier 20854
  • Polish a few icons 20980
  • Polish date-picker component 20824
  • Improve permalink editing 12009
  • Nicer block footprint for social links 20978
  • Show inserter only when block selected for nesting contexts 20753
  • URL: Use test data from web-platform-tests for isURL spec conformance 20537
  • Adds multi-select to categories on Latest Posts 20781
  • Add basic nav block example for inserter and styles previews 21011

Bug Fixes

  • Allow media library in gallery mode to be reset 20675
  • Autocomplete: Add support for results with long titles 20962
  • Compat: Conditionally filter editor settings for image dimensions 20939
  • Compat: Use core-js-url-browser for URL polyfill 20225
  • Data: Migrate post editor persistence with fullscreenMode false 21082
  • Edit Post: Make sidebar header focusable for button focus normalization 21031
  • Fix auto-hiding appender regression 20780
  • Fix fullscreen mode device preview 21010
  • Fix link control search results spacing. 21003
  • Fix snackbar container block portion of UI while present 21000
  • Make the inner button block not allowed as a reusable block or editable as HTML 20948
  • URL: Fix getQueryString incorrect handling of hash fragment 20738
  • Update social links block to output a custom class on each individual link 20998
  • Update the inserter’s block preview to use the AutoHeightPreview 20817
  • Latest Posts:
    • Fix link for read more markup 20917
    • Fixes the categories selector crash when category does not exist 20960
  • Fix input rules 20964
  • Trim input value in navigation search input field 19832
  • Fix mobile header 20946
  • Fix visually hidden classnames 20649
  • Fix/screen reader text 20607
  • Fix SelectControl example code synax highlight 19803

New APIs

  • Add initial API to register patterns from themes and plugins 21074
  • Convert __experimentalCreateInterpolateElement to a stable API 20699


  • Site Editor:
    • Add Fullscreen mode 20691
    • Add fullscreen close button 20989
    • Add more menu and fullscreen toggle 21006
    • Style resets for top level page 20886
    • Get current template part correctly for auto drafts 20438
    • Add template preview to the edit site template switcher 20958
    • Add things required to load custom blocks to Site Editor page 20549
    • Avoid page templates overwriting page title 20865
  • Lighter block DOM:
  • Navigation Block:
    • Fix dynamic rendering recursive function name typo 21078
    • Avoid hiding submenu when adding a link 21035
    • Fix toolbar overlap on navigation links 21033
  • PlainText v2 21076
    • Editable Component 18361


  • Add ESNext example for unregisterBlockType 20784
  • Docs/SlotFills: Small update for consistency 20767
  • Correct 2nd param of useViewportMatch() usage 20911
  • Include npm run dev guidance in “Getting Started” 21015
  • Document default login credentials and wp-env run command 20678
  • Fixes docblock for useViewportMatch 20919
  • Lowercase visual editor and code editor to match block editor and classic editor 20968
  • Update README.md 20913
  • Add Custom Block Editor to TOC and Manifest 20749
  • Add tutorial link to Table of Contents for Custom Block Editor 20750

Code Quality

  • Block Editor: Use useResizeObserver in place of direct react-resize-aware dependency 20889
  • E2E Test Utils: Improve durability of embedding matcher 20811
  • Framework: Migrate/remove temporary compatibility script initialization 19178
  • Framework: Use WHATWG URL in place of legacy url module 19823
  • Nav Block: Remove ‘frontend’ from style comments 21034
  • Project Management Automation: Add TypeScript type-checking 20850
  • Refactor the inserter menu component and split into multiple smaller components 20880
  • Remove iframe from content elements 20976
  • Update Search/RSS block render method 20977


  • Update glossary 20934
  • Improve performance testing 20802
  • Edit Post: Register block patterns as separate plugin 20871
  • Accessibility: updated headings to reflect semantic relationship between html tag and it’s content. 16444
  • Add Prettier shared config package 20026
  • Add default styles to the TabPanel component 20872
  • Add isFileURL method and use it on all native media upload checks. 20985
  • Add menus endpoints. 20292
  • Block Patterns: Update text-two-columns.json 20890
  • Block Styles: Remove the block margin in the style selector 19983
  • Block patterns: improve success notice 21005
  • Blocks: Allow the Default Style selector to be hidden. 20620
  • E2E Tests: Mock Embed response for InnerBlocks locking test 20481
  • ESLint Plugin: Relax prefer-const for destructuring assignment 20737
  • Gallery: Update UI of controls 20776
  • Improves RTL style conversion 20503
  • Minor change to switch Help link target to _blank, add rels 20800
  • Mobile: Add accessibility label to Block List Footer 20633
  • Moves category multi select from LatestPosts to QueryControls 20832
  • Paste: replace iframes with url 20983
  • Polish poster image button arrangement. 20754
  • Preview Button: Remove the separator and border, and reduce the size of the icon. 20683
  • RangeControl: Improve disabled rendering and interactions 20723
  • Reduce gap between block library and preview 20777
  • Remove aria-expanded from close button in Publish panel 20993
  • Remove feature flag for mobile page templates 20718
  • Remove inaccurate message from image block 20909
  • Removed the textarea width restriction for the Shortcode block 20624
  • Revert “Framework: Travis: Avoid skipping Puppeteer download” 20828
  • Show errors in the media replace control 19244
  • Styles Panel: Don’t force it to be closed by default. 20617
  • Update Navigation Menu Item icon 20763
  • Update page template picker after design review 20883
  • Latest Posts: Testing larger margins 20563
  • Add codeowners for env package 20667
  • Scripts: Update all webpack related dependencies 20916
  • Dependencies webpack plugin: Let the output file be specified when output is combined 20844

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.8 5193ms 23.05ms
Gutenberg 7.7 5134ms 22.79ms
WordPress 5.3 9512ms 25.83ms

#core-editor, #editor, #gutenberg

Showing Online WordCamps in the Events Widget

TLDR: Should online WordCamps be added to the Events widget? If so, who should they be shown to?


Many WordCamps are transitioning from in-person events to online events, due to COVID-19.

At the moment, those events don’t show up in the News & Events widget on the dashboard, because they don’t have a physical location. The widget was originally designed to show the user local events, because cultivating local, in-person bonds is an essential element of our community’s success.

Online events aren’t being intentionally kept out of the widget; it’s just an unforeseen side-effect of the temporary shift to online events. Online meetup events still appear in the widget, because in the absence of an explicit event location, the Meetup.com API falls back to the location of the group.


  1. Should online WordCamps show up in the widget?
  2. If so, who should they be shown to? Here are a few potential criteria:
    • The same people who would have seen the in-person event. i.e., anyone within a 400km radius of the venue.
    • Everyone within the same country. Would this apply equally to countries that host a small number of camps, and those that host a large number? Would it apply equally to countries that often see people from neighboring countries traveling to attend the event, and to countries where that is not common?
    • Everyone within an increased radius, e.g., 600km. If so, what would be the best distance?
    • Everyone within the same timezone, plus-or-minus a few hours.
    • Everyone who speaks the same language — or locale? — as the host city.
    • A combination of the above? Some other criteria entirely?
  3. Should the timezone and/or language of the event be displayed in the dashboard?


#events-news-widget, #meetups, #online-events, #wordcamps

WordPress 5.4 Field Guide

WordPress 5.4 is shaping up to be the best WordPress 2020 has seen!

As a user, you’ll see new blocks and enhancements in the block editor, new embeds, and improvements in the WordPress Admin experience.

As a developer, you’ll see 122 enhancements and feature requests, 210 bug fixes, and more! Of course, all those improvements mean code changes, which could in turn require you to make updates to your site, plugin, or theme.

So take a look through this Field Guide, and see what’s relevant to you and your users, among the many improvements coming in 5.4…


On the 14 updates related to Accessibility in 5.4, you’ll want to particularly note changes to the WordPress Admin Bar, to the calendar and recent comments widgets, on the Menu screen, and bugs reported by the WPCampus accessibility report.

Block Editor

The block editor has continued its rapid iteration since WordPress 5.0. Now it has Gutenberg version 7.5 bundled with WordPress 5.4; that’s ten releases all bundled into WordPress 5.4 (versions  and 7.5)! Bug fixes and performance improvements from Gutenberg versions 7.6 will also be part of 5.4.

The WordPress 5.4 Beta 1 post highlights a lot of new features and improvements across these releases, though you’ll also want to note the impressive achievement of 14% loading-time reduction and 51% time-to-type reduction (for a particularly long post of ~36,000 words, ~1,000 blocks) since WordPress 5.3.

Below you’ll find details on two new blocks, button component updates, block collections, default fullscreen mode for new installs/devices, custom keyboard shortcuts, general block editor API updates, new block variations API, a new gradient theme API, markup and style-related changes, and a new @wordpress/create-block package for block scaffolding.


On the 14 updates of the Customizer component, WordPress 5.4 improves accessibility of focused elements as a follow-up to WordPress 5.3 Admin CSS changes, adds documentation of existing Customizer functions and hooks, removes apple-touch-icon-precomposed deprecated meta tags, and improves Menu items selection logic.

Please note that some unused Customizer classes are now formally deprecated:


On the 5 updates in the Menus component, WordPress 5.4 improves keyboard accessibility of the Menu items selection tab panel and streamlines the user interface.

If your plugins add custom fields to menu items, you’ll want to update your code to use the new wp_nav_menu_item_custom_fields hook:


On the 15 updates in the Privacy component, you will want to specifically note:

  • Personal Data Export now includes Session Tokens, Community Events Location and Custom User Meta.
  • Personal Data Exports now include a JSON file and a Table of Contents
  • New filters for the headers of all Privacy-related emails
  • The privacy tables are improved for a cleaner interface
  • wp_get_user_request_data() function was replaced with wp_get_user_request() for better clarity

All those changes are in this dev note:


On the 22 updates related to the REST API, WordPress 5.4 now supports “OR” taxonomy relation parameter in Post Controller, adds selective link embedding and introduces some changes in the WP_REST_Server method. Read below for more details on these updates:


On the 3 updates to the Shortcodes component, WordPress 5.4 introduces documentation improvements and a new function: apply_shortcodes. This function is an alias of do_shortcode, which is still supported.


On the 9 updates to the Widgets component, WordPress 5.4 introduces accessibility and user interface enhancements on the Widgets Admin screen and changes in the Recent Comments and Calendar Widgets HTML markup.

Other Developer Updates

There are even more goodies in 5.4, like the new wp-env (a zero config tool for painless local WordPress environments), enhancements to favicon handling, better information about errors in wp_login_failed, a new site ID in multisite’s newblog_notify_siteadmin filter, a new TikTok video embed and removal of the CollegeHumor embed, storing the original URL of media attachments in _source_url post meta, improved accessibility by loading the Admin Bar with wp_body_open, avoiding duplicate IDs in the Recent Comments widget, a new parameter in the lostpassword_post action in retrieve_password(), theme headers supporting “Requires at least” and “Requires PHP” declarations, and the delete_posts capability won’t trigger PHP notices for custom post types. Read through the dev notes below to see details on all these changes coming in 5.4.

But Wait, There is More!

Over 198 bugs, 121 enhancements and feature requests, and 8 blessed tasks have been marked as fixed in WordPress 5.4. Some additional ones to highlight include:

  • Bootstrap/Load: Enhancement to favicon handling (#47398)
  • Bundled Theme: Twenty Twenty: Add social icon for WhatsApp (#49098)
  • Comments: Add “In response to …” before threaded comments in comment feed (#43429)
  • Comments: Add “in reply to” in comment moderation email notification (#43805)
  • Embeds: Embed support has been added for TikTok (#49083) (Gutenberg#19345)
  • Embeds: Removal of CollegeHumor embed as the service doesn’t exists anymore (#48696) (Gutenberg#18591)
  • Login and Registration: Clearer information about errors in wp_login_failed (#49007)
  • Login and Registration: new parameter passed into the lostpassword_post action in retrieve_password() (#38334)
  • Networks and Sites: Site ID has been added to the newblog_notify_siteadmin filter for multisite installs (#48554)
  • Networks and Sites: switch_to_blog() and restore_current_blog() reuse switch_blog action (#49265)
  • Media: store the original URL of the attachment in the _source_url post meta value (#48164)
  • Menus: Make tabs panels more accessible for keyboard users (#49211)
  • Posts, Post Types: Use delete_posts without triggering PHP notices in every post type (#30991)
  • Post Thumbnails: Make sure get_post_thumbnail_id() returns an integer, to match the documented return value (#40096)
  • REST API: Expose all theme supports and changed permissions in /themes endpoint (#49037)
  • Site Health: Theme headers support “Requires at least” and “Requires PHP” declarations (#44592)
  • Toolbar: The Admin Bar is now loaded with wp_body_open when available (#47053)
  • Widgets: Avoid duplicate IDs in Recent Comments (#46747)

Please, test your code. Fixing issues helps you and helps millions of WordPress sites.

Props to @jeffpaul and @marybaum for contributing to this guide.

#5-4, #field-guide

General Block Editor API Updates

Meta attribute sources deprecated in 5.4

WordPress 5.4 deprecates meta attribute sources.

Your existing code that uses these attributes should still work, but there’s a new way to get where you want to go.

Instead of meta attributes, use EntityProvider and related hooks APIs. EntityProvider and related hooks APIs provide a more flexible and powerful way to build blocks that source data from a variety of properties of WordPress entities and data.

Here’s how your block’s objects can permit reading and writing to the meta of a post:

const [meta, setMeta] = useEntityProp('postType', 'post', 'meta')

Shortcode transforms: Support isMatch predicate

To bring shortcodes in line with other types of block transformations, you can add an optional isMatch function to see if a given shortcode should transform into a specific block.

For instance, this hypothetical Antarctica Weather block only cares about [weather] shortcodes for Antarctica:

transforms: {
    from: [
            type: 'shortcode',
            tag: 'weather',
            isMatch( { named: { latitude } } ) {
                return parseInt( latitude, 10 ) < -70;
            attributes: {
                latitude: {
                    type: 'number',
                    shortcode: ( { named: { latitude } } ) =>
                        parseInt( latitude, 10 ),
                longitude: {
                    type: 'number',
                    shortcode: ( { named: { longitude } } ) =>
                        parseInt( longitude, 10 ),

If isMatch returns false, the shortcode won’t become an Antarctica Weather block. At that point, another block type can pick it up (presumably, one that matches the [weather] shortcode), or it can stay a shortcode and get encapsulated in a Shortcode block.

New AsyncModeProvider API

Because nobody wants laggy typing in the Editor, the BlockEditor uses an Async Rendering Mode: The selected block gets rerendered synchronously on each change—while the unselected blocks only refresh when the browser goes idle (i.e., while it’s not actively doing some task).

That behavior comes courtesy of the Async Mode, implemented in the wordpress/data package.

In WordPress 5.4, you can use that same sort of asynchronous behavior to speed things up in your own React state trees—as long as they rely on the data module.

That’s because version 5.4 puts the AsyncModeProvider component where you can find it and use it — or, conversely, not use it, since you can also use it to opt out of the block async rendering mode.

import { AsyncModeProvider } from '@wordpress/data';
const MyComponent = () => {
  return (
        The following component updates synchronously on data store changes
        <MySyncComponent />
        <AsyncModeProvider value={ true }>
            The following component updates asynchronously on data store changes
            <MyAsyncComponent />

For more about the AsyncMode, you can check this blog post.

A custom media upload handler in a block editor. In a SETTING!

Did you know? You can use the wordpress/block-editor package by itself, to add block-editor pages just about anywhere. Use it for custom WPAdmin pages or even in a completely WordPress-agnostic context.

Here’s an example from the Gutenberg Playground. In a situation like this, WordPress 5.4 lets you add a custom media-upload handler to the block editor—as a setting! (One of your users probably wants this right now.)

import { BlockEditorProvider } from '@wordpress/block-editor';

 * Media Upload Handler
 * @param   {Object}   $0                   Parameters object passed to the function.
 * @param   {?Object}  $0.additionalData    Additional data to include in the request.
 * @param   {string}   $0.allowedTypes      Array with the types of media that can be uploaded, if unset all types are allowed.
 * @param   {Array}    $0.filesList         List of files.
 * @param   {?number}  $0.maxUploadFileSize Maximum upload size in bytes allowed for the site.
 * @param   {Function} $0.onError           Function called when an error happens.
 * @param   {Function} $0.onFileChange      Function called each time a file or a temporary representation of the file is available.
const myMediaUploadHandler = ( settings ) => {
   const mediaObject = {
      id, alt, caption, title, url,


const MyCustomEditor = () => {
  return (
        <BlockEditorProvider settings={ { mediaUpload: myMediaUploadHandler  } }>
            <MyEditorLayout />

Now, realize this: if you leave the mediaUpload handler out of your BlockEditor instance, your editor won’t support media upload at all. Or, it might not let the current user upload media with their current permissions.

You can also give Media Blocks access to this setting in their edit functions, so they can support uploads.

const MyBlockEdit = () => {
   const mediaUpload = useSelect( ( select ) => {
      return select( 'core/block-editor' ).getSettings().mediaUpload;
   }, [] );

   return (
           { !! mediaUpload && <MyMediaUploadComponent onUpload={ mediaUpload } /> }

Easier drag-and-drop

Do you get complaints about drag-and-drop being more like swing-and-miss? In WordPress 5.4, you can listen to sweet, sweet silence.

That’s because the positioning classes that rendered in the DropZone component (is-close-to-topis-close-to-bottomis-close-to-left and is-close-to-right) are GONE.

In fact, the drop zone is gone. So users have a much bigger target to grab in the blocks they want to move. Easier grab, easier drag, happier users. And you’re the hero.

And with the exit of the drop zone, the editor.BlockDropZone component filter is also gone. That filter was originally supposed to filter media uploads that happened by drag-and-drop— but it didn’t seem to be doing the job well.

If you’d been using that filter, and its removal is a problem, please leave a comment on this note. If there’s enough demand, it’s possible a filter like it, focused on a broader media-upload use case, could emerge from the discussion.

RichText: don’t set focus when applying format

When you’re formatting text in a rich-text instance, does it annoy you to see the focus go back automatically to the editable element? Do your users complain about that behavior?

Well, get happy! In support of more complex UI, to give your users better control of rich-text instances, (e.g. a color control: who wants to have to click back into the color UI for every color change?) the focus will stay where you (or your users) are working until all the color changes, or whatever, are DONE.

Of course, that means that if you do want to keep setting the focus back, say, after a button click, you’ll have to actively make that happen when you’re registering the format type.

You’ll want to do that with the new onFocus function for the edit component.

For example, here’s how that works with the bold format button: https://github.com/WordPress/gutenberg/blob/c5eb9626dc1c73ad9bc543a5d171e9ab4a840996/packages/format-library/src/bold/index.js#L21-L53

New Guide component

A new Guide component was added to the @wordpress/components package (wp.components.Guide). Guide allows developers to easily create a step-by-step guide to display to users. The block editor uses Guide to implement a new welcome modal which appears on first launch.

Guide is a React component that renders a user guide in a modal. The guide consists of several GuidePage components which the user can step through one by one. The guide is finished when the modal is closed or when the user clicks Finish on the last page of the guide.

function MyTutorial() {
    const [ isOpen, setIsOpen ] = useState( true );

    if ( ! isOpen ) {
        return null;

    <Guide onFinish={ () => setIsOpen( false ) }>
            <p>Welcome to the ACME Store! Select a category to begin browsing our wares.</p>
            <p>When you find something you love, click <i>Add to Cart</i> to add the product to your shopping cart.</p>

Deprecation of wordpress/nux

The @wordpress/nux package (wp.nux) has been deprecated along with the DotTip component that it contained. Importing the package will display a warning in the browser console. It is recommended that plugins using wp.nux and DotTip migrate to Guide instead.

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

New Blocks in WordPress 5.4

Social Icons Block

This new block lets users link to social media and other popular websites by using those sites’ logos. Initially called Social Links, Social Icons were an experimental feature in Gutenberg 6.5 but held out of WordPress 5.3. Since then, the Block Variations API has progressed to the point that Social Icons in Gutenberg 7.5 are much simpler and more stable – and ready for merge in WordPress 5.4.

This reimplementation is a breaking change in the way Social Icons are saved (see details). Only sites that have run the Gutenberg plugin since September are potentially concerned. 

In WordPress 5.4, the core block editor will not recognize any Social Icons blocks built before Gutenberg 7.5.

There are two ways to deal with this:

  • (Recommended method) Manually migrate any content with old Social Icons. Here’s how: load a post in the block editor (Gutenberg 7.5 or higher) and save it. The block editor will automatically update its contents. 
  • Keep the Gutenberg plugin installed after upgrading to WordPress 5.4. The plugin will give you manual backwards compatibility for the old Social Icons.

Buttons Block

This new block is a collection of buttons, because authors often need to use several at a time (for instance: download and read more buttons).

The buttons block shows each button as an individual button-block child of the Buttons block. You won’t be able to insert a button block outside Buttons, but your existing button blocks will work the way they always have.

In case you were using the button block as part of a template or a system that automatically inserted a button block, you’ll want to use the Buttons block with a nested button instead.

Plus, here’s some good news: you won’t need to migrate your existing button blocks. They’ll just work — again, as they always have.

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

Feature Plugin Proposal: WP Consent API

As part of the core-privacy team’s roadmap the team has started development on a Consent API as a feature plugin.

We welcome all thoughts on this proposal, which you are welcome to leave as comments on this post, or share with us directly in the #core-privacy channel on Making WordPress Slack. We host weekly office hours on Wednesdays at 19:00 UTC, see the meetings page for times in your timezone.


A standard way for WordPress core, plugins, and themes to obtain consent from users should be established to provide a consistent and stable experience for administrators, developers, and users of all kinds.

Currently it is possible for a consent management plugin to block third party services like Facebook, Google Maps, Twitter, if a user does not give consent. But if a WordPress plugin places a PHP cookie, a consent management plugin cannot prevent this.                                         

There are also WordPress plugins that integrate tracking code on the client side in javascript files that, when blocked by a consent management plugin, break the site. Or, if such a plugin’s javascript is minified, causing the URL to be unrecognizable, it won’t get detected by an automatic blocking script.

Lastly, the blocking approach requires a list of all types of URL’s that place cookies or use other means of tracking. A generic API which plugins adhere to can greatly help a webmaster in getting a site compliant.

Does usage of this API prevent third party services from tracking user data?

Primarily this API is aimed at helping to achieve a compliant use of cookies or other means of tracking by WordPress websites. If a plugin or custom code triggers for example Facebook, usage of this API will be of help to ensure consent. If a user manually embeds a facebook iframe, a cookie blocker is needed that initially disables the iframe and or scripts.

Third-party scripts have to be blocked by a blocking functionality in a consent management plugin. To do this in core would be too intrusive, and is also not applicable to all users: only users with visitors from opt in regions such as the European Union require such a feature. Such a feature also has a risk of breaking things. Additionally, blocking these and showing a nice placeholder, requires even more sophisticated code, all of which should not be part of WordPress core, for the same reasons.

That said, the consent API can be used to decide if an iframe or script should be blocked.

How does it work?

There are two indicators that together tell if consent is given for a certain consent category, e.g. “marketing”:

  1. The region based consent_type, which can be optin, opt out, or other possible consent_types;
  2. The visitor’s choice: not set, allow or deny.

The consent_type is a function that wraps a filter, wp_get_consent_type. If there’s no consent management plugin to set it, it will return false. This will cause all consent categories to return true, allowing cookies and other types of tracking for all categories.

If optin is set using this filter, a category will only return true if the value of the visitor’s choice is allow.

If the region based consent_type is opt out, it will return true if the visitor’s choice is not set or is allow.

Clientside, a consent management plugin can dynamically manipulate the consent type, and set the applicable categories.

A plugin can use a hook to listen for changes, or check the value of a given category.

Categories, and most other stuff can be extended with a filter.

Existing integrations

  • Cookiebot
  • Complianz
  • Example plugin. This plugin basically consists of a shortcode, with a div that shows a tracking or not tracking message. No actual data tracking 🙂

Demo site

Plugins used to set this up:

Technical Scope

The feature plugin should at least handle the following functionality:

  • PHP functions to set the consent level and consent type.
  • PHP functions to retrieve the consent level and consent type.
  • Javascript functions to set the consent level.
  • Javascript hook that fires when a consent level is set.
  • Javascript functions to retrieve the consent level.

Introducing the Feature Plugin

What’s next?

Once the plugin is confirmed as a feature plugin, the next steps would be:

  • To increase the number of users of the feature plugin.
  • To add other interested privacy team members and core developers as contributors of the plugin.
  • To have additional Third-Party consent management plugins to adopt the API.
  • To iterate on the feature plugin development.
  • To audit some specific aspects of the feature plugin:
    • security
    • coding-standards and documentation
  • To create a Trac ticket to handle a potential future merge proposal – if the feature plugin deserves it.

Post written by @rogierlankhorst / @paapst and reviewed by @garrett-eclipse / @carike

#consent-api, #core-privacy, #feature-plugins, #privacy, #privacy-roadmap

Dev Chat Agenda for April 1, 2020

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


WordPress 5.4 “Adderley” was released yesterday, March 31, 2020!

Highlighted blog posts

Components Check-in

  • News from components
  • Components that need help
  • Cross-component collaboration

Open Floor

Got something to propose for the agenda, or a specific item relevant to our standard list above?

Please leave a comment, and say whether or not you’ll be in the chat, so the group can either give you the floor or bring up your topic for you, accordingly.

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

#5-4, #agenda, #devchat

New hooks let you add custom fields to menu items

WordPress 5.4 gives you two new actions that let you add custom fields to menu items—in the Menu screen and in the Customizer’s menu editor.

Menus admin screen

The new wp_nav_menu_item_custom_fields action fires just before the move buttons of a nav menu item in the menu editor.

You can assign five parameters:

  • $item_id: the menu item ID (integer)
  • $item: the menu item data object (object)
  • $depth: the depth of the menu item (integer)
  • $args: an object of menu item arguments (object)
  • $id: the Navigation Menu ID (integer)

Here’s a simple example:

function wporg_my_custom_field() {
	esc_html_e( 'Howdy! WordPress 5.4 is coming!', 'wporg' );
add_action( 'wp_nav_menu_item_custom_fields', 'wporg_my_custom_field' );

And here’s the result (highlighted in green dashed border):

The Customizer menu editor

The new wp_nav_menu_item_custom_fields_customize_template action fires at the end of the form-fields template for navigation menu items in the customizer.

The hook lets you render extra fields there and manage them with JavaScript.

This brings parity with the wp_nav_menu_item_custom_fields action.

Compatibility with existing custom walkers

These new action hooks can replace the custom walkers you’ve been using for your nav-menu fields. You’ll want to check your existing code to see where that replacement makes sense.

For more, see the related Trac ticket #47056.

For more help managing duplication in custom fields, see Trac ticket #49500. In plugins, you can avoid the issue entirely with a check for the WordPress version.

#5-4, #dev-notes, #menu-customizer, #menus

Markup and style-related changes

WordPress 5.4 makes several DOM structure changes on the block editor. Ideally, your code doesn’t depend on WordPress Core class names or a specific DOM, since class names and the DOM structure are not part of the WordPress public API.

Remove legacy “editor-” class name compatibility

WordPress 5.2 updated the CSS class names of a lot of the components in the block editor, changing editor- prefixes on those class names to block-editor-. Where the old class names still existed, largely in component references, the conventional wisdom urged developers to avoid those references or update them accordingly.

In WordPress 5.4, these old editor--prefixed class names are gone from components in the block-editor scripts. If you’re still referencing the editor-prefixed CSS class name of a component, you’ll need to update to the block-editor- equivalent.

Div with class edit-post-layout__content removed

The `edit-post-layout__content` div is gone from the DOM of the block editor. Check your custom styles and plugin files to make sure you’re not targeting it fir styling.

Blocks and rich text components lose redundant wrappers

Blocks and RichText have been refactored to simplify and lighten the React and DOM tree.

The key to this refactor: moving controls out of the elements and into adjacent popovers, which made four div wrappers redundant—so now they’re gone.

The result: significant performance improvement—and the editor-content DOM looks a lot more like the front end. So styling blocks is now a lot easier for both block and theme authors. Eventually, the plan is to let blocks render the very same tree in the editor as on the front end.

Here’s how those changes have affected the block-editor DOM:

The block-editor-rich-text class is now part of the editable element, unless you’re still using the wrapperClasses prop (which you should really stop using). If you really need a wrapper around the editable element, you’re better off creating your own.

The data-block attribute, containing the block ID, has relocated to the outer block wrapper element. The block-editor-block-list__block-edit class is gone completely; so is the div element. Selectors like .wp-block > .block-editor-block-list__block-edit > [data-block] won’t work anymore. Use .wp-block or just the [data-type] attribute instead.

Simpler block margins

 17877 changes the way the block editor lays out blocks. Before now, every block came with built-in padding, left and right, and negative margins to compensate.

Well, in a bid to radically simplify the CSS you need to style blocks, to develop blocks, to build themes and style the editor in your themes, the built-in padding and negative margins are refactored out of existence—they’re GONE.

Now, if your current block or editor styles have been compensating for those previous margins/paddings, they might look a little off in version 5.4. If so, try getting rid of the styles you wrote to compensate.

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

Fullscreen mode enabled by default in the editor

Starting with WordPress 5.4, the editor behaves differently the first time you open the editor in a new installation or on a new device—or any other time WordPress resets the user preferences.

Now the editor opens in fullscreen mode by default. Note that for now, that’s a local setting, which is why it’s going to reset when your preferences do, including incognito mode. Future releases will store the setting in the WordPress database.

Want to turn it off? It’s simple—just use the pulldown in the editor’s menu.

You can also control the editor’s mode programmatically with the data module. A quick reminder: the code below is JavaScript, not PHP.

const isFullscreenMode = wp.data.select( 'core/edit-post' ).isFeatureActive( 'fullscreenMode' );

if ( isFullscreenMode ) {
    wp.data.dispatch( 'core/edit-post' ).toggleFeature( 'fullscreenMode' );

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