Tag Archives: block themes

Felix Arntz 7:34 pm on August 7, 2023
Tags: , block themes, , ,   

WordPress 6.3 performance improvements

Update (Aug 8, 2023): Benchmarks in this post were updated with results for the 6.3 stable release.

With WordPress 6.3 now available, this post summarizes the performance improvements that are part of this release. While WordPress 6.2 set the bar high with its notable boost to load time performance of CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress., WordPress 6.3 has been able to exceed these results: Based on the performance benchmarks conducted, WordPress 6.3 loads 27% faster for blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. themes and 18% faster for classic themes, compared to WordPress 6.2, based on the Largest Contentful Paint (LCP) metric. For WordPress 6.2, those improvements amounted to 18% and 5% respectively, so it is fair to summarize that WordPress 6.3 is a major achievement in terms of performance.

Thank you to @clarkeemily for collaborating on this post!

What makes 6.3 so much faster?

To break down the performance improvements in 6.3, it is crucial to understand the different load time performance metrics and how they relate. The most holistic metric is Largest Contentful Paint (LCP) because it captures overall load time performance. As such, the percentages mentioned in the introduction of this post were specifically the LCP improvements measured.

An important part of LCP is the Time to First Byte (TTFB) metric, which captures server-side load time performance and thus directly affects LCP: Effectively, TTFB is the server-side part that contributes to the LCP result. For client-side load time performance, there is no dedicated standalone metric. However, since client-side performance is effectively everything else, it can be concluded that client-side load time performance can be expressed by the difference between LCP and TTFB, i.e. “LCP-TTFB”.

Client-side performance

In WordPress 6.2, the majority of the performance boost came from improvements to server-side performance (TTFB), as highlighted in the aforementioned 6.2 performance improvements post. In WordPress 6.3, that is different: Most of the performance boost stems from client-side performance improvements (LCP-TTFB). In fact, client-side performance in WordPress 6.3 is 40% faster for block themes and 31% faster for classic themes, compared to WordPress 6.2. For reference, in the comparison of WordPress 6.2 with 6.1 LCP-TTFB amounted to only a 1.5% and 2.5% improvement respectively.

The vast majority of the client-side performance improvement comes from optimizing the emoji-loader.js script, by leveraging modern JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/. APIs such as Web Workers, OffscreenCanvas, and sessionStorage. Unless your WordPress site has disabled the related emoji functionality, you should notice a performance improvement due to this enhancementenhancement Enhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature.. See #58472 and [56074] for additional context on this change.

The other notable portion of the client-side performance improvements stem from adding support for the fetchpriority="high" attribute on images. As such, this improvement is only relevant on content with images above the fold, but given that images are by far the most common media used on web pages, it is very likely that you will notice a performance improvement from this enhancement as well. For a comprehensive overview of how to leverage and modify the new functionality as a developer, please refer to the 6.3 dev note on image performance improvements. For additional context on the change, see #58235 and [56037].

The following list highlights a few additional tickets that can improve client-side performance in certain scenarios, several of them enhancing the heuristics for whether to add the loading="lazy" attribute to images:

Last but not least: A notable developer feature that should be highlighted here is the introduction of script loading strategies, which adds support for loading scripts with defer or async. This is a major milestone for performance in general, however so far only the APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. itself has been introduced, which means there is no actual performance impact from it yet, which is why the change was not mentioned earlier in the post. As WordPress core and the ecosystem starts adopting the API (e.g. defer for block view scripts and async for comment-reply), it is anticipated that in the future we will see notable performance improvements from it as well. Please read the 6.3 dev note on registering scripts with async and defer to learn more on how you can leverage the API as a developer and the advantages over approaches that directly manipulate the script tagtag A directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.). See #12009 and [56033] for additional context on this change.

Server-side performance

While server-side performance improvements in 6.3 overall did not account for as much of the performance boost, the release still includes several notable enhancements, particularly for block themes, where server response time is 19% faster. Many of the server-side performance enhancements are the result of optimizing low-level logic in WordPress core internals. While this makes the improvements difficult to describe in isolation, it means that they don’t require any adoption or modifications in the WordPress ecosystem in order to become effective.

One of the most notable performance enhancements for block themes was a low-level change which optimizes how WordPress core block styles are registered. This is relevant since core block styles are handled slightly differently from those of custom blocks. Prior to 6.3 however, all blocks were using the same general logic which included quite a bit of flexibility, and thus also a performance cost, which was unnecessary for the core blocks. The change introduced a dedicated function to register core block styles in a more efficient way. See #58528 and [56044] for more context on this change.

Another major win for block theme performance was an improvement to the get_block_templates() function. The logic in that function was optimized to no longer process all block templates but only those that match the current query. See #57756 and [55687] for more context on this change.

The wp_common_block_scripts_and_styles() function is another optimized function that is certainly worth highlighting. This enhancement is only relevant to hybrid themes, specifically classic themes that call add_theme_support( 'wp-block-styles' ), but for those themes it results in a major server-side performance boost. See #58560 and [56064] for more context on this change.

The biggest change that has a notable performance impact for both block themes and classic themes is a performance optimization in the wp_maybe_inline_styles() function which avoids unnecessary calls to relatively costly functions to get the size and contents of stylesheet files. See #58394 and [55888] for more context on this change.

The following list highlights a few additional tickets that can improve server-side performance in certain scenarios:

Database performance

Several enhancements were made in WordPress 6.3 to lazy-load metadata, which can avoid database queries in certain situations. These changes are outlined in the 6.3 dev note post on metadata API improvements. See the individual tickets #57227, #57645, #57901, and #58185 for more context.

Additionally, the get_pages() function now uses WP_Query internally, which not only means elimination of duplicate code, but more importantly it leads to a performance improvement in the function as it now benefits from the same solid caching behavior, something that was missing in the previous custom implementation of the function. For more context, please see the 6.3 dev note on the get_pages() function and the ticketticket Created for both bug reports and feature development on the bug tracker. #12821.

Last but not least, the WP_User_Query class now supports caching query results, becoming the last of the WordPress core query classes to support it. This can avoid database queries when querying user information. For more context, please see the 6.3 dev note on WP_User_Query caching and the ticket #40613.

A note on the benchmarks used

While the metrics shared in this post are based on benchmarks that were conducted with the same methodology used for WordPress 6.2, any benchmarks need to be interpreted with nuance: Other than how the WordPress site used for benchmarking is configured, benchmarks are heavily dependent on the environment that they are run in. To have additional reference points, a few different contributors conducted and shared their benchmarks as well, based on a slightly earlier version of the release, 6.3 RC1. All of the benchmark results are summarized in this spreadsheet.

It can be noted there that some of the other benchmarks did not see improvements as high as noticed in the benchmarks highlighted (which, for context, were run on the author’s machine), but the main takeaway is that there is a notable performance boost overall. For now it made sense to focus on the performance benchmark with the numbers highlighted in this post in order to be consistent with the numbers from the aforementioned 6.2 performance improvements post, since that was using the same environment for the performance benchmarks as well. For any of the other contributors’ benchmarks where the relative improvements were not as high, it can be assumed that the 6.2 performance benchmarks on their environments would have shown an equivalently lower performance boost as well.

While this means we cannot get a definite answer to how much faster WordPress 6.3 is, it is safe to say that it is a lot faster than 6.2, and relatively speaking the performance improvement is even higher than it was between 6.2 and 6.1.

Automated benchmarking workflow

Some of the benchmarks referenced were conducted using a new reusable automated benchmarking workflow that @swissspidy recently implemented, using the same approach as the manual benchmarks, but using GitHubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ Actions. Those results show that using this workflow leads to more consistent results overall due to using the same environment, and it furthermore reduces the effort needed to conduct performance benchmarks. In the future it may be a good idea to rely on the numbers from that workflow rather than those from an arbitrary environment of a specific contributor. For reference, the automated workflow numbers roughly indicate the following performance improvements in WordPress 6.3 compared to 6.2:

  • LCP is 10.6% faster for block themes and 8.8% faster for classic themes.
  • TTFB is 4.7% faster for block themes and 5.6% faster for classic themes.
  • LCP-TTFB is 13.4% faster for block themes and 9.3% faster for classic themes.

Get involved

If you’re interested in working on improving performance across the project, make sure to join #core-editor, #core-performance, and attend meetings for both.

Props to @adamsilverstein, @annezazu, @joemcgill, @oandregal, @spacedmonkey, @westonruter for review and proofreading.

#6-3, #block-themes, #core-editor-improvement, #core-performance, #performance

annezazu 3:38 am on April 5, 2023
Tags: block themes, , ,   

WordPress 6.2 Performance improvements for all themes

With the latest WordPress release out in the world, this post seeks to recap the performance improvements available for all sites. According to this analysis done by @flixos90 that you’re encouraged to dig into, WordPress 6.2 loads 14-18% faster for blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. themes and 2-5% faster for classic themes. Server-side performance is seeing a major boost of 17-23% for block themes and 3-5% for classic themes. These changes demonstrate WordPress’s continued commitment to ensuring that websites built on the platform are optimized for performance.

This builds on efforts done in the past that you can read about in the following posts: Need for Page/Post Speed and Performance Matters.

Thank you to @oandregal and @flixos90 for collaborating on this post!

What’s changed

theme.jsonJSON JSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML. APIs

Leading up to WordPress 6.2, theme.json related code received more performance related attention partially thanks to an understanding that this newer configuration file has an important role to play in the future of themes. This work aimed to improve Time To First Byte (TTFB), a metric related to server-side performance. It focused on three aspects:

According to this analysis, caching wp_get_global_settings had the most impact in the release, improving classic themes by 9% and block themes by 24%. For context, while wp_get_global_settings was introduced in WordPress 5.9, it’s usage expanded to cover many more use cases, including querying data for rendering front-end blocks. As a result, it benefitted immensely from caching the response.

Lazy-loading images for block themes

While Time To First Byte (TTFB) was a big focus of the 6.2 release, there was also a major change to Largest Contentful Paint, the main user-perceived performance metric: the first image or iframeiframe iFrame is an acronym for an inline frame. An iFrame is used inside a webpage to load another HTML document and render it. This HTML document may also contain JavaScript and/or CSS which is loaded at the time when iframe tag is parsed by the user’s browser. of the post will no longer be lazy loaded for block themes.

As a reminder, lazy-loading images landed in WordPress 5.5. After an analysis reported that lazy loading images above the fold negatively impacted user-perceived performance, a fix landed in WordPress 5.9 with WordPress 6.2 following up to ensure block themes won’t lazy load the first image or iframe.

Front-end metrics

Outside of the work done to directly improve performance, there was also a focus on making front-end metrics readily available to all. The aim being to ensure developers have the necessary information to make new features performant and catch regressions earlier, all aiding in creating performant future major releases. All Pull Requests in the Gutenberg and wordpress-develop repositories now include front-end performance information. This information is also reported in the following places for a more comprehensive look:

  • The Gutenberg dashboard now collects a number of front-end metrics:
    • Largest Contentful Paint (LCP): tracks the overall user-perceived performance.
    • Time To First Byte (TTFB): tracks server-side performance.
    • LCP-TTFB: tracks client-side performance.
  • There is a new WordPress core dashboard that reports the following server-side metrics:
    • Total: tracks server-side performance. Equivalent to TTFB in the GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ dashboard.
    • Before template: tracks the time it takes to dispatch the template_redirect hook.
    • Template: the difference between total time and the time it took to dispatch the tempate_redirect hook.

Get involved

If you’re interested in working on improving performance across the project, make sure to join #core-editor, #core-performance, and attend meetings for both. 

These “CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Editor Improvement…” posts (labeled with the #core-editor-improvement tagtag A directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.)) are a series dedicated to highlighting various new features, improvements, and more from Core Editor related projects. 

#block-themes, #core-editor-improvement, #performance, #themes

Andrei Draganescu 7:10 am on September 27, 2022
Tags: , block themes, , ,   

Navigation Block Fallback Behavior in WP 6.1

In WordPress 6.1 the navigation blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. will have a new fallback behavior.

What is the fallback behavior?

When a theme uses a navigation block in a template part, it’s to control where the navigation should visually be located, for the theme’s UIUI User interface to be consistent, usable, and visually attractive. However, themes developers don’t know beforehand what menus the site has, how many pages, what they’re called and so on.

The fallback behavior is the small heuristics in the navigation block which tries to determine what the block should display by default, when a user activates a theme.

What is the new fall back behavior?

Starting with WordPress 6.1, theme developers and authors can lean on the following fallback behavior of the block:

If the navigation block has inner blocks, it will honor them and display them. If the navigation block is empty, however, then it will initialize the fallback behavior.

The fallback behavior (in both the editor and the front of the site) is:

  • If there are no block menus or classic menus, the block will display a list of available pages using the Page List block.
  • If there are multiple block menus, the navigation block will display the most recently created block menu.

The key changes can be summarized as follows:

  1. Improved consistency.
  2. Page List as default fallback.
  3. Selecting the most recent block menu.

Consistency: previously the fallback behavior was inconsistent between the fronted of the site and the editor. If a theme used an empty navigation block it would display a list of pages on the front, and an empty block in the editor. Now the behavior is consistent between both; the editor mirrors what visitors see on the frontend.

Defaulting to page list: previously, themes which wanted to default to a page list in the editor usually included a page list inner block within the Navigation block. With this update, this is no longer necessary. The navigation block, if empty, will automatically have consistent front and editor behavior, defaulting to a page list.

Selecting the most recent block menu: This part of the fallback behavior is new. In the event a site has multiple block menus, an empty navigation block will display the most recent one.

Theme developers should keep in mind.

Display only

The fallback behavior only affects what the empty navigation block will display. Unless the user edits the navigation block’s default fallback, adding a link, changing a label, converting a page list block to a list of links or selecting another menu, the markup of the template part is not changed.

Default content is still honored.

There is no change to how navigation blocks with inner blocks from theme markup behave. Themes  still include inner blocks in the markup in the event they want to showcase a specific situation, for instance a small three links menu, pointing to #, with some restriction on length of link labels – this will continue to work, just like before, rendering the uncontrolled inner blocks both on the front and in the editor.

Props: @get_dave for editing and technical review, @bph for review

#6-1, #block-themes, #dev-notes, #dev-notes-6-1, #navigation-block

ramonopoly 2:00 am on April 13, 2022
Tags: block themes, ,   

Core Styles and Theme Customization: the next steps

Since WordPress 5.9 ushered in the era of blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. themes, there have been questions and concerns about the relationship between theme and CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. styles in the context of GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/. Much of the feedback centers around the notion of how themes can, or should be able to, override CSSCSS Cascading Style Sheets. generated by Core.

This post provides an update about what is happening and, rather imprecisely, when things will happen.

A summary of the challenge

Gutenberg comes with a mix of bundled CSS: global, preset CSS vars, individual block styles or style attributes and block supports.  

As a result of these different layers, theme authors are running into battles of specificity where they wish to override Core styles. Given the frequency of pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party releases, CSS rules are seen as moving targets.

Part of the challenge is to combine the need for greater transparency and predictability with the customization and control of theme.jsonJSON JSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML.. Thrown into the mix is how the Block Editor approaches and honors styles added by users.

Folks working closely with Gutenberg are thinking about how to address these concerns both in the short and long term. Everyone’s feedback and contributions have been immensely helpful so far. 

As you can imagine, the ambitions are lofty, the parts are many and moving. There remains a lot of work and discussion to undertake, and the answers aren’t all there.

Theme.json and theme CSS

Block themes have introduced a new paradigm into theme development, with Core attempting to absorb many of the common CSS customization burdens that classic themes have had to carry.

This arrangement is apparent at the basic level of pattern and site composition: blocks.

One of the functions of blocks is to express site elements in a consistent manner, and promote consistent customization experience regardless of the theme. This means that site owners can switch between themes and be confident that their theme.json and global style preferences will migrate with little or no friction. 

Overriding CSS, whether layout, preset, or block styles, presents an obstacle to integration and interoperability: visual parity between the frontend and editor becomes more difficult to maintain, upgrades to block internals may conflictconflict A conflict occurs when a patch changes code that was modified after the patch was created. These patches are considered stale, and will require a refresh of the changes before it can be applied, or the conflicts will need to be resolved. with overrides. Custom CSS is, furthermore, less portable across other block themes.

By encouraging theme authors to use theme.json APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. where possible, the hierarchy of “base > theme > user” defined styles can be resolved correctly.

The general response to calls for greater control over themes is to extend the theme.json API. If there is a feature in demand, and it’s not currently available in the API, contributors band together to build it in. For example, to control the ways in which editors can interact with their designs, theme authors can define which style UIUI User interface components are accessible in the editor right down to the block level through the block support API.

When working on styles in Gutenberg, these guiding principles have remained predominant.

The reality however, is that theme authors will do what they can to achieve specific objectives, that is, “to get stuff done” and realize their (or others’) designs. There have been reports of overly-specific generated layout styles, and CSS rules using !important frustrating theme CSS overrides.

Alternative ways of thinking about how styles are expressed have been proposed, and the ensuing discussion has been supremely valuable.

While more communication and documentation around the what, why and how of styles is part of the puzzle, making the theory and intentions behind blocks and block themes compatible with the practical reality is an ongoing preoccupation of many who are working on Gutenberg.

Current initiatives

Folks on the Core team, including me, are monitoring discussions, and are actively working on shorter-term code changes, and longer-term mitigation strategies to make working with CSS more predictable.

At the same time, the goal is to preserve the primacy of theme.json, and look for opportunities to extend its API and reduce the need for manual overriding of block or layout CSS. When considering proposals such as extending theme.json to define settings and styles for block “sections”, the goal becomes even more pertinent.

Shorter term changes relate to bugs or enhancementenhancement Enhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature. features. These potentially include removing !important from preset style rules, and addressing block-specific style issues such as Global Styles: Setting font size for Paragraph impacts Quote Block.

Longer term, there are new discussions around outputting semantic classnames for generated styles and the notion of, for better or worse, holding block or layout classnames to the standards of a public API. The motivation here is for greater consistency in what Core exposes. @isabel_brison expresses eloquently that, regardless of whether something can or should be done via theme.json “sometimes there isn’t a better way to accomplish the goal, and the best we can do in that case is provide a good safety net of consistent and meaningful classnames”.

A vehicle that could unify the management and generation of style and classnames is the nascent Style Engine. The stated goal is to have a “consistent API for rendering styling for blocks, across both client-side and server-side applications”. The barest of bones are in the Gutenberg plugin right now, and there are more iterations on the way. 

Finally, and intertwined with all these efforts, are the plans around increasing layout options. Implicit in this project is a refactor of how we generate and apply layout styles across blocks. Many of the concerns in relation to style and classname generation – predictable and consistent classname hooksHooks In WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same., and customization via theme.json – are guiding this work.

Iterations of the longer term projects will be priorities in upcoming versions of WordPress.

Improving documentation

Official documentation on block editor styles is out there. 

There is, nevertheless, huge scope to improve documentation around the role of in-built block CSS and theme.json styles, for example, answering specific questions on best ways to control layouts or individual blocks and providing how-to guides.

It’s a critical one to get right as we all move forward on this issue, and one that I hope will form part of the projects mentioned above.

How to get involved

While there’s no single solution, or maybe even a right solution, now is a great time to get involved while everyone is still experimenting and planning, and there exists the chance for us to strike a balance between the common styles produced by Core and highly specific requirements of theme authors. 

Compromise will arise from wide input and consultation, so I encourage folks to share their thoughts on the features they’d like to see in theme.json and block themes in general. You can join the discussions surrounding semantic classnames, layout options or the Style Engine, or create a new GithubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ issue or discussion if you have an idea about a new approach.

If you have knowledge to share that would help other contributors, there’s always scope to expand and improve the documentation. 

Thanks for reading this post, and for everyone’s input so far. I look forward to diving into the problem-solving pool with you all.

Thanks to @annezazu, @isabel_brison, @andrewserong, @glendaviesnz and @apeatling for their help with this post.

#block-themes, #core-css, #gutenberg

annezazu 6:07 pm on March 3, 2022
Tags: block themes, , ,   

Core Editor Improvement: Choose your Style

These “CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Editor Improvement…” posts (labeled with the #core-editor-improvement tagtag A directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.)) are a series dedicated to highlighting various new features, improvements, and more from Core Editor related projects. 

With Gutenberg 12.5 and the soon to be released GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ 12.8, a blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. theme author can now bundle multiple sets of Styles with their theme, allowing anyone using the theme to quickly switch between them as shortcuts for customization. These different Style presets can change both settings available, like turning on/off font weight, and style options, like the default color palette. For a practical example of what this looks like, check out the quick demo below showing off how a theme could offer both light and dark Style presets:

You can experience this for yourself locally by using the Twenty Twenty Two theme, creating a new styles folder in the root of the twentytwentytwo theme folder, and dropping this gist in there. 

This Styles feature gets even more exciting when it’s paired with new enhancements like the fonts API in theme.json coming to Gutenberg 12.8. That opens the door for a wide range of styles per theme — look for more and more themes to leverage this in the coming months. The following video shows off some new creative possibilities that are opened up by these new features in combination: 

If you’re a block theme author looking to take advantage of this new feature, dig into the documentation now to learn how to create different style presets and align with the necessary theme structure. 

Thank you to @kjellr for the demos and help writing this post. 

#block-themes, #core-editor, #full-site-editing

Anton Vlasenko 4:29 pm on January 7, 2022
Tags: , block themes, , ,   

State of the Customizer with block themes in WordPress 5.9

With WordPress 5.9 bringing support for block themes, this results in a few changes to how the CustomizerCustomizer Tool built into WordPress core that hooks into most modern themes. You can use it to preview and modify many of your site’s appearance settings. works and how one can preview themes.

At a high level, this post covers how blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. themes cannot be previewed due to the introduction of the Site Editor and how the Customizer itself will only appear if a non-block theme is activated or a site has a pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party that interacts with the Customizer.

Previewing block themes

If you activate a non-block theme like Twenty Twenty-One, open the Customizer, and click on the Change button in the Active theme section, you will see a warning message displayed for each block theme. Please see the example below:

A warning message is displayed for each block theme in the Customizer

It is displayed because the Customizer doesn’t support block themes. They can be customized in the Site Editor instead.

As a result, to customize a block-based theme, you need to activate it first. If you’re concerned about doing so, it’s recommended that you set up a test site first to explore the theme.

Also, it is not possible to preview inactive block themes because the Site Editor only works with the currently activated block theme. This means that the Live Preview button is not displayed for inactive block themes.

Once the ability to preview any block theme in the Site Editor is implemented, it will be possible to enable the Live Preview button for block themes as well.

Previewing non-block themes

Previewing non-block themes works the same way as in WordPress 5.8. Nothing has changed here.

Customizer and block themes

WordPress removes the Customizer from the Appearance menu if a block theme is enabled. Why? Block themes are customizable within the Site Editor rather than the Customizer.

However, if any callback function is registered for the customize_register action, the Customize menu item will be added. This is necessary to ensure compatibility with plugins that still require the Customizer to be present in the Appearance menu.

Because the Customizer shows up conditionally, various links have been adjusted depending on the type of active theme to ensure a smooth user experience.

For example, if a block theme is activated, the link in the Welcome banner leads to the Site editor. However, if a non-block theme is active, it leads to the Customizer.

Summary

If you need to preview or edit a block theme, activate it first. Previewing non-block themes will continue to work the same way.

WordPress will only add the Customize menu item if a non-block theme is activated or a plugin interacts with the Customizer (please see the customize_register action).

TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. tickets: #54549 (warning messages for block themes in the Customizer), #54460 (change links depending on the type of active theme), #54337 (conditionally show the Customizer in the Appearance menu).

Props to @annezazu and @hellofromtonya for technical review and proofreading; props to @audrasjb for proofreading; props to @desrosj for providing general feedback on this post.

#5-9, #block-themes, #customize, #customizer, #full-site-editing