Make WordPress Core

Keyboard Shortcuts | Hide comment threads
Dan Farrow 8:04 pm on July 1, 2021

CSS Chat Agenda: July 1, 2021

This is the agenda for the upcoming CSS meeting scheduled for Thursday July 1 at 21:00PM UTC.

The meeting will be held in the #core-css channel in the Making WordPress Slack.

  • Housekeeping
  • Discussion: Custom Properties (#49930)
    Continue discussing the workflow for adding Custom Properties to core.
  • Open Floor + CSS Link Share

If there’s any topic you’d like to discuss, please leave a comment below!

#agenda

thewebinart 10:05 am on July 5, 2021

This will awesome to have beautiful design for the WordPress 6.0

thewebinart 10:11 am on July 5, 2021

This is will be awesome to have beautiful design for the WordPress 6.0

We could have some shortcuts for the developers, and improve their UX/UI, of course without the pleasure to use a beautiful CMS.

Ari Stathopoulos 9:36 am on July 1, 2021

Block-styles loading enhancements in WordPress 5.8

WordPress 5.8 improves the way we load block-styles by introducing 2 new features:

  • Load styles only for rendered blocks in a page
  • Inline small styles

Only load styles for used blocks

This is an opt-in, non-breaking change. Using the should_load_separate_core_block_assets filter, developers can opt-in to this feature:

1
add_filter( 'should_load_separate_core_block_assets', '__return_true' );

Prior to WordPress 5.8, styles for all blocks were included in a style.css file that gets loaded on every page. By opting-in to separate styles loading, the following will happen:

  • The wp-block-library stylesheet changes: Instead of loading the wp-includes/css/dist/block-library/style.css file which contains all styles for all blocks, this handle will now load the (much smaller) wp-includes/css/dist/block-library/common.css file, which contains generic styles like the default colors definitions, basic styles for text alignments, and styles for the .screen-reader-text class.
  • Styles for blocks will only get enqueued when the block gets rendered on a page.

The above changes will only apply to the frontend of a site, so all editor styles will continue to work as they did before.

The difference between block themes and classic themes

Block themes

In a block theme, blocks get parsed before the <head> so we always know which blocks will be present prior to rendering a page. This makes it possible to add the block styles to the <head> of our document.

Classic themes

In a classic, php-based theme, when a page starts to render, WordPress is not aware which blocks exist on a page and which don’t. Blocks gets parsed on render, and what that means is that block-styles don’t get added in the <head> of the page. Instead, they are added to the footer, when print_late_styles() runs.

If you have an existing theme and you want to opt-in to this improvement, you will need to test your theme for style priorities. Opting-in to separate styles loading in a classic theme means that the loading order of styles changes. Block styles that used to be in the head will move to the footer, so you will need to check your theme’s styles and make sure any opinionated styles you add to blocks have a higher priority than core styles.

Taking advantage of separate styles loading to add plugin/theme styles to blocks

It is possible to use this new feature to attach styles to existing block-styles, by inlining them.

If your theme adds styles to blocks, instead of loading a single file containing all styles for all blocks, you can split styles and have a single file per-block. This will allow you to only load your theme’s (or plugin’s) block styles only when a block exists on a page.

The function below is an example implementation of how to do that, with some additional tweaks:

  • It works both in WordPress 5.8 and previous versions
  • It has a fallback in case the should_load_separate_core_block_assets filter is disabled
  • It adds styles both in the editor and frontend
  • Checks for specific editor block styles.

Feel free to use this as an example, tweaking it to suit your needs and implementation.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
/**
 * Attach extra styles to multiple blocks.
 */
function my_theme_enqueue_block_styles() {
    // An array of blocks.
    $styled_blocks = [ 'paragraph', 'code', 'cover', 'group' ];
 
    foreach ( $styled_blocks as $block_name ) {
        // Get the stylesheet handle. This is backwards-compatible and checks the
        // availability of the `wp_should_load_separate_core_block_assets` function,
        // and whether we want to load separate styles per-block or not.
        $handle = (
            function_exists( 'wp_should_load_separate_core_block_assets' ) &&
            wp_should_load_separate_core_block_assets()
        ) ? "wp-block-$block_name" : 'wp-block-library';
 
        // Get the styles.
        $styles = file_get_contents( get_theme_file_path( "styles/blocks/$block_name.min.css" ) );
 
        // Add frontend styles.
        wp_add_inline_style( $handle, $styles );
 
        // Add editor styles.
        add_editor_style( "styles/blocks/$block_name.min.css" );
        if ( file_exists( get_theme_file_path( "styles/blocks/$block_name-editor.min.css" ) ) ) {
            add_editor_style( "styles/blocks/$block_name-editor.min.css" );
        }
    }
}
// Add frontend styles.
add_action( 'wp_enqueue_scripts', 'my_theme_enqueue_block_styles' );
// Add editor styles.
add_action( 'admin_init', 'my_theme_enqueue_block_styles' );

Inlining small assets

In some cases small stylesheets get loaded on WordPress sites. These stylesheets require the browser to make an additional request to get an asset, and while they benefit from caching, their small size doesn’t justify that extra request, and performance would improve if they were inlined.

To that end, an inlining mechanism was implemented. This is an opt-in feature, and can be handled on a per-stylesheet basis. Internally, only assets that have data for path defined get processed, so to opt-in, a stylesheet can add something like this:

1
wp_style_add_data( $style_handle, 'path', $file_path );

When a page gets rendered, stylesheets that have opted-in to get inlined get added to an array. Their size is retrieved using a filesize call (which is why the path data is necessary), and the array is then ordered by ascending size (smaller to larger stylesheet). We then start inlining these assets by going from smallest to largest, until a 20kb limit is reached.

A filter is available to change that limit to another value, and can also be used to completely disable inlining.

To completely disable small styles inlining:

1
add_filter( 'styles_inline_size_limit', '__return_zero' );

To change the total inlined styles limit to 50kb:

1
2
3
add_filter( 'styles_inline_size_limit', function() {
    return 50000; // Size in bytes.
});

Inlining these styles happens by changing the src of the style to false, and then adding its contents as inline data. This way we avoid backwards-compatibility issues in themes and any additional styles attached to these stylesheets using wp_add_inline_style will still be printed.

Please note that if a stylesheet opts-in to get inlined, that is no guarantee that it will get inlined.

If for example on a page there are 30 stylesheets that are 1kb each, and they all opt-in to be inlined, then only 20 of them will be converted from <link rel="stylesheet"/> to <style> elements. When the 20th stylesheet gets inlined the 20kb limit is reached and the inlining process stops. The remaining 10 stylesheets will continue functioning like before and remain <link> elements.

If your theme opts-in to the separate block-styles, core block styles by default have path defined so they can all be inlined.

Props @sergeybiryukov for proofreading this dev-note.

#5-8, #dev-notes

Damon Cook 10:50 am on July 1, 2021

This is great stuff 5hanks Ari!

Cory Birdsong 1:42 pm on July 1, 2021

On a recent custom theme I used a combination of has_block() and parse_blocks() to check the post’s content for blocks before the wp_enqueue_scripts action fires, which avoids the flash of unstyled content. Is this a bad idea for performance or otherwise impractical?

Ari Stathopoulos 2:34 pm on July 1, 2021

It depends on what you want to check…
If you want to check which blocks exist in the_content I suppose it’s OK to do it this way.

However, WordPress 5.8 also adds a new widget-areas editor and users will now be able to add blocks inside a widget area. Checking the_content in that case won’t be enough to get all blocks that may exist on a page, so it’s not something that we can use to print styles in this context.

A workaround would be to render the whole page in-memory first, gather an array of all blocks that may exist in the content, sidebars, footer etc, then inject the stylesheet in the head of the document and render the whole page at once.

But that would require a significantly bigger refactor and can’t be part of WordPress 5.8 at this point. It is however the way that block templates (and block themes) work, which is why block styles get added in the head in that case.

Another way to avoid FOUC if that worries you, would be to inject the stylesheets in the content, right before the first instance of a block, using something like this:

1
2
3
4
5
6
7
8
9
10
11
add_filter( 'render_block', function( $html, $block ) {
    static $rendered_styles = [];
    if ( isset( $block['blockName'] ) && ! in_array( $block['blockName'], $rendered_styles, true) ) {
        $stylesheet = "assets/blocks/{$block['blockName']}.css";
        if ( file_exists( get_theme_file_path( $stylesheet ) ) ) {
            echo '<style>' . file_get_contents( get_theme_file_path( $stylesheet ) ) . '</style>';
            $rendered_styles[] = $block['blockName'];
        }
    }
    return $html;
}, 10, 2 );

The above is a very crude example, but it is possible to do something like that and I actually have done it in the past in an older theme 😀
It will print a style containing the styles for a block the 1st time it encounters an instance of the block, but if you decide to go down that road make sure you also implement it for innerBlocks etc, maybe add some fallbacks and expand the logic to suit your needs.

Tom 3:13 pm on July 1, 2021

However, WordPress 5.8 also adds a new widget-areas editor and users will now be able to add blocks inside a widget area. Checking the_content in that case won’t be enough to get all blocks that may exist on a page, so it’s not something that we can use to print styles in this context.

Why not just parse `get_option( ‘widget_block’ )`?

CLS/FOUC is a pretty major issue these days. Loading those styles in the footer doesn’t seem like a good idea in my opinion. Parsing `the_content` and `widget_block` before `wp_enqueue_scripts` seems like something worth exploring.

Ari Stathopoulos 3:46 pm on July 1, 2021

CLS is not the same as FOUC… and we’re not talking about major style shifts, block-styles are usually pretty small in size which means that you can also take advantage of the inlining mechanisms mentioned in the post to add these styles inline instead of loading an additional asset – which would cause a delay. Inlining them would make them be included in the initial response when the browser gets the HTML and by inlining the small styles, FOUC is kept to a minimum, to the point where it’s barely (if at all) noticeable.

Personal opinion follows:
Last year I was living in an area without good internet coverage and all I had at my disposal was a slow 3G connection. Sites with “FOUC” were always a pleasant surprise because I could actually consume the content a lot faster. Now that I moved and have a decent connection those same sites are not annoying because the FOUC is no more than a few milliseconds.
What I’m trying to say is, there is no perfect solution. What one finds annoying is another person’s delight… which is why this is opt-in and not forced. You can optimize a theme to work perfectly with this option on, or you can do it with this option off. This is just another tool in our arsenal, how we use it is up to each one of us.

Why not just parse `get_option( ‘widget_block’ )`?

That would probably solve the widgets thing… but it’s important to remember that widgets are just the start. It may be the only thing we have now, but it’s also possible to have widgets in a header, footer, without using sidebars. This is already possible in the Gutenberg plugin (see PR http://wayback.fauppsala.se:80/wayback/20210711165750/https://github.com/WordPress/gutenberg/pull/30345) or in themes simply by back-porting functions similar to those in the PR. When this gets backported to core we’ll need a different implementation for these too…

Yes, there are ways to optimize things so please if you have any suggestions for improvements, pull-requests in the Gutenberg plugin and patches in WordPress trunk are always welcomed!!

But the way forward is block-themes where things just… work!

Cory Birdsong 3:19 pm on July 1, 2021

Thanks! Very informative.

It seems like it would be worth checking the_content for blocks and adding those styles to the even if widgets end up having their styles in print_late_styles()?

Rich Tabor 2:26 pm on July 1, 2021

Taking advantage of separate styles loading to add plugin/theme styles to blocks

Are you referring to if styles are added to blocks via RegisterBlockStyle as well?

Ari Stathopoulos 2:44 pm on July 1, 2021

This post refers to block-styles as in the blocks CSS styles, not the block-styles API. Checking at the code now, I see that using the PHP equivalent of registerBlockStyle would be register_block_style and these styles get printed via the enqueue_block_styles_assets function. Currently there is no check to only load these block-styles only when the actual block gets rendered, but that is an excellent observation!
We could definitely improve it so these styles only get enqueued/inlined when needed… Could you please create a ticket for that (if one does not already exist) so we can fix it? It can’t be a part of WP5.8 ’cause we’re past the point of adding new features, but it can definitely be included in 5.9 (or a minor release?)

Paul Gibbs 8:46 am on July 3, 2021

To clarify for my own understanding, if this was done, the load-assets-when-used approach would work for a well-written custom block plugin?

Ari Stathopoulos 11:20 am on July 7, 2021

A new ticket was created for this on trac (#53616) and a patch was included.

WebMan Design | Oliver Juhas 3:35 am on July 5, 2021

This is looking great.
Just a question about `file_get_contents()`: is it allowed to use this function in themes? I’m not 100% sure now, but as far as I know it is being flagged with Theme Check plugin and when submitting a theme to repository.

Ari Stathopoulos 6:19 am on July 5, 2021

Yes, that changed a few months ago, file_get_contents is now allowed.

Josepha 9:29 pm on June 29, 2021

Dev Chat Summary: June 23, 2021

Chats were led by @peterwilsoncc and @jeffpaul. Opened with intros and welcome.

Highlighted Posts

  • Dev notes are shipping!
  • Block Editor API Changes to Support Multiple Admin Screens in WP 5.8
  • Bundled themes changes in WordPress 5.8
  • Extending the Site Health interface in WordPress 5.8
  • Block API Enhancements in WordPress 5.8
  • Meeting notes and stuff
  • Regular posts on A Week in Core plus CSS and Editor chat summaries are also available to peruse.

WP5.8 Things

Component Check-in

  • Build/Test Tools: sourceMaps are now ignored for non WordPress Core files to avoid a build failure for custom plugins or themes located in build/wp-content. See ticket #52689 for more details.
  • Git is now used when fetching the WordPress Importer for unit tests. Previously, SVN was used and the commands were not correctly run within the Docker container. See ticket #52909 for more details.
  • Bundled themes: There are a few tickets related to polishing the new blocks added in 5.8 that need testing. And the default themes also need more testing in general for 5.8. If that’s within your area of expertise, please feel free to help out with that.

Open Floor

#5-8

Jb Audras 9:19 pm on June 29, 2021

A Week in Core – June 28, 2021

Welcome back to a new issue of Week in Core. Let’s take a look at what changed on Trac between June 21 and June 28, 2021.

  • 60 commits
  • 64 contributors
  • 79 tickets created
  • 8 tickets reopened
  • 78 tickets closed

Please note that the WordPress Core team released WordPress 5.8 beta 3 and beta 4 last week. Everyone is welcome to help testing the next major release of WordPress 🌟

Ticket numbers are based on the Trac timeline for the period above. The following is a summary of commits, organized by component and/or focus.

Code changes

Build/Test tools

  • Add the regenerator-runtime script as a dependency to wp-polyfill – #52941
  • Correct PHPUnit version requirement in tests using ::createPartialMock() – #52625
  • Replace assertEquals() with assertSameSets() in text widget tests – #52482, #52625
  • Require PHPUnit >= 6 in tests using ::createPartialMock() – #52625
  • Use assertSame() in _wp_to_kebab_case() tests – #52482, #52625, #53397
  • Use more appropriate assertions in a few tests – #52625

Bundled Themes

  • Improve display of blocks in widget areas – #53422
  • Improve Gutenberg check before activating an FSE theme – #53410
  • Prevent a Full Site Editing theme from being activated when Gutenberg is not active – #53410
  • Remove mention of “FSE” in Core – #53497
  • Remove unexpected border around the Theme Details button – #53473
  • Twenty Nineteen: Update margins on full- and wide-aligned blocks in the editor – #53428
  • Twenty Thirteen: Improve the display of the Query Loop block – #53438
  • Twenty Twenty-One: Add margins around content in Post Template block – #53389, #53398
  • Twenty Twenty-One: Add spacing around Query block when there is a background color – #53398
  • Twenty Twenty-One: Use the theme version when enqueueing theme assets – #53502
  • Twenty Twenty: Remove extra margin within the Query Loop block – #53482

Coding standards

  • Apply an alignment fix from running composer format – #53481
  • Fix WPCS issues in [51227] – #53475
  • Use a consistent check for parent items in WP_Walker – #53474

Docs

  • Document api_version and variations properties in WP_Block_Type::__construct() – #53518
  • Fix typo in widgets-block-editor feature documentation – #53424
  • Remove inaccurate @since tag – #53461, #50105
  • Shorten the copyright notice for the WP_REST_Sidebars_Controller class – #41683
  • Update documentation for WP_Widget_Block per the documentation standards – #52628, #53461
  • Various docblock corrections for code added in 5.8 – #53461
  • Various filter docblock improvements – #52920

Editor

  • Allow custom-units to be an array – #53472
  • Correct variable names in get_block_editor_settings() – #53458
  • Ports theme.json changes for beta 3 – #53397
  • Do not load a default font family for themes with theme.json
  • Move caching to endpoint for unique responses – #53435
  • Package updates for Beta 3 – #53397
  • Package updates including fixes from Gutenberg for WordPress 5.8 RC1 – #53397
  • Remove empty blocks/query-loop directory – #52991
  • Send locale, version with remote pattern requests – #53435
  • Update the packages with a number of fixes targeted for Beta 4 – #53397

General

  • Ensure svn:eol-style is consistently set for all recently added files – #53528

Media

  • Add lazy-loading support to block-based widgets – #53463, #53464
  • Correct undefined variable in wp_ajax_query_attachments – #50105
  • Improve upload page media item layout on smaller screens – #51754
  • Prevent uploading and show an error message when the server doesn’t support editing of WebP files and image sub-sizes cannot be created – #53475
  • Prevent uploading and show an error message when the server doesn’t support editing of WebP images, take II. Add new, better error message for it – #53475
  • Revert r51211 to restore ms-files.php assets – #53492, #53475

REST API

  • Include the sidebar ID when saving a widget – #53452
  • Retrieve latest widgets before loading sidebars – #53489

Site Health

  • Add a unique wrapper for dashboard widget content – #53521

Widgets

  • Fix non-multi widgets not appearing in wp_inactive_widgets – #53534
  • Add editor styles to the widgets block editor – #53344. – #53388
  • Add missing label and description to Customizer controls – #53487
  • Add support for the Widgets Editor on after_setup_theme instead of widgets_init – #53424
  • Avoid a TypeError when adding a widget in the Customizer – #53488, #53421, #53419
  • Fix an “Invalid value” warning when adding a new widget in the Customizer – #53479
  • Fix widget preview not working if widget registered via a instance
  • Remove unnecessary gutenberg_ functions – #53441
  • Stop loading wp-editor and the Block Directory assets on the widgets screen – #53437, #53397

Props

Thanks to the 64 people who contributed to WordPress Core on Trac last week: @noisysocks (10), @desrosj (9), @ryelle (7), @hellofromTonya (5), @nosolosw (4), @zieladam (4), @SergeyBiryukov (4), @spacedmonkey (4), @aristath (3), @scruffian (3), @peterwilsoncc (3), @azaozz (3), @audrasjb (3), @gziolo (3), @johnbillion (3), @walbo (3), @caseymilne (3), @youknowriad (2), @jorbin (2), @Mamaduka (2), @dd32 (2), @joedolson (2), @kevin940726 (2), @jamesros161 (2), @chanthaboune (2), @timothyblynjacobs (2), @jorgefilipecosta (2), @marybaum (1), @ocean90 (1), @daisyo (1), @tellyworth (1), @sumaiyasiddika (1), @danieldudzic (1), @mkaz (1), @Presskopp (1), @joen (1), @sabernhardt (1), @andraganescu (1), @sunxiyuan (1), @isabel_brison (1), @kraftner (1), @onemaggie (1), @jffng (1), @otto42 (1), @Boniu91 (1), @Clorith (1), @alanjacobmathew (1), @mbabker (1), @ntsekouras (1), @strategio (1), @poena (1), @naoki0h (1), @ixkaito (1), @antpb (1), @aleperez92 (1), @iandunn (1), @barry (1), @mukesh27 (1), @herregroen (1), @jeherve (1), @hellofromtonya (1), @adamsilverstein (1), @cbringmann (1), and @AlePerez92 (1).

Congrats and welcome to our 3 new contributors of the week! @sumaiyasiddika, @sunxiyuan, and @alanjacobmathew ♥️

Core committers: @desrosj (24), @sergeybiryukov (11), @ryelle (4), @youknowriad (3), @noisysocks (3), @iandunn (3), @jorbin (2), @azaozz (2), @jorgefilipecosta (2), @clorith (1), @timothyblynjacobs (1), @joedolson (1), @flixos90 (1), @peterwilsoncc (1), and @antpb (1).

#5-8, #week-in-core

Ella van Durpe 5:35 pm on June 29, 2021

Blocks in an iframed (template) editor

The new template editor is loaded in an iframe to isolate it from the rest of the admin screen. This has the following benefits:

  • Admin styles no longer affect the editor content, so there’s no need to reset any of these rules.
  • Content styles no longer affect the admin screen, so block and theme CSS rules no longer need to be prefixed.
  • Viewport relative CSS units will work correctly. The dimensions of the editor content is usually not the same as the dimensions of the admin page, so without an iframe units like vw will be relative to the admin page.
  • Media queries will also work natively, without needing to fake them, as we did before, which is fragile.
  • In general, it makes the lives of block and theme authors easier because styles from the front-end can be dropped in with very little, if nothing, to adjust. This also applies to lighter blocks, where the editor DOM structure matches the front-end, which we highly recommend when possible.
  • With a separate window for the editor content, it’s possible for the selection in the editor to remain visible while also having a (collapsed) selection in the editor UI, for example an input field for a URL.

We currently only iframe new editors. While the new template editor has been iframed, the post editor remains unchanged. We do this to gradually test how existing blocks from plugins work within an iframed editor, since there are cases where a block could look broken or (less likely) error. We hereby urge plugin authors to test their blocks with the new template editor and contact us if they need help to adjust blocks to work in the iframe.

Document and window

The iframe will have a different document and window than the admin page, which is now the parent window. Editor scripts are loaded in the admin page, so accessing the document or window to do something with the content will no longer work.

Most blocks written in React should continue to work properly, except if you rely on document or window. To fix, you need to create ref to access the relative document (ownerDocument) or window (defaultView). Regardless of the iframe, it is good practice to do this and avoid the use of globals.

const ref = useRef();
useEffect( () => {
  const { ownerDocument } = ref.current;
  const { defaultView } = ownerDocument;
  // Set ownerDocument.title for example.
}, [] );
const props = useBlockProps( { ref } );

If you attach event handlers, remember that the useEffect callback will not be called if the ref changes, so it is good practice to use the new useRefEffect API, which will call the given callback if the ref change in addition to any dependencies passed.

const ref = useRefEffect( ( element ) => {
  const { ownerDocument } = element;
  const { defaultView } = ownerDocument;
  defaultView.addEventListener( ... );
  return () => {
    defaultView.removeEventListener( ... );
  };
}, [] );
const props = useBlockProps( { ref } );

Other frameworks and libraries

For the editor, scripts such as jQuery are loaded in the parent window (admin page), which is fine. When using these to interact with a block in the iframe, you should pass the element reference.

const ref = useRefEffect( ( element ) => {
  jQuery( element ).masonry( … );
  return () => {
    defaultView.jQuery( element ).masonry( 'destroy' );
  }
}, [] );
const props = useBlockProps( { ref } )

But what if the library is using the global window or document and it’s out of your control?

Submit an issue or PR for the library to use ownerDocument and defaultView instead of the globals. Ideally, any library should allow initialisation with an element in an iframe as the target. It’s never impossible. Feel free to contact us to mention the issue.

In the meantime, you can use the script that is loaded inside the iframe. We’ve loaded all front-end scripts in the iframe to fix these cases, but note that ideally you shouldn’t use scripts loaded in the iframe at all. You can use defaultView to access the script.

const ref = useRefEffect( ( element ) => {
  const { ownerDocument } = element;
  const { defaultView } = ownerDocument;
 
  // Use the script loaded in the iframe.
  // Script are loaded asynchronously, so check is the script is loaded.
  // After the dependencies have loaded, the block will re-render.
  if ( ! defaultView.jQuery ) {
    return;
  }
 
  defaultView.jQuery( element ).masonry( … );
  return () => {
    defaultView.jQuery( element ).masonry( 'destroy' );
  }
} );
const props = useBlockProps( { ref } );

And that’s it! In summary, any problem that a block might have in the iframe is caused by using the document or window global at the root of it, either in the block’s code or a third party library. Ideally, all code uses the ownerDocument and defaultView relative properties.

#5-8, #dev-notes, #gutenberg

Joy 6:12 pm on June 29, 2021

In general, it makes the lives of block and theme authors easier because styles from the front-end can be dropped in with very little, if nothing, to adjust.

Except that they still need separate styles for the post editor, so it’s not really easier. (This is simply going back to the good old days of Classic editor in an iframe.)

Josepha 4:26 pm on June 30, 2021

It is worth noting that we’re in the middle of a multi-year project to update the whole of WordPress. Because we are trying to minimize fully breaking changes, there will necessarily be some overlap as we make progress, and reducing the work to “simply going back” isn’t accurate.

No one has to like everything being done in the project—it would be strange if they did!—but there is a bit more nuance to the components than your comment suggests.

Paul Gibbs 9:00 am on July 3, 2021

Is there a mechanism to opt-in to the iframe approach for the post template editor?

Paul Gibbs 9:01 am on July 3, 2021

Sorry, typo – meant the Post editor! 😅

Ella van Durpe 7:01 pm on July 4, 2021

You mean for the site as a whole or for specific blocks? We could add an option for the site as a whole, but it would be experimental.

Mimin Maniez 3:24 pm on July 4, 2021

mungkin beberapa cara diatas akan saya praktekan disitus sinopsis saya terbaru.

Joost Boomkamp 7:46 am on July 6, 2021

I believe you’d want to add a ! in that code example to check if jQuery exists:

1
if ( <strong>!</strong> defaultView.jQuery ) {
exstheme 10:53 am on July 11, 2021

It seems that extending of the block editor CSS styles as noted in the documentation does not work in the iframe?

http://wayback.fauppsala.se:80/wayback/20210711165750/https://developer.wordpress.org/block-editor/how-to-guides/javascript/extending-the-block-editor/

Ella van Durpe 4:04 pm on July 11, 2021

Right, enqueuing styles with enqueue_block_editor_assets won’t work for the iframe because it’s not possible to tell if the styles are for editor UI or content. The only way to add styling right now is though a block (http://wayback.fauppsala.se:80/wayback/20210711165750/https://developer.wordpress.org/block-editor/reference-guides/block-api/block-metadata/#editor-style) or add_editor_style (http://wayback.fauppsala.se:80/wayback/20210711165750/https://developer.wordpress.org/reference/functions/add_editor_style/) if you’re not registering a block.

exstheme 11:26 am on July 11, 2021

I also have noticed that even on the default WordPress theme styles in the iframe editor are broken: blocks are not aligned to the center of the editor:

http://wayback.fauppsala.se:80/wayback/20210711165750/https://prnt.sc/1a8h86d

Also i have noticed that font size is now 13px in the version 5.8 even for the regular (not iframe) editor.
Is this some kind of bug?

Thank you!

Riad Benguella 5:29 pm on June 29, 2021

On layout and content width in WordPress 5.8

WordPress 5.8 introduces Global Settings and Global Styles. They allow theme authors to control and style the available features in the editor and the different blocks using a theme.json.

By using a theme.json file, in addition to the Global styles and settings capabilities, theme authors opt-in into the layout feature for block containers.

Layout config

Historically, themes had the responsibility to provide CSS styles in order to support aligning content (left, right). With the introduction of the block editor in WordPress 5.0, new alignments has been added to the mix (wide, full). In addition to that, the block editor allowed users to use container blocks (group, columns blocks) which potentially can change how their inner blocks are positioned and aligned. Taking all these variations into consideration has become a very difficult task for theme authors. To address these issues, WordPress 5.8 introduces the layout feature and config.

How do I migrate my theme

Themes that have a centered content area, need to define a layout setting in their `theme.json` file:

{
   "settings": {
       "layout": {
           "contentSize": "800px",
           "wideSize": "1000px"
       }
   }
}

The block-editor will automatically read this config and provide the corresponding styles in the editor. It will allow all alignments to work properly without requiring the `add_theme_support( ‘align-wide’ )` call.

Themes are still required to provide the corresponding styles in the frontend of their sites, something like:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
.entry-content > * {
    max-width: 800px;
    margin-left: auto !important;
    margin-right: auto !important;
}
 
.entry-content > .alignwide {
    max-width: 1000px;
}
 
.entry-content > .alignfull {
    max-width: none;
}
 
.entry-content > .alignleft {
    float: left;
    margin-right: 2em;
}
 
.entry-content > .alignright {
    float: right;
    margin-right: 2em;
}

Note:

It’s not possible for WordPress to generate these styles automatically for all themes because the entry-content className in the example above is not mandatory and may not exist. In the future, with the introduction of the upcoming block themes, these styles won’t be needed anymore.

Nested Blocks

For themes with the layout config enabled, container blocks (like group blocks) do not automatically inherit the layout config. Meaning the blocks added inside the containers will by default take all the available space and not have any wide/full alignments options unless the user defines the wide and content sizes for that particular container block or “inherits” the config from the default layout.

This also means that themers can drop any alignment specific CSS that was added specifically to support nested blocks.

#5-8, #dev-notes, #gutenberg

philhoyt 6:23 pm on June 30, 2021

Meaning the blocks added inside the containers will by default take all the available space and not have any wide/full alignments options unless the user defines the wide and content sizes for that particular container block or “inherits” the config from the default layout.

How about blocks which do not have alignment options such as Paragraph? The work around I’ve found is to place a single column block, align that, and then the paragraph block. But this feels clunky.

Rich Tabor 2:29 pm on July 1, 2021

Agreed. I’ve always thought it interesting that the Heading block lets you set wide/full alignment, but the Paragraph block does not.

nick6352683 5:00 pm on July 1, 2021

Just put the paragraph(s) into a Group or Cover block, and set the wide/full alignment there…

philhoyt 5:03 pm on July 1, 2021

I already described such a solution as… clunky

keithdevon 6:40 pm on July 1, 2021

I’ve been enabling paragraph alignment in editor.js on my recent themes.

Riad Benguella 11:08 am on July 5, 2021

Good remarks here, I agree that the alignment options seem independent of the block itself but rather an option that should be added to all blocks depending on their containers instead.

The challenges there is how to do it without having a big impact on the UI (block toolbars…). I’d love to explore this further.

Jeffrey Paul 4:54 pm on June 29, 2021

Dev Chat Agenda for June 30, 2021

Here is the agenda for this week’s developer meetings to occur at the following times: Wednesday, June 30, 2021 at 05:00 AM UTC and Wednesday, June 30, 2021 at 08:00 PM UTC.

Blog Post Highlights

5.8 Schedule Review

  • Beta 4 released last week and RC 1 yesterday and now under hard string freeze
  • Focus now shifts fully to RC phase with RC 2 release in 6 days on Tuesday, July 6th
  • Also working to publish Dev Notes, Field Guide and email to plugin/theme authors
  • Next RC Scrub before RC 2 is Monday, July 5, 2021 at 08:00 PM UTC (this needs a scrub host/coordinator)
  • RC 2 in 6 days on Tuesday, July 6th
  • RC 3 in 13 days on Tuesday, July 13th
  • 5.8 release in 20 days on Tuesday, July 20th

Components check-in and status updates

  • 5.8 plans and help needed
  • Check-in with each component for status updates.
  • Poll for components that need assistance.

Open Floor

Do you have something to propose for the agenda, or a specific item relevant to the usual agenda items 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-8, #agenda, #dev-chat

Jb Audras 4:34 pm on June 29, 2021

Introducing “Update URI” plugin header in WordPress 5.8

WordPress 5.8 introduces a new header available for plugin authors. This allows third-party plugins to avoid accidentally being overwritten with an update of a plugin of a similar name from the WordPress.org Plugin Directory.

Previously, any custom plugin which used the same slug than a plugin hosted on WordPress.org was taking a significant risk of being overwritten by an update of the latter.

WordPress 5.8 introduces a new Update URI plugin header field. If the value of this new field matches any URI other than http://wayback.fauppsala.se:80/wayback/20210711165750/https://wordpress.org/plugins/{$slug}/ or w.org/plugin/{$slug}, WordPress will not attempt to update it.

If set, the Update URI header field should be a valid URI and have a unique hostname.

Please note that authors of plugins hosted by WordPress.org don’t need to use this new header.

Some examples include:

  • Update URI: http://wayback.fauppsala.se:80/wayback/20210711165750/https://wordpress.org/plugins/example-plugin/
  • Update URI: http://wayback.fauppsala.se:80/wayback/20210711165750/https://example.com/my-plugin/
  • Update URI: my-custom-plugin-name

Update URI: false also works, and unless there is some code handling the false hostname (see the hook introduced below), the plugin will not be updated.

If the header is used on a w.org hosted plugin, the WordPress.org API will only return updates for the plugin if it matches the following format:

  • http://wayback.fauppsala.se:80/wayback/20210711165750/https://wordpress.org/plugins/{$slug}/
  • w.org/plugin/{$slug}

If the header has any other value, the API will not return any result. It will ignore the plugin for update purposes.

Additionally, WordPress 5.8 introduce the update_plugins_{$hostname} filter, which third-party plugins can use to offer updates for a given hostname.

This new hook filters the update response for a given plugin hostname. The dynamic portion of the hook name, $hostname, refers to the hostname of the URI specified in the Update URI header field.

The hook has four arguments:

  • $update: The plugin update data with the latest details. Default false.
  • $plugin_data: The list of headers provided by the plugin.
  • $plugin_file: The plugin filename.
  • $locales: Installed locales to look translations for.

They can be used to filter the update response in multiple use cases.

For reference, see tickets #32101, #23318, and changelog [50921].

Thanks @milana_cap for proofreading.

#5-8, #dev-notes

Sybre Waaijer 5:13 pm on June 29, 2021

Awesome! Does this mean we can finally migrate plugin slugs on the repo?

Knut Sparhell 5:28 pm on June 29, 2021

If the value of this new field matches any URI other than http://wayback.fauppsala.se:80/wayback/20210711165750/https://wordpress.org/plugins/{$slug}/ or w.org/plugin/{$slug}, WordPress will not attempt to update it.

I read {$slug} as current slug, not any valid slug in the repo. So I don’t think this opens for migration. It could be interesting to investigate the possibility of using this mechanism that way, however.

Samuel Wood (Otto) 8:40 pm on June 29, 2021

The idea of “migrating” plugins to another slug doesn’t work for other reasons, none of which are very particular to the org plugin repository. Doing so would be a completely separate discussion, realistically. Although, not a very long one, as there is no real need to ever change the slug of a plugin.

Sybre Waaijer 5:32 am on June 30, 2021

The impact of the slug is real as long as this value gets the massive boost of 2. One cannot find my plugin in other languages but English, even when 100% translated. There’s a prominent bug lingering in Jetpack’s ElasticSearch, hidden at WordPress.com’s side, which biases search for non-English toward a slug-match or otherwise installation-count. Either migrating the plugin slug or disavowing their weight would solve the issue. Or, of course, fixing that bug would also help :), but I have no access to the source to help pinpoint that.

Samuel Wood (Otto) 9:07 am on July 5, 2021

Migrating slugs is not happening. So, find another solution to your presumed problems.

Ipstenu (Mika Epstein) 7:36 pm on June 29, 2021

Alas, no, it wouldn’t work properly. Slug is the current slug, as Knut said. Changing it would .. well, try to break it.

Joy 5:15 pm on June 29, 2021

This part doesn’t seem right:

If the header has any other value, the API will not return any result. It will ignore the plugin for update purposes.

Doing that would allow placeholder plugins in the repository. When I read the discussion, I thought it meant that plugins in the repository were not allowed to have any value other than the WP repo. In other words, other values would be ignored for plugins in the repo, meaning that they would still be updated as usual from the WP repo, and not externally (or disabled).

Samuel Wood (Otto) 8:18 pm on June 29, 2021

No, the Update URI will not be allowed to be set to be incorrect in the repository.

How this will be accomplished is still being worked on, but suffice it to say that attempts to put in the wrong Update URI into plugin code hosted here will not be allowed. If we find such, then it will be either corrected or eliminated.

Doug Wollison 8:53 pm on June 29, 2021

Does this apply to themes as well? It’s nearly the same basic system so I would assume so but there’s no mention in this post.

Samuel Wood (Otto) 9:13 pm on June 29, 2021

Themes are different, and would need a somewhat different approach. We haven’t discussed it yet in any great detail, however if it works out well for plugins, then themes will likely get a similar treatment in the future.

Doug Wollison 10:23 pm on June 29, 2021

Wait, how are themes that different? They seem identical to me in terms of how updating would be handled.

Samuel Wood (Otto) 10:35 pm on June 29, 2021

Themes are updated by uploading a ZIP of the theme. Plugins are updated directly in SVN. Different processes. The API changes will be similar, but different in the internal code.

Doug Wollison 3:22 am on June 30, 2021

I don’t follow; the wp_update_themes/plugins functions simply compile a list of installed themes/plugins to send to the update-check API endpoint to get info on newer versions. This new Update URI header should be dictating wether or not a theme/plugin is *included* in the sent list, right? Why would the backend structure of the repo matter?

Samuel Wood (Otto) 9:09 am on July 5, 2021

Because none of the themes or plugins in the repo should have this header at all. We have to *prevent* them from including it. That’s why it matters.

Paal Joachim Romdahl 1:52 pm on June 29, 2021

Editor Chat Agenda: 30 June 2021

Facilitator and notetaker: @itsjusteileen

This is the agenda for the weekly editor chat scheduled for Wednesday, June 30, 2021, 04:00 PM GMT+1.

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

If you are not able to attend the meeting, you are encouraged to share anything relevant for the discussion:

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

#agenda, #core-editor, #core-editor-agenda, #meetings

Riad Benguella 8:28 am on June 29, 2021

Various Block Editor API removals in WordPress 5.8

Removed APIs

Keeping deprecated JavaScript APIs around has a cost on performance and bundle size. This means at some point we need to consider removing some of the very old deprecated APIs, especially the ones with very low usage. WordPress 5.8 does remove two APIs that were deprecated on WordPress 5.2.

  • EditorGlobalKeyboardShortcuts component, this was a component used to define some keyboard shortcuts of the block editor, it was not really meant to be used by third-party developers. We verified that it’s not used by any plugin in the repository but if you rely on this component, it should be safe to just replace with VisualEditorGlobalKeyboardShortcuts.
  • The hasUploadPermissions selector from the core store. We contacted all the three plugins in the repository that were still using this API. If you’re still relying on this selector on a private site/plugin, it can be safely replaced with select( 'core' ).canUser( 'create', 'media' )

Removed blocks

Before WordPress 5.0 and in the very early days of the Gutenberg plugin, we used to have a block called Subheading, this block has never been included in WordPress Core as stable, it was hidden and deprecated very early. We expect its usage to be very small. WordPress 5.8 removes the code of this block meaning that if you open content relying on that block in the editor, it will ask you to fallback to the HTML block instead. We don’t expect this to have a noticeable impact on the frontend of your site.

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