The Crowdstrike disaster is good…

The Crowdstrike disaster is a good opportunity for us to brainstorm and review our “defense in depth” around updates. If I committed a die(); to coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress., what happens? What if I modify the file on the server directly? What automated fail-stops can we build in? How can WordPress clients also protect themselves? (We do some decent stuff here already for failed updates.)

It’s our ethical duty as engineers to make sure these systems fail gracefully when something goes wrong, because it’s guaranteed that it will at some point.

WordPress 6.7 Planning Proposal & Call for Volunteers

  • Please leave your feedback about the schedule and release squad size in the comments by July 19th.
  • If you are interested in participating in WordPress 6.7’s release squad as a lead, please show interest in the comments below, clearly specifying the role.

With WordPress 6.6 almost ready, it’s time to start planning WordPress 6.7 so that the release leads can participate from the start of the release cycle.

The timeline for the third release of 2024 takes into consideration WordCampWordCamp WordCamps are casual, locally-organized conferences covering everything related to WordPress. They're one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. Learn more. US in mid-September. To avoid having major milestones (Beta1, RC1) 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 flagship events, this proposal suggests having WordPress 6.7 BetaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. 1 after WordCamp US with a small buffer in between.

According to the schedule proposed below and 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/ release cadence, WordPress 6.7 would include up to Gutenberg 19.3 for a total of 8 Gutenberg releases.

Proposed WordPress 6.7 Schedule

MilestoneDate
Alpha (trunktrunk A directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running "trunk", then you are on the latest revision. open for 6.7 release)June 25, 2024
Last Gutenberg RCrelease candidate One of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta). before Beta 1September 18, 2024
Beta 1October 1, 2024
Beta 2October 8, 2024
Beta 3October 15, 2024
Release Candidaterelease candidate One of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta). 1October 22, 2024
Release Candidate 2October 29, 2024
Release Candidate 3November 5, 2024
Dry RunNovember 11, 2024
WordPress 6.7 General ReleaseNovember 12, 2024

Please leave your feedback about the schedule in the comments by July 19th.

Release Leads call for volunteers

With the recent switch to using the microsite as the base for the About page, some of the Marcomms lead’s responsibilities increasingly overlap with the Design Lead. Considering recurring feedback about the excessive number of release roles, we propose experimenting with combining the Marcomms and Release Coordination roles. This new consolidated role would absorb the duties of the Marcomms lead, streamline communication, and enhance collaboration, addressing the feedback on role complexity and redundancy while improving overall efficiency.

Leads in the squad should have proven experience and availability during the release cycle. Less experienced folks and newcomers are still welcome to follow along the process in preparation for future releases.

Some roles have already been filled by volunteers from the previous call, while others remain open. The TBDs in the list below indicate the number of spots that still need to be filled.

  • Release LeadRelease Lead The community member ultimately responsible for the Release.: Matt Mullenweg
  • Release Coordination and Communications: TBD
  • CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Tech Leads: Peter Wilson, Kira Schroder
  • Editor Tech Leads: Robert Anderson, Kai Hao
  • Triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. Leads: TBD
  • Documentation Leads: TBD
  • Test Lead: TBD
  • Design Lead: TBD
  • Performance Lead: TBD
  • Default Themes Lead: TBD

All release decisions will ultimately be this release team’s to make and communicate while gathering input from the community.

As a reminder, if you are interested in participating in WordPress 6.7’s release squad as a lead or as a cohort, please show interest in the comments below, specifying the desired role and level of involvement (lead/cohort).


Props to @peterwilsoncc for kicking off this post, and @chanthaboune and @cbringmann for reviewing it.

#planning #6-7

WordPress 6.6 Field Guide

This guide outlines major developer features and breaking changes in 6.6 and is published in the Release Candidaterelease candidate One of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta). cycle to help inform WordPress extending developers, CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. developers, and others.

There are almost 299 Core TRACTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. tickets included in WordPress 6.6, 108 of which are enhancements and feature requests, 171 bug fixes, and 10 other blessed tasks. This time, 16 tickets focused on performance, 24 on accessibility, and 15 on modernizing code and applying coding standards. Changes in 6.6 are spread across 40 Core components.

This release includes 392 enhancements, 462 bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. fixes, and 46 accessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) improvements for the Block Editor (a.k.a. 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/).

Below is the breakdown of the most important developer-related changes included in WordPress 6.6.


Table of contents


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

    WordPress 6.6 brings 8 Gutenberg releases into core – 17.8, 17.9, 18.0, 18.1, 18.2, 18.3, 18.4, and 18.5. The Block Editor receives several improvements related to the ReactReact React is a JavaScript library that makes it easy to reason about, construct, and maintain stateless and stateful user interfaces. https://reactjs.org/. library, the Block 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., Themes, and more.

    React

    A new version of React and the new JSX transform is available in WordPress 6.6.

    Block API

    Some Block API improvements available in WordPress 6.6 include:

    • Unification of slots and extensibility APIs between the post and site editors
    • Improvements on isActive property of Block variations
    • Improvements on some core blocks
    • Block Bindings: Editing custom fields from connected blocks

    Themes

    WordPress 6.6 introduces several theme-related updates, including:

    • A new version 3 of theme.json
    • Uniform CSSCSS Cascading Style Sheets. specificity applied across core styles
    • Introduction of section styles to streamline the styling of blocks and their internal elements
    • Additional features for the grid layout type in blocks
    • Capability to define site-wide background images in theme.json and the Site Editor

    Miscellaneous Block Editor Changes

    Some other updates to the Block Editor are also included in WordPress 6.6:

    A table on design tools supported per block at WordPress 6.6 has been published as a reference.

    Interactivity API

    WordPress 6.6 includes updates for the Interactivity API, such as new async directives, support for derived state props from PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher, integration with Preact Devtools, and new warning messages available when the SCRIPT_DEBUG configuration constant is enabled.

    HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. API

    WordPress 6.6 includes a helpful maintenance release to the HTML API. This work includes a few new features and a major improvement to the HTML Processor’s usability. This continues the fast-paced development since WordPress 6.5.

    There’s also a new data structure coming in WordPress 6.6 for the HTML API: the WP_Token_Map.

    Options API

    Several changes have been made to the Options API to support an optimization for the autoloading behavior, and to create a way to apply further optimizations going forward.

    PHP Support

    Support for PHP 7.0 and 7.1 is dropped in WordPress 6.6.

    I18Ni18n Internationalization, or the act of writing and preparing code to be fully translatable into other languages. Also see localization. Often written with a lowercase i so it is not confused with a lowercase L or the numeral 1. Often an acquired skill.

    Various internationalization (i18n) improvements are in WordPress 6.6, including:

    Miscellaneous Developer Changes

    Some other changes included in WordPress 6.6 are:

    Other updates

    One of the highlight features included in WordPress 6.6 is the automatic rollback 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 auto-updates upon detecting PHP fatal errors.

    New/Modified 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.

    For a list of all new and updated Functions/Hooks/Classes/Methods in WP 6.6, please see this page on Developer Resources after the release: https://developer.wordpress.org/reference/since/6.6.0/.

    Modified FilterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. Hooks

    New Filter Hooks

    • interactivity_process_directives [58234]
    • wp_theme_files_cache_ttl [58025]
    • wp_default_autoload_value [57920]
    • wp_max_autoloaded_option_size [57920]
    • wp_autoload_values_to_autoload [57920]
    • lang_dir_for_domain [58236]
    • activate_tinymce_for_media_description [58372]
    • site_status_autoloaded_options_action_to_perform [58332]
    • site_status_autoloaded_options_size_limit [58332]
    • site_status_autoloaded_options_limit_description [58332]

    New Action Hooks

    • delete_post_{$post->post_type} [57853]
    • deleted_post_{$post->post_type} [57853]

    Props to @sabernhardt, @milana_cap, @stevenlinx and @bph for review.

    #6-6, #dev-notes, #field-guide

    What would you like to see in the next default WordPress theme?

    The most recent default theme, Twenty Twenty-Four, has been praised for its design and flexibility. It is time to start thinking about Twenty Twenty-Five, which will be released with WordPress 6.7 in November 2024. Twenty Twenty-Five will be a block theme showcasing new Site Editing features introduced this year.

    Share your ideas

    • What types of sites do you want to create with the theme?
    • What problems do you need the theme to solve to be able to create these sites?
    • Is there an existing feature that you want the theme to support?

    Please add your comments below. Feedback and ideas will be collected continuously. You are also welcome to participate in the discussions on the GitHub repository and in the #core-themes channel on WordPress SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/..

    Note: Ideas won’t necessarily guarantee inclusion in Twenty Twenty-Five but might be considered when creating other community themes.

    More information will be provided later for those who would like to contribute to the theme with design, code, testing, or documentation.

    Props to @poena, @kafleg, @richtabor, @onemaggie and @karmatosed for reviewing this post.

    WordPress 6.6.1: An upcoming maintenance release

    WordPress 6.6.1 is scheduled to be the first maintenance release for the 6.6 version. This is a quick cycle release to fix a few high impact bugs. It is expected that there will be additional maintenance releases during this cycle.

    Its release will follow the following preliminary schedule:

    • July 18, 2024 – Release Candidaterelease candidate One of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta). made available and announced here on the make/coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. site.
    • July 23, 2024 – Final release made available.

    Specific times will be decided in advance and adjustments to the schedule may be made. All adjustments will be noted in this post.

    Minor or Maintenance releases of WordPress are intended as bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority.-fix releases. If you have a TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. ticketticket Created for both bug reports and feature development on the bug tracker. that you think should be considered, please put it in the 6.6.1 milestone. If you have a 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, please add it to the 6.6.x Editor Tasks board. If you lack bug gardening capabilities and have a ticket or issue you wish to highlight for 6.6.1, please add a comment here.

    Note: except in extreme situations, only bug fixes will be considered and generally only bugs that have been introduced during the 6.6 cycle.

    General coordination for the release will happen in the #6-6-release-leads channel and decisions around code for the release will be made in the #core room.

    This minor releaseMinor Release A set of releases or versions having the same minor version number may be collectively referred to as .x , for example version 5.2.x to refer to versions 5.2, 5.2.1, 5.2.3, and all other versions in the 5.2 (five dot two) branch of that software. Minor Releases often make improvements to existing features and functionality. will be led by @ellatrix and myself (@hellofromtonya).

    Thank you to @davidbaumwald and @jorbin for pre-publication review.

    #6-6, #6-6-x

    Theme.json version 3

    The 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. version is incremented whenever a breaking change would need to be made to 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.. This allows consumers to opt-in to the breaking change by updating the version. Older theme.json versions will always be supported in the latest versions of WordPress.

    Updating to version 3 is recommended when your minimum supported WordPress version reaches 6.6. See theme.json version 3 frequently asked questions for more information on when to update. Then check out the theme.json reference for migrationMigration Moving the code, database and media files for a website site from one server to another. Most typically done when changing hosting companies. instructions when you are ready to update.

    Breaking changes in version 3

    Starting with theme.json version 3 the default behavior for using the same slugs as the default fontSizes and spacingSizes presets has been changed to match how other theme.json presets work: from always overriding the default presets to requiring defaultFontSizes or defaultSpacingSizes to be false in order to override the default presets.

    Default font sizes

    settings.typography.defaultFontSizes is a new option in theme.json v3. It controls whether the coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. provided default settings.typography.fontSizes presets are shown and used.

    The default fontSizes presets’ slugs are: small, medium, large, and x-large.

    • When defaultFontSizes is true it will show the default font sizes in the editor and prevent the theme from creating presets using the default slugs.
    • When defaultFontSizes is false it will hide the default font sizes in the editor and allow the theme to use the default slugs.

    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 defaultFontSizes is true by default. This is consistent with how other default* options work such as settings.color.defaultPalette.

    For classic themes there is a new theme support default-font-sizes which is also true by default. However, unlike block themes, it is set to false when editor-font-sizes theme support is defined.

    In theme.json v2, the default font sizes were only shown when theme sizes were not defined. A theme providing font sizes with the same slugs as the defaults would always override the defaults.

    To keep behavior similar to v2 with a v3 theme.json:

    • If you do not have any fontSizes defined, defaultFontSizes can be left out or set to true.
    • If you have some fontSizes defined, set defaultFontSizes to false.
    --- theme.json v2
    +++ theme.json v3
    @@ -1,24 +1,25 @@
     {
    -	"version": 2,
    +	"version": 3,
     	"settings": {
     		"typography": {
    +			"defaultFontSizes": false,
     			"fontSizes": [
     				{
     					"name": "Small",
     					"slug": "small",
     					"size": "10px"
     				},
     				{
     					"name": "Medium",
     					"slug": "medium",
     					"size": "14px"
     				},
     				{
     					"name": "Large",
     					"slug": "large",
     					"size": "20px"
     				}
     			]
     		}
     	}
     }
    

    Default spacing sizes

    settings.spacing.defaultSpacingSizes is a new option in theme.json v3. It controls whether the core provided default settings.spacing.spacingSizes presets are shown and used.

    The default spacingSizes presets’ slugs are: 20, 30, 40, 50, 60, 70, and 80.

    • When defaultSpacingSizes is true it will show the default spacing sizes in the editor and prevent the theme from creating presets using the default slugs.
    • When defaultSpacingSizes is false it will hide the default spacing sizes in the editor and allow the theme to use the default slugs.

    defaultSpacingSizes is true by default. This is consistent with how other default* options work such as settings.color.defaultPalette.

    For classic themes there is a new theme support default-spacing-sizes which is also true by default. However, unlike block themes, it is set to false when editor-spacing-sizes theme support is defined.

    In theme.json v2, the default spacing sizes were only shown when theme sizes were not defined. A theme providing spacing sizes with the same slugs as the defaults would always override the defaults.

    Furthermore, there are two settings that can be used to set theme level spacing sizes: spacingSizes and spacingScale. With theme.json v3, presets from both will be merged together and sorted numerically by slug. Presets defined in spacingSizes will override those generated by spacingScale if the slugs match.

    In theme.json v2, setting both spacingSizes and spacingScale would only use the values from spacingSizes.

    To keep behavior similar to v2 with a v3 theme.json:

    • If you do not have any spacingSizes presets or spacingScale config defined, defaultSpacingSizes can be left out or set to true.
    • If you disabled default spacing sizes by setting spacingScale to { "steps": 0 }, remove the spacingScale config and set defaultSpacingSizes to false.
    • If you defined only one of either spacingScale or spacingSizes for your presets, set defaultSpacingSizes to false.
    • If you defined both spacingScale and spacingSizes, remove the spacingSizes config and set defaultSpacingSizes to false.
    --- theme.json v2
    +++ theme.json v3
    @@ -1,27 +1,25 @@
     {
    -	"version": 2,
    +	"version": 3,
     	"settings": {
     		"spacing": {
    -			"spacingScale": {
    -				"steps": 0
    -			},
    +			"defaultSpacingSizes": false,
     			"spacingSizes": [
     				{
     					"name": "Small",
     					"slug": "40",
     					"size": "1rem"
     				},
     				{
     					"name": "Medium",
     					"slug": "50",
     					"size": "1.5rem"
     				},
     				{
     					"name": "Large",
     					"slug": "60",
     					"size": "2rem"
     				}
     			]
     		}
     	}
     }
    

    Props to @scruffian and @juanmaguitar for assistance with writing and reviewing this post.

    #6-6, #dev-note, #dev-notes, #dev-notes-6-6

    WordPress 6.6 CSS Specificity

    One of the goals of WordPress 6.6 is to simplify the process for theme authors to override coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. styles while also maintaining support for Global Styles.

    Historically, high CSSCSS Cascading Style Sheets. specificity in core styles has made customization challenging and unpredictable, often requiring complex CSS rules to achieve desired outcomes. Development of the new section styles feature also highlighted a need for uniform CSS specificity to support nesting such styles, facilitating the creation of sophisticated, layered designs.

    Uniform 0-1-0 Specificity

    WordPress 6.6 introduces several changes aimed at broadly reducing CSS specificity and making it more uniform. These changes generally fall into two categories:

    1. Core 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. Styles
    2. 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. / Global Styles:

    Where adjustments to CSS specificity were required, they were achieved by wrapping the existing selector within :root :where(...).

    Core Block Styles

    The choice of 0-1-0 specificity greatly reduced the changes required to existing core block styles as blocks targeting their default .wp-block- class already have the desired specificity.

    Any blocks with Global Styles support using higher specificity selectors had those selectors wrapped in :root :where(...). This also applied to Block Styles (aka block style variations) and their default styles e.g., .wp-block-image.is-style-rounded img was updated to :root :where(.wp-block-image.is-style-rounded img).

    Theme.json / Global Styles:

    All block styles, including block style variation styles, output by theme.json and Global Styles are now limited to 0-1-0 specificity. Layout styles, e.g., constrained, flex, flow` etc., have also been limited however depending on the specific layout type and definition the final specificity varies slightly from 0-1-0 so they apply correctly.

    Usage

    The alignment of 0-1-0 specificity for Global Styles to default block selectors, e.g. .wp-block-, greatly reduces the need for updates. It’s recommended for theme and block authors to double-check their designs if they rely on custom CSS using more complex selectors.

    Custom blocks

    Authors of custom blocks that opt into global styles and apply default styling via a selector with greater than 0-1-0 specificity, should update those selectors wrapping them in :root :where().

    An example could be a custom list block that opts into padding block support but defines default padding via:

    ul.wp-block-custom-list {
        padding: 0;
    }
    

    Without adjusting the specificity of this rule, any customizations of the block type’s padding in Global Styles would be overridden. Wrapping the selector in :root :where() here would allow the style load order to determine which rule takes precedence.

    // Block's stylesheet
    :root :where(ul.wp-block-custom-list) { // This is a contrived example and could simply be `.wp-block-custom-list`
        padding: 0;
    }
    
    // Global Styles - Loaded after the block styles
    :root :where(.wp-block-custom-list) {
        padding: 1em;
    }
    

    Block Styles (aka Block Style Variations)

    Theme authors customizing Block Styles for a core block will need to limit their style’s specificity, so the block style continues to be configurable via Global Styles.

    For example, take a theme that tweaks the border radius for the Image block’s rounded block style:

    .wp-block-image.is-style-rounded img {
        border-radius: 2em;
    }
    

    Without adjustment, this style would override any customizations made to the Rounded block style within Global Styles.

    In this case, the theme can tweak its rounded image style to the following:

    //. Theme style
    :root :where(.wp-block-image.is-style-rounded img) {
        border-radius: 2em;
    }
    
    // Global Styles - Loaded after the block styles
    :root :where(.wp-block-image.is-style-rounded img) {
        border-radius: 4px;
    }
    

    Zero-Specificity, CSS Layers, and the future

    Reducing all core styles to zero specificity was explored before settling on 0-1-0 specificity. Zero specificity unfortunately wasn’t robust in the face of common reset stylesheets and required more widespread changes.

    CSS Layers were also evaluated but fell short due to not being able to enforce all styles belonged to a layer. This will change in the future at which point a combination of CSS Layers and zero-specificity can be revisited to further the benefits gained in this initial reduction of CSS specificity.

    More history and context can be found in this detailed discussion.

    Useful Links

    Props to @bph and @juanmaguitar for review

    #6-6, #core-editor, #dev-note, #dev-notes, #dev-notes-6-6, #gutenberg

    JSX in WordPress 6.6

    WordPress 6.6 introduces the possibility for developers to use the new React JSX transform that was first released in ReactReact React is a JavaScript library that makes it easy to reason about, construct, and maintain stateless and stateful user interfaces. https://reactjs.org/. 17. 

    How to use the new JSX in WordPress 6.6

    Your build scripts need to apply the following changes in the built files:

    • Add the react-jsx-runtime to your script dependencies.
    • Use ReactJSXRuntime.jsx global as the output of your JSX calls.

    In general, this is not something you do manually in your code base. Instead, you’ll use a build tool. The @wordpress/scripts, @wordpress/babel-preset-default and  @wordpress/dependency-extraction-webpack-plugin npm packages have been upgraded to apply these transformations automatically.

    Build Tools Compatibility and upgrade path

    If you’re using the JSX syntax in your code base, and as long as you don’t update your dev dependencies (including @wordpress/scripts, @wordpress/babel-preset-default or @wordpress/dependency-extraction-webpack-plugin), you will continue to use the old JSX transform. This will allow your 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 and built files to be compatible with WordPress 6.5, earlier versions and WordPress 6.6 as well.

    When you’re ready to make WordPress 6.6 the minimum supported version of your plugin, you can update the following dependencies to use the new JSX transform.

    • @wordpress/scripts from version 28.
    • @wordpress/babel-preset-default from version 8.
    • @wordpress/dependency-extraction-webpack-plugin from version 6.

    Going forward

    The new JSX transform comes with performance improvements and optimization. 

    Note that the React team will deprecate the old JSX transform in the upcoming React v19 release (currently in RC). 


    Thank you @ramonopoly @justlevine for contributing to and reviewing this post.

    #6-6, #dev-note, #dev-notes, #dev-notes-6-6

    Proposal: Block Variation Aliases

    To provide an easy way 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. authors to specify variations of a given block that only differ in some attributes and/or inner blocks, WordPress has been providing the Block Variations mechanism, first introduced in version 5.4. This mechanism is widely used in CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. itself; for example, the Group block has “Row”, “Stack”, and “Grid” variations (that can be selected from the block inspector); the Social Icon block has variations for individual social networks, e.g. wordpress, tumblr, etc.

    For WordPress 6.7, we’d like to propose some changes to Block Variations, most notably the following:

    1. Add a variation-specific class name to the block wrapper (i.e. wp-block-${blockName}-${variationName} in addition to the existing wp-block-${blockName}).
      1. Implement server-side detection of the active block variation.
    2. Include the variation name in block markup persisted in the database (e.g. <!-- wp:core/social-link/wordpress {"url":"wordpress.org","service":"wordpress"} /-->).

    Below, we discuss each of these suggested changes in more detail.

    Add a variation-specific class name to the block wrapper

    TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. Ticketticket Created for both bug reports and feature development on the bug tracker.: #61265. 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/ PR: #61864.

    Adding a variation-specific class name will allow block authors to style individual variations of their blocks differently. Some blocks do this already on an individual basis, e.g. the Social Icon block adds a wp-block-social-link-${service} class name.

    There is a number of questions that need to be answered here:

    First, should a block need to opt in to having the variation class name added, or should it be added automatically? Since there’s already the className block-supports flag – which also controls the addition of the “default” wp-block-${blockName} class name – it might make sense to couple the variation class name to the same flag.

    Second, how should existing block markup be handled? There’s the precedent of block deprecations (and migrations) which applies changes to existing blocks when they’re edited – and leaves them otherwise unchanged. If we follow this pattern (albeit probably not on an individual block level but more globally), blocks won’t get the variation class name added as long as the existing markup is not edited.

    A different strategy was chosen for the List block whose wrapper element was only recently given the wp-block-list default class name. Here, a server-side render callback was added to inject the new class name into the (otherwise static) existing block markup; i.e., existing List blocks now have the wp-block-list class name added to their wrapper element on the frontend, even if they’re never edited.

    In Gutenberg PR #61864, we’ve opted against introducing a new block-supports flag for the variation-specific class name; furthermore, the new class name is currently only added to existing markup when editing it.

    If we want a mechanism to add the wp-block-${blockName}-${variationName} class name on the frontend, we need to be able to infer the active block variation for a given block on the server side. This problem is covered in the next section.

    Implement server-side detection of the active block variation

    Core PR: #6602

    Block variations support an isActive property to determine if a given block instance matches the variation, i.e. if the variation is active. That property can either be a 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/. function (only if registration of the variation happens on the client side) or an array of block attribute names to compare.

    In order for the block variation class name to be added on the server side – which is required to include it on the frontend for dynamic blocks, or for existing static blocks (see previous section) – the server needs to be able to determine which variation is active. To that end, there needs to be a server-side counterpart to the client’s getActiveBlockVariation function that, given the same set of variations, yields the same result. (Note some recent improvements made to the client-side function that the server would need to reproduce.)

    Include the variation name in block markup persisted in the database

    Gutenberg Issue: #43743. PR: #61678 (experimental).

    Finally, we propose to append the variation name (separated by a slash) to the block type name that’s used in block delimiters when persisting markup to the database, so that e.g.  <!-- wp:social-link {"url":"wordpress.org","service":"wordpress"} /--> becomes <!-- wp:core/social-link/wordpress {"url":"wordpress.org","service":"wordpress"} /-->.

    This was first proposed by #43743 for the following reasons:

    To allow theme developers and users to customize block variations’ styles granularly, e.g. in theme.json, or in the Global Styles panel (#40621). As a corollary, this would allow for an optimization, by attaching variation-specific CSSCSS Cascading Style Sheets. only when the corresponding block variation is present.

    Developers could furthermore benefit from all other Block 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. tools that work on a block type basis. For example, it could be possible to limit usage of a given block variation as another block’s child block via the allowedBlocks field, or to limit the number of instances of a variation in a given post via multiple block support.

    One particularly noteworthy example of how block variations can unlock some desirable enhancements for other features is the Block Hooks API: It is currently not possible to use it to insert multiple blocks in the same position if they share the same block type (and are only distinguished by their attributes). Including variation names in the persisted block names can solve this problem, allowing multiple different variations of the same block to be inserted as hooked blocks in the same position.

    Finally, using named block variations in persisted markup would give easier access for site owners to the content analysis to determine which blocks and variations are used in posts and templates.

    Architecture

    Note that while this change would affect the persisted markup, we would seek to contain it there, so that it becomes at once available to some tooling but doesn’t affect everything else adversely. Specifically, we’re not planning to introduce a separate WP_Block_Type object for every single variation; even for WP_Block class instances, we’re currently thinking to strip the /${variationName} part from the block type name upon construction. This way, the appended variation name would be confined to the lowest level of block markup processing, i.e. the “parsed block format” that parses block markup into nested arrays that look as follows:

    array(
    	'blockName'    => 'core/social-link/wordpress',
    	'attrs'        => array(
    		'service' => 'wordpress',
    		'url'     => 'wordpress.org',
    	),
    	'innerBlocks'  => array(),
    	'innerContent' => array(),
    );
    
    

    Note that this parsing step – unlike the later creation of WP_Block objects – is “dumb” in that it doesn’t have any knowledge of what blocks and block variations are registered.

    Furthermore, we would shield the client from this new format by simply removing the appended /${variationName} upon loading the markup in the editor, and by re-appending it upon saving, i.e. when loading markup like <!-- wp:core/social-link/wordpress {"url":"wordpress.org","service":"wordpress"} /--> , it will be transformed into  <!-- wp:social-link {"url":"wordpress.org","service":"wordpress"} /-->  (and back when saving it).

    Generated vs arbitrary aliases

    Note that #43743 originally proposed allowing arbitrary aliases (e.g. wp:core/wordpress-link). Arbitrary aliases would allow some further improvements that go beyond what is possible with generated aliases. For example, a number of Core blocks could be redefined as variations of other (simpler) Core blocks, by using Block Bindings: For instance, the Post Title block could be redefined as an alias of a variation of the Heading block, where the latter’s content is bound to the current post’s title (which is done via the block’s metadata.bindings attribute and can thus be used to define the variation).

    Another benefit of arbitrary aliases is that they do not require the server to determine the active block variation based on the block’s attribute values, as that information is already contained in the alias.

    While we’re considering arbitrary aliases for a later stage, we’d like to start by using the information that’s readily available (the block and variation names) rather than introducing a new alias field; it also simplifies the required transformation in the editor (which can simply remove the /${variationName} suffix; inferring the correct variation name on the client side to re-attach it upon saving is no different than determining the active variation via getActiveBlockVariation).

    Conclusion

    We’re curious to hear your thoughts and feedback on these suggestions, and on the architecture we’re having in mind. Please use the comments below this post to share your feedback on this proposal. Alternatively, you can comment on the individual Trac tickets, issues, and pull requests linked from it.

    The feedback period for this proposal will end in three weeks’ time, on 2024-07-14, in order to give us enough time for implementation.

    Props @gziolo and @tjcafferkey for review.

    Hallway Hangout: Section styles and other block style variation updates

    WordPress 6.6 expands block style variations in several ways, giving you the ability to do more with the existing feature, such as

    • Define styles for registered variations via `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.`.
    • Style nested elements and blocks.
    • Create “section styles” that are connected to one or more blocks.
    • Overwrite section styles via theme style variations.

    At a technical level, the expanded tool set does not add too many new concepts to learn. However, in practice, working with these updates can present challenges and may even have you rethinking your approach to theme design.

    You can learn more about the updates here:

    Join us for a Hallway Hangout on July 8th, 2024  at 16:00 UTC for an early discussion around how these tools work and what they mean for themes. The zoom link will the provided in the #outreach channel on SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/..

    Props for drafting to @greenshady and for review to @juanmaguitar

    #hallway-hangout