Summary, Dev Chat, August 7, 2024

Start of the meeting in 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/., facilitated by @joemcgill. 🔗 Agenda post.

Announcements

There were no announcements this week.

Forthcoming Releases

Next major releasemajor release A release, identified by the first two numbers (3.6), which is the focus of a full release cycle and feature development. WordPress uses decimaling count for major release versions, so 2.8, 2.9, 3.0, and 3.1 are sequential and comparable in scope.: 6.7

We are currently in the WordPress 6.7 release cycle. 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 is scheduled for Tuesday, October 1.

Next 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.: 6.6.2

The next maintenance release will be 6.6.2 and will likely be released at the end of the month, likely August 26 with RC1 the week before.

Next 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: 19.0

Gutenberg 19.0 is scheduled for August 14. RC1 was released on August 7.

Discussion

@joemcgill led with this reminder:

WordCamp US is coming up on September 17–20, and @courane01 has begun requesting table leads from all the Make teams for Contributor DayContributor Day Contributor Days are standalone days, frequently held before or after WordCamps but they can also happen at any time. They are events where people get together to work on various areas of https://make.wordpress.org/ There are many teams that people can participate in, each with a different focus. https://2017.us.wordcamp.org/contributor-day/ https://make.wordpress.org/support/handbook/getting-started/getting-started-at-a-contributor-day/.. We can use some time to discuss this and answer any questions folks might have.

Open Floor

#53817 was raised in the agenda comments. We discussed that this issue should be opened in the Gutenberg repo instead of TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress., which @hellofromtonya offered to handle.

Next, we discussed #51525. @mathieulamiotwpmedia described where the ticketticket Created for both bug reports and feature development on the bug tracker. was up to:

We are interested in this possible enhancementenhancement Enhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature. for a while and we built a library that we currently use based on the ticket’s discussions. Having this directly in CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. would open up a few possibilities to make apply_filters typing more resilient, but it was never really clear in the ticket discussion if such approach could make it to the Core at some point.

So, we suggest a patchpatch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing. based on the library we built, and it would be great to get feedbacks from Core maintainers. First, to know whether or not it’s worth pursuing the effort on this, from a WP Core perspective. And if yes, what could be next steps

The ticket itself is loaded with information and context, and the patch itself might not be easy to assess right here right now ; but I thought we could bring this up here to maybe follow-up on it asynchronously. That’s it, I guess!

We discussed whether this should be included in Core, how it could be used, or if it is intended as a shared 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. that plugins and themes would use.

Finally, @swissspidy mentioned this merge proposal for Preferred Languages that resulted in some good feedback, including:

  • Concerns that core starts consuming GB packages outside of the editor
  • Tooling limitations in core (no TypeScript, no ESLint, no Jest tests)
  • Concerns about adding TypeScript to core (implications for build server etc.)
  • Need to have performance tests with fallback chain as well

@swissspidy will publish a new make/core post following this feedback.

Note: Anyone reading this summary outside of the meeting, please drop a comment in the post summary, if you can/want to help with something.

Props to @joemcgill for proofreading.

#6-7, #core, #dev-chat, #summary

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

Agenda, Dev Chat, Wednesday Aug 7, 2024

The next WordPress Developers Chat will take place on  Wednesday August 7, 2024 at 20:00 UTC in the core channel on Make WordPress Slack.

The live meeting will focus on the discussion for upcoming releases, and have an open floor section.

Additional items will be referred to in the various curated agenda sections, as below. If you have ticketticket Created for both bug reports and feature development on the bug tracker. requests for help, please do continue to post details in the comments section at the end of this agenda.

Announcements

There are no announcements from the last week.

Forthcoming releases

Next major releasemajor release A release, identified by the first two numbers (3.6), which is the focus of a full release cycle and feature development. WordPress uses decimaling count for major release versions, so 2.8, 2.9, 3.0, and 3.1 are sequential and comparable in scope.: 6.7

We are currently in the WordPress 6.7 release cycle. 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 is scheduled for Tuesday, October 1.

Next maintenance release: 6.6.2

The next maintenance release will be 6.6.2. No release date is currently set.

Next 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: 19.0

Gutenberg 19.0 is scheduled for August 14.

Discussions

Reminder: WordCamp US is coming up on September 17–20, and @courane01 has begun requesting table leads from all the Make teams for Contributor DayContributor Day Contributor Days are standalone days, frequently held before or after WordCamps but they can also happen at any time. They are events where people get together to work on various areas of https://make.wordpress.org/ There are many teams that people can participate in, each with a different focus. https://2017.us.wordcamp.org/contributor-day/ https://make.wordpress.org/support/handbook/getting-started/getting-started-at-a-contributor-day/.. We can use some time to discuss this and answer any questions folks might have.

Please suggest other important topics for the agenda in the comments of this post.

Editor updates

You can keep up to date with the major Editor features that are currently in progress by viewing these Iteration issues.

Open floor

Any topic can be raised for discussion in the comments, as well as requests for assistance on tickets. Tickets in the milestone for the next major or maintenance release will be prioritized.

Please include details of tickets / PRs and the links in the comments, and if you intend to be available during the meeting for discussion or if you will be async.

Props to @mikachan for reviewing.

#6-7, #agenda, #dev-chat

Proposal: Adjusting Dev Chat times for the 6.7 release

Background

The weekly WordPress Dev Chat meeting is a tradition that dates back to the days when WordPress contributors primarily communicated via IRC. Since that time, these meetings have continued to serve as a regular time each week where contributors working on CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. releases could gather to have synchronous conversations about important matters related to the upcoming releases or to discuss general team processes.

Given the global nature of the WordPress community, the current time for these Dev Chats are not inclusive to everyone to attend. We experimented with a second APAC Dev Chat starting in 2020 as a way of creating opportunities for folks who could not attend the current time to still participate in a weekly Dev Chat. However, those were not well attended and were eventually abandoned.

Scheduling Dev Chats for WordPress 6.7

Given that the primary purpose of Dev Chats is to have a time for synchronous conversations about the upcoming release, holding them at a time where the majority of named the release squad members for 6.7 are unable to attend isn’t ideal. Let’s consider moving them to a more APAC friendly time during this release.

If we’re trying to find a time that is inclusive to folks from India Standard Time (UTC +5:30) to Australian Eastern Standard Time (UTC +10) then the best times for rescheduling seem to be between 3–10 UTC. The early part of that range could cover some folks in the Americas but not folks in EMEA. Likewise, the latter part of this range could work for a majority of folks from EMEA, but is not ideal for folks in the Americas. Moving the time range earlier, to 0:00 UTC would allow participation from more folks in the Americas, but would exclude folks from EMEA and folks around IST as well. With that in mind, I’m proposing a few options for consideration to gather feedback.

Proposed time options

  1. Wednesdays at 3:00 UTC (Ex: Wednesday, August 7, 3:00 UTC): India, Japan, Australia with some late Americas overlap (no EMEA)
  2. Wednesdays at 10:00 UTC (Ex: Wednesday, August 7, 10:00 UTC): India, Japan, Australia and EMEA (no Americas)
  3. Wednesdays at 0:00 UTC (Ex: Wednesday, August 7, 0:00 UTC): Japan, Australia, Americas (no India or EMEA overap)
  4. Wednesdays at 20:00 UTC (Ex: Wednesday, August 7, 20:00 UTC): No Change – Americas and EMEA (no India, Japan, Australia)

Feedback Deadline: July 31, 2024
Please provide feedback to this proposal before Wed., July 31. In your feedback, let us know if you regularly attend Dev Chats and if you have a role for 6.7 that would be impacted (positively or negatively) by your preferred time. We’ll collect responses and plan to announce an updated schedule before Aug. 7, 2024.

Changing the time following the 6.7 release

Currently, WordPress 6.7 is scheduled for release on Nov 12, 2024. Following this release, we will maintain the updated Dev Chat time to address any post-release wrap up, including confirming another time change for the 6.8 release based on the success of this experiment and the needs of the release squad for that release.

Props to @desrosj, @colorful-tones, and @peterwilsoncc for review and feedback on this proposal.

#6-7, #dev-chat, #proposal

Data Liberation and WordPress Migrations

One thing I heard a lot about when talking to the community about Data Liberation was the challenge of WordPress-to-WordPress migrations. Exciting news for anyone who has ever struggled with that: those migrations are now going to be an important part of the Data Liberation project.

As Matt mentioned at his WCEU Keynote, “We need to make WordPress to WordPress easier.” That’s what we’ll aim to do.

Making WordPress sites easier to move could free you from being locked into a specific host, let you set up a local staging site to test changes, or even let you take a copy of your whole site as an archive.

Migrations ≠ Importing

This might seem obvious, but it’s important to point out that the WordPress Importer 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 is useful for importing content from an XML file and can definitely be used to migrate content from one site (or host) to another.

But, if the goal is to provide a 1:1 migrationMigration Moving the code, database and media files for a website site from one server to another. Most typically done when changing hosting companies. (or as close as possible), the WordPress Importer is not the tool for the job. No plugins or themes, no settings of wp-config.php, and limited support for media migration mean that we need something more.

Plenty of third-party plugins are filling this gap and meeting user needs, but we should also improve the options within WordPress itself.

Migration challenges

In discussions with hosts and agencies, several recurring challenges emerge regarding migration:

  • Getting adminadmin (and super admin) access to the source site – incorrect username and password, finding hidden login pages, insufficient user privileges, etc.
  • Incompatibilities in PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher version or WP version between source and destination sites.
  • Incompatibilities in supported plugins between source and destination.
  • Incompatibilities in database encoding.
  • Poor server performance/resources of source site (causing backups/migrations to fail or timeout).

Migrations and WordPress Playground

Something I’m particularly excited about is the potential of the WordPress Playground. In fact, the primary proposal for improving WordPress to WordPress migrations, Site Transfer Protocol, leans on the Playground heavily. You can check the details of that proposal in this Trac ticket.

But what about third party platforms to WordPress?

Don’t worry – a focus on WordPress to WordPress doesn’t mean we’re forgetting the need for migration pathways to WP from third-party platforms. There’s more information to come regarding that – but for now you can check out this really interesting proof of concept of a browser extension to copy content from a site and paste it into the editor as Blocks.

Get Involved!

There will be opportunities soon to get your hands dirty in helping build the tools of Data Liberation – but for now, the best way to get involved is to join the Discussion on how best to solve the challenges of migration. I’m really interested in hearing about your experiences with migrating WordPress sites – the challenges, and interesting and clever ways you’ve worked around them!

You can share those experiences in the comments here – or join the  #data-liberation channel in Make Slack to share any feedback, ideas, or comments there!

You can also check out the proposal for Site Transfer Protocol (to standardise WP to WP migrations) and join the discussion there.

Agenda, Dev Chat, Wednesday July 31, 2024

The next WordPress Developers Chat will take place on  Wednesday July 31, 2024 at 20:00 UTC in the core channel on Make WordPress Slack.

The live meeting will focus on the discussion for upcoming releases, and have an open floor section.

Additional items will be referred to in the various curated agenda sections, as below. If you have ticketticket Created for both bug reports and feature development on the bug tracker. requests for help, please do continue to post details in the comments section at the end of this agenda.

Announcements

There are no release announcements from the last week.

Forthcoming releases

Next major releasemajor release A release, identified by the first two numbers (3.6), which is the focus of a full release cycle and feature development. WordPress uses decimaling count for major release versions, so 2.8, 2.9, 3.0, and 3.1 are sequential and comparable in scope.: 6.7

We are currently in the WordPress 6.7 release cycle. 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 is scheduled for Tuesday, October 1.

Next maintenance release: 6.6.2

The next maintenance release will be 6.6.2. We can dedicate some discussion time to any issues that may need to go into the next maintenance release.

Next 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: 18.9

Gutenberg 18.9 is scheduled for July 31.

Discussions

Let’s discuss the latest updates on the release squad for 6.7, and any questions anyone has about the next release.

WordCamp US is coming up on September 17–20, and @courane01 has begun requesting table leads from all the Make teams for Contributor DayContributor Day Contributor Days are standalone days, frequently held before or after WordCamps but they can also happen at any time. They are events where people get together to work on various areas of https://make.wordpress.org/ There are many teams that people can participate in, each with a different focus. https://2017.us.wordcamp.org/contributor-day/ https://make.wordpress.org/support/handbook/getting-started/getting-started-at-a-contributor-day/.. We can use some time to discuss this and answer any questions folks might have.

Please suggest other important topics for the agenda in the comments of this post.

Editor updates

You can keep up to date with the major Editor features that are currently in progress by viewing these Iteration issues.

Open floor

Any topic can be raised for discussion in the comments, as well as requests for assistance on tickets. Tickets in the milestone for the next major or maintenance release will be prioritized.

Please include details of tickets / PRs and the links in the comments, and if you intend to be available during the meeting for discussion or if you will be async.

Props to @joemcgill for reviewing.

#6-7, #agenda, #dev-chat

Section Styles

In WordPress 6.6, Section Styles simplify the process of styling individual sections of a webpage by offering users a one-click application of curated styles, eliminating the need for repetitive manual configuration.

Table of Contents

  1. What’s Changed?
  2. Usage
    1. Registration of Block Style Variations
    2. Defining Block Style Variations
      1. Theme.json Partial Files
      2. Programmatically
      3. Via Theme Style Variations (Not Recommended)
  3. Backwards Compatibility
  4. Limitations
  5. What’s Next?
  6. Useful Links

What’s Changed?

Section-based styling has been enabled by extending the existing Block Styles feature (aka 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. style variations) to support styling inner elements and blocks. These enhanced block style variations can even be applied in a nested fashion due to uniform CSS specificity (0-1-0) for Global Styles introduced in WP 6.6.

In addition block style variations can now be:

  • registered across multiple block types at the same time
  • defined via multiple methods; primarily through 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. partials, or by passing a theme.json shaped object in the style’s data given to existing block style registration functions
  • customized via Global Styles (see also current limitations)

Usage

Registration of Block Style Variations

The block style variations that can be defined and manipulated through Global Styles are limited to those that have been registered with the WP_Block_Styles_Registry or via a block type’s styles property, such as Outline for the Button block. If a block style variation has not been registered, any theme.json or global styles data for it will be stripped out.

Any unregistered block style variation defined within a theme.json partial with be automatically registered.

Outlined below are three approaches to registering extended block style variations. The approaches leveraging theme.json definitions will automatically register the block style variation with the WP_Block_Styles_Registry.

Defining Block Style Variations

Outlined below are recommended approaches to registering extended block style variations.

Theme.json Partial Files

With the extension of block style variations to support inner element and block type styles, they essentially are their own theme.json file much like theme style variations. As such, block style variations also reside under a theme’s /styles directory. They are differentiated from theme style variations however by the introduction of a new top-level property called blockTypes. The blockTypes property is an array of block types the block style variation can be applied to.

A new slug property was also added to provide consistency between the different sources that may define block style variations and to decouple the slug from the translatable title property.

{
	"$schema": "https://schemas.wp.org/trunk/theme.json",
	"version": 3,
	"title": "Variation A",
	"slug": "variation-a",
	"blockTypes": [ "core/group", "core/columns", "core/media-text" ],
	"styles": {
		"color": {
			"background": "#eed8d3",
			"text": "#201819"
		},
		"elements": {
			"heading": {
				"color": {
					"text": "#201819"
				}
			}
		},
		"blocks": {
			"core/group": {
				"color": {
					"background": "#825f58",
					"text": "#eed8d3"
				},
				"elements": {
					"heading": {
						"color": {
							"text": "#eed8d3"
						}
					}
				}
			}
		}
	}
}

Programmatically

Within a theme’s functions.php or 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, a call can be made to register_block_style, passing it an array of block types the variation can be used with as well as a theme.json shaped style object defining the variation’s styles. The style object provided here will be absorbed into the theme’s theme.json data.

register_block_style(
	array( 'core/group', 'core/columns' ),
	array(
		'name'       => 'green',
		'label'      => __( 'Green' ),
		'style_data' => array(
			'color'    => array(
				'background' => '#4f6f52',
				'text'       => '#d2e3c8',
			),
			'blocks'   => array(
				'core/group' => array(
					'color' => array(
						'background' => '#739072',
						'text'       => '#e3eedd',
					),
				),
			),
			'elements' => array(
				'link'   => array(
					'color'  => array(
						'text' => '#ead196',
					),
					':hover' => array(
						'color' => array(
							'text' => '#ebd9b4',
						),
					),
				),
			),
		),
	)
)

This approach has been enabled as a temporary means to facilitate ergonomic definitions of shared block style variations through theme style variations. It is being flagged here for transparency however it will likely be deprecated soon as the Global Styles architecture is updated to address growing complexity and simplify its mental model.

More details on what’s ahead for Global Styles can be found in this issue.

Shared block style variations can be defined via styles.variations. Style data defined under styles.variations will be copied to, and merged with, variation data stored at the block type level for all block types that have a matching variation registered for it.

Additionally, a new translatable title property has been added here to mirror the capabilities of the theme.json partial files outlined above.

The key for the variation correlates to the slug property for theme.json partials. In the example below, this would be variation-a.

{
	"$schema": "https://schemas.wp.org/trunk/theme.json",
	"version": 3,
	"title": "Theme Style Variation",
	"styles": {
		"variations": {
			"variation-a": {
				"color": {
					"background": "#eed8d3",
					"text": "#201819"
				},
				"elements": {
					"heading": {
						"color": {
							"text": "#201819"
						}
					},
				},
				"blocks": {
					"core/group": {
						"color": {
							"background": "#825f58",
							"text": "#eed8d3"
						},
						"elements": {
							"heading": {
								"color": {
									"text": "#eed8d3"
								}
							}
						}
					}
				}
			},
		}
	}
}

Backwards Compatibility

As the Section Styles feature was implemented via extensions to block style variations rather than as a replacement, existing block style variations will continue to work as before.

Limitations

The following limitations for block style variations in WordPress 6.6 should be noted:

  1. Only root styles, i.e. those that apply directly to the block type the block style variation belongs to, can be configured via Global Styles.
  2. Block style variations cannot redefine or customize inner block style variations.
  3. Block style variations do not support their own custom settings values (yet).
  4. Custom block style variations cannot be applied and previewed within the Style Book.

What’s Next?

The Global Styles UIUI User interface for block style variations will be updated to facilitate the customization of all available styles for inner elements and block types. This includes potentially enhancing the Style Book to support block style variations.

Another future enhancementenhancement Enhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature. is the possible support for settings per block style variations.

Props to @bph, @oandregal and @juanmaguitar for review

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

Dropping support for PHP 7.0 and 7.1

Support for PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher 7.0 and 7.1 will be dropped in WordPress 6.6, scheduled for release in July 2024. The new minimum supported version of PHP will be 7.2.24. The recommended version of PHP remains at 7.4 or greater.

WordPress currently supports PHP version 7.0 or greater. The minimum supported version was last adjusted in WordPress 6.3 in August 2023, and since then usage of PHP 7.0 and 7.1 has dropped to a combined 2.45% of monitored WordPress installations as of April 2024.

There’s no concrete usage percentage that a PHP version must fall below before support in WordPress is dropped, but historically the project maintainers have used 5% as the baseline. Now that usage of PHP 7.0 and 7.1 combined is well below that at 2.45%, the process to increase the minimum supported PHP version in this release can move forward.

The benefits to increasing the minimum supported PHP version manifest over time and in multiple places, including within the 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 theme ecosystem, within the long term perception of the WordPress project, within developer relations, and over time within the WordPress codebase and its developer tooling.

Discussion around this minimum version bump can be found here on the Trac ticket.

What about PHP 8?

WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. is compatible with PHP 8.0 and 8.1 with exceptions. Support for PHP 8.2 and PHP 8.3 is considered 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. since WordPress 6.4. Please see the PHP Compatibility and WordPress Versions page in the handbook for full information.

What about security support?

Sites that are running PHP 7.0 or 7.1 will remain on the 6.5 branchbranch A directory in Subversion. WordPress uses branches to store the latest development code for each major release (3.9, 4.0, etc.). Branches are then updated with code for any minor releases of that branch. Sometimes, a major version of WordPress and its minor versions are collectively referred to as a "branch", such as "the 4.0 branch". of WordPress which will continue receiving security updates as it does currently. The current security policy is to support WordPress versions 4.1 and greater.

What about 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/ plugin?

The Gutenberg plugin, which is used for development of the 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, has a separate release schedule from WordPress core and officially supports the two most recent releases of WordPress. The Gutenberg development team will likely also increase the minimum supported version of PHP to 7.2 in time for WordPress 6.6. See this issue on the Gutenberg repo for when this was last changed in WordPress 6.3.

Going forward

There are no plans to bump the minimum supported PHP version on a schedule. The core team will continue to monitor usage of PHP versions and work with the hosting team to encourage users and hosting companies to upgrade their versions of PHP as swiftly as possible. The 5% usage baseline will continue to be used for the foreseeable future.

The PHP usage stats as of April 2024 look like this:

  • 8.3: 1.20%
  • 8.2: 12.07%
  • 8.1: 16.34%
  • 8.0: 12.25%
  • 7.4: 42.80%
  • 7.3: 4.79%
  • 7.2: 3.80%
  • 7.1: 0.95%
  • 7.0: 1.50%

Update PHP today

If you need more information about PHP or how to update it, check out this support article that explains more and guides you through the process.

Props to all those that have contributed to this discussion recently. Thanks to @chanthaboune for feedback and proof-reading this post.

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

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.