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

New: the block variations API

Just as you can declare a block’s style variations when you register a block, a block type can define block variations the user can pick from. The difference is that, beyond changing the look, this field offers a way to apply initial custom attributes and inner blocks at the point of insertion.

By default, all the variations will show up in the Inserter along with the regular block-type item. But you can set the isDefault flag for any of the listed variations—and in the process, you’ll override the regular block type in the Inserter.

variations: [
        name: 'wordpress',
        isDefault: true,
        title: __( 'WordPress' ),
        description: __( 'Code is poetry!' ),
        icon: WordPressIcon,
        attributes: { service: 'wordpress' },
        name: 'google',
        title: __( 'Google' ),
        icon: GoogleIcon,
        attributes: { service: 'google' },
        name: 'twitter',
        title: __( 'Twitter' ),
        icon: TwitterIcon,
        attributes: { service: 'twitter' },

An object describing a variation defined for the block type can contain these fields:

  • name (type string) – The unique and machine-readable name.
  • title (type string) – A human-readable variation title.
  • description (optional, type string) – A detailed variation description.
  • icon (optional, type String | Object) – An icon helping to visualize the variation. It can have the same shape as the block type.
  • isDefault (optional, type boolean) – Indicates whether the current variation is the default one. Defaults to false.
  • attributes (optional, type Object) – Values that override block attributes.
  • innerBlocks (optional, type Array[]) – Initial configuration of nested blocks.
  • example (optional, type Object) – Example provides structured data for the block preview. You can set to undefined to disable the preview shown for the block type.
  • scope (optional, type String[]) – the list of scopes where the variation is applicable. When not provided, it assumes all available scopes. Available options: block, inserter.

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

Editor Chat Agenda: 1 April, 2020

Note taker and facilitator: @pbrocks

This is the agenda for the weekly editor chat scheduled for 2020-04-01 14:00 UTC.

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

  • WordPress 5.4 released
  • Planning 5.4.1
  • Monthly Plan & Weekly Priorities
  • Task Coordination
  • Open Floor

If you have anything to share for the Task Coordination section, please leave it as a comment on this post.

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


Updating the Coding standards for modern PHP

Until May last year, contributions to WordPress Core were bound to PHP 5.2 syntax and most plugins and themes stuck to the PHP 5.2 minimum requirement as well.

However, with the change to PHP 5.6 as the minimum PHP version for WordPress Core, new PHP features have become available for use in WP Core and with the outlook of a minimum version of PHP 7.x in the (near) future, even more interesting language features will soon become available for use in WordPress Core, plugins and themes.

With that in mind, we’d like to define coding standards for a number of these constructs and propose to implement automated checking for these in the WordPress Coding Standards tooling in the near future.

While it may still be a while before some of these features will actually be adopted for use in WordPress Core, defining the coding standards in advance will allow for a consistent code base when they do get adopted and will allow for plugins and themes, which are not necessarily bound to the PHP 5.6 minimum, to safeguard their code consistency when they start using more modern PHP already.

To be honest, none of these proposals are terribly exciting and some may not even seem worth mentioning. Most follow either prior art in WordPress Core or industry standards for the same, but in the spirit of openness, we’d like to verify our take on these before implementing them.

Continue reading

#modernizewp, #codingstandards, #php, #wpcs

Editor chat Summary: 25 March, 2020

This post summarizes the weekly editor chat meeting agenda here. Held on Wednesday, 25th March 2020 held in Slack. Moderated by @get_dave.

WordPress 5.4 Upcoming Release

  • WP 5.4 RC 4 was released yesterday (Wednesday, 24th March)
  • WP 5.4 RC 4 adds the Editor packages (Trac: 49688)
    • The editor PR’s that were cherry-picked into 5.4 can be checked on PR: 21083
    • Remaining issues can be checked and triaged on this board

Monthly Plan & Weekly Priorities

  • Revisit March master plan
  • @youknowriad Progress is good
    • Global Styles: We’ve added CSS vars to multiple blocks and more coming
    • Full Site Editing (FSE): still some challenges (Context API) and we’re improving the Edit Site screen at the same time
    • Patterns: Thanks to @nrqsnchz we have a dozen patterns on the works and the UI is being iterated on
  • Check out some of the Overview issues here for a better outlook

Task Coordination.

  • @nosolosw will work on global styles for edit-siteand reviewing related PRs
  • @youknowriad worked on CSS var support for multiple blocks, Edit Site improvements and PR reviews
  • @isabel_brison worked on Navigation block and Triaging the a11y audit board
  • @Johnston Philip wants to help review things
  • @Jon Q has been working on adding more style controls to Blocks.
  • @karmatosed has been focusing on navigation, global styles and triage
  • @Bart Kalisz has been reviewing some Good first review PRs
  • @get_dave worked with @andraganescu to allow Navigation Blocks to be created from existing WP Menus: PR 18869
  • @michael-arestad works on multi-entity saving and navigation methods within the editor
  • @Brent Swisher will continue working on storybook stories

Open floor

  • @soean asked that we announce WPBlockTalk – a free, online event for all things block editor happening on April 2nd
  • @paaljoachim asked about a progress with the Reusable Block feature. Progress can be monitored here.
  • @paaljoachim also raised awareness on PR 18718 about refactoring cover background controls.
  • @paaljoachim asked if we have a “how to create a PR info area: in the Core Editor handbook. Closest match is here.

Post Meeting discussion

There has been some discussion post meeting between @matveb, Pablo Honey and @mapk about the limitations of designing more complex block patterns.

To sum up the way forward is to provide the best patterns we can which don’t don’t suffer from the lack of tools and when we run into limitations to distill them down to improvements on the blocks themselves.


Guidelines for ancient browser support: IE

WordPress still officially supports IE 11, and will likely have to continue support for it for a while. But there is not a huge amount of people using it anymore, and there’s some indication that quite a few of the people still using it may be screen reader users.

On the other hand, there are lots of new-ish features, particularly in CSS, that it would be very useful to start exploring.

A graceful degradation approach might be the best way to allow WordPress to leverage the potential of new tech, without ruining the experience for those who still rely on legacy browsers. But how to go about adopting this approach?

Graceful degradation ensures essential functionality is still available for IE users, and features lacking IE support are used only for enhancements. What is essential is not always obvious though, so it would be good to agree on some rules for how to go about this.

I’ve created a Trac ticket for this task. It would be lovely to get some discussion going on this, either there or here!

WP Notify weekly meeting suspended, call for proposals for new meeting times or new meeting hosts.

At the present moment, due to various circumstances, the Monday 14:00 UTC time slot for the WP Notify weekly meeting has become problematic for me. This means it is becoming more and more difficult for me to attend, let alone host these meetings.

I am therefore putting these meetings on hold until we can agreed on either a new meeting time, or chose a new meeting host to drive the weekly meetings forward.

I will leave the post open for comment for the rest of the week, or until we can agree on a way forward.



wp-env: Simple Local Environments for WordPress.

Local WordPress environments are now as simple as running a single command. wp-env is a zero config tool for painless local WordPress environments. It provides decisions over options so that users can quickly spin up WordPress without wasting time. Indeed, the goal is to make these environment easily accessible to all — whether you’re a developer, designer, manager, or anyone else. It really is this straightforward:

  1. From the directory of your WordPress source code, plugin, or theme, run wp-env start.
  2. Access the instance on localhost:8888. The local code is already mapped and ready for development!

In this basic example, there is no configuration. wp-env creates a Docker instance behind the scenes with the latest WordPress image and then maps the local theme or plugin to the environment as a Docker volume. This way, any changes you make to the code locally are reflected immediately in the WordPress instance.

wp-env requires both Docker and Node. Once these prerequisites are met, you can run npm install -g @wordpress/env to install wp-env locally. Feel free to test it out from the root of the Gutenberg repository!

For more advanced use cases, the experience is just as simple after one includes a short configuration file (called .wp-env.json) in the source code. Running wp-env start in the same directory as a .wp-env.json file will automatically start and configure everything for you according to the specifications in the file. This makes it easy for new folks to start contributing or testing in advanced environments without having to configure anything themselves.

The .wp-env.json file allows you to create fairly advanced local development setups. Here is the documentation for the config file, and below is an advanced use case:

  "core": "https://wordpress.org/wordpress-5.4-beta2.zip",
  "plugins": [
  "port": 1000,
  "testsPort": 1001,
  "config": {
    "WP_DEBUG_DISPLAY": true

The core field allows us to specify a source for the core WordPress code. Additionally, the plugins and themes fields allow us to specify sources for plugins and themes. These sources can be in several formats: relative or absolute local paths, a GitHub repository, or a URL to a .zip file.

In the above example, we see the following:

  • The core field is mapped to a beta version of WordPress in the .zip format.
  • The plugins field contains several plugins. The first is a local path to a plugin, the next is a zip file, the third is the plugin in the same directory as the .wp-env.json file, and last is a reference to the master branch of the Gutenberg GitHub repository.
  • The port field overrides the port on which the instance is mounted. In this case, we access WordPress at http://localhost:1000.
  • The config field sets wp-config.php constants. Here, the WP_DEBUG_DISPLAY constant is set to true in the created WordPress instance.

You might need to create this file if your plugin or theme has a lot of dependencies or options required for development. Instead of offloading this configuration work to the consumer, .wp-env.json makes the development and testing of advanced setups easily accessible to anyone with wp-env installed.

Finally, props to @noisysocks and @epiqueras for making this tool possible. If you’d like to learn more about wp-env, see the documentation page, read the source code, or follow development progress. As always, feel free to open issues or pull requests on GitHub if you find bugs or have suggestions concerning the tool.


Associating GitHub accounts with WordPress.org profiles

In an effort to make tracking all contributions to the WordPress project across multiple locations easier, a new option is available when editing your WordPress.org profile that allows you to connect your GitHub account.

WordPress.org profile with GitHub profile link highlighted.

In recent releases, the process of collecting props for non-WordPress.org contributions (namely Gutenberg) has been highly manual and error prone, occasionally resulting in contributors not receiving proper credit. Connecting your WordPress.org and GitHub accounts will allow automatic tooling to be built which reduces the burden on release teams to maintain a credit list.

How it works

The feature uses an oAuth flow to grant a WordPress GitHub application read-only access to your GitHub account’s public information. This proves that you own both the GitHub account and the WordPress.org account and links the two accounts.

This has been available and tested for several months now, and many contributors have connected their accounts. But, because it was never officially announced, adoption has been low.

If you have not already, please take a moment to connect your GitHub account to your WordPress.org account by going to https://profiles.wordpress.org/me/profile/edit/.

Below are some screenshots of how the process works.

1. Edit WordPress.org profile

WordPress.org profile edit screen with the GitHub Username section highlighted.
Click “link your GitHub account” to initiate the process.

2. Authorize WordPress.org Profiles application

The authorization screen on GitHub for the WordPress.org Profiles application.
Grant the WordPress Profiles GitHub application read-only access to your public information.

3. Verify connection

WordPress.org profile edit screen showing a linked GitHub profile.
Access can be revoked at any time on the Edit Profile screen on WordPress.org.

Huge props go out to @dd32 for implementing this feature. For more information on this feature and the ongoing effort to make collecting props easier, see Meta-#4447.

Dev Chat Agenda for March 25, 2020 (5.4 Week 11)

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


WordPress 5.4 Release Candidate 4 landed yesterday, March 24, as scheduled.

Upcoming Releases

  • The current major is 5.4, scheduled to go out on March 31st 2020; please keep testing for all the bugs!
  • Trunk has branched to 5.5 on the beginning of March. That means 5.5 is officially in Alpha.
  • Work for 5.6, aka all-women release, has kicked off with an initial round of messages going out to the women that expressed interest.

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