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

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

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.

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

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

Miscellaneous developer changes in WordPress 6.6


Table of contents


Autosave

Allowed disabling autosave support for individual post types

[58201] added a way to allow disabling autosave support for individual post types. Not all post types support autosaving. By making autosave a post type feature, support can be more granularly handled without any workarounds or hardcoded allowlists. For backward compatibility reasons, adding editor support implies autosave support, so one would need to explicitly use remove_post_type_support() to remove it.

See #41172 for more details.

Bundled Theme

Twenty Sixteen: Fixed mismatch of visual and DOM order of elements

Starting in Twenty Sixteen’s version 3.3 (released with WordPress 6.6), the site information links remain below the social navigation at any screen size. Before that, the social navigation had displayed after the site information on larger screens, which created a mismatch between the visual order and the Document Object Model (DOM) order.

Site, Privacy Policy, and Proudly powered by WordPress links appear beneath three social icon links in the site footer
The two footer elements are stacked, now at screen widths larger than 910 pixels.

If you would like to have the two elements side-by-side, with the social navigation first, you could paste styles in a child themeChild theme A Child Theme is a customized theme based upon a Parent Theme. It’s considered best practice to create a child theme if you want to modify the CSS of your theme. https://developer.wordpress.org/themes/advanced-topics/child-themes/. or in the Customizer’s Additional CSS panel.

Check the instructions on how to do this
@media screen and (min-width: 56.875em) {
	/*
	  1. Reset the social navigation width.
	  2. Adjust margins to place site info along the right edge.
	*/
	.site-footer .social-navigation {
		width: auto;
		margin: 0.538461538em auto 0.538461538em 0;
	}
	.site-info {
		margin: 0;
	}


	/* Reverse the margins for right-to-left languages. */
	.rtl .site-footer .social-navigation {
		margin: 0;
	}
	.rtl .site-info {
		margin: 0.538461538em auto 0.538461538em 0;
	}
}
Three social icon links appear on the left side of the site footer, but Site, Privacy Policy, and Proudly powered by WordPress links are on the right.
Custom CSSCSS Cascading Style Sheets. could place the site information links on the right side.

See #60496 for more details.

Comments

Default length of time for comment author cookies has changed

[58401] changed the default length of time for comment author cookies from 0.95129375951 of a year to 1 year by taking advantage of the YEAR_IN_SECONDS constant. The comment_cookie_lifetime 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. can still be used to change this value.

See #61421 for more details.

Editor

Site Editor Patterns on Classic Themes

#61109 now directs a classic theme’s Appearance > Patterns menu to the site editor Patterns view (/wp-admin/site-editor.php?path=/patterns), providing a consistent pattern and template management experience regardless of theme type. For themes with block-template-parts support, the Appearance > Template Parts menu has been removed, with template parts now accessible under the site editor’s Patterns > Template Parts view.

Fluid Typography

Some theme.json presets require custom logic to generate their values, for example, when converting font size preset values to clamp() values.

The custom logic is handled by callback functions defined against the value_func key in WP_Theme_JSON::PRESETS_METADATA. The callback functions are invoked in WP_Theme_JSON::get_settings_values_by_slug().

In WordPress 6.6, settings of the current WP_Theme_JSON instance, are now passed to these callback functions. The permits callback functions to return values that rely on other settings in 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. tree.

In the case of font sizes presets, it fixes a bug whereby the callback function — wp_get_typography_font_size_value() — was not taking into account settings values passed directly to the WP_Theme_JSON class.

External libraries

jQuery UIUI User interface library update

The jQuery UI library was updated to version 1.13.3. For more information on the changes included, see jQuery UI 1.13.3 release notes.

Login and Registration

New array arguments for wp_login_form

The wp_login_form() function has two new array arguments: required_username and required_password. Passing true to these arguments adds the ‘required’ attribute to the input fields.

$args = array(
    'required_username' => true,
    'required_password' => true,
);
wp_login_form( $args );

There is no change to the default field output.

See #60062 for more details.

Multisitemultisite Used to describe a WordPress installation with a network of multiple blogs, grouped by sites. This installation type has shared users tables, and creates separate database tables for each blog (wp_posts becomes wp_0_posts). See also network, blog, site

Custom ports for multisite site addresses

#21077 made it possible to install and operate a Multisite installation on a host name that includes a port number, and the corresponding #52088 added full support for this to the local development environment. This means it’s now possible to run Multisite on an address such as localhost:8889.

Update enabled mime types for new multisite installs

In #53167, the list of mime types that are enabled for upload were aligned to those enabled by regular sites by switching from a hard-coded list of types (that had become outdated) to using coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.’s get_allowed_mime_types function. This ensures that new multisite installs are up to date with the current mime types supported in core, including the recently enabled image/webp and image/avif types.

Note that, since this is only used to populate the schema for new networks, it will only affect newly created multisite networks – it does not change the allowed mime types for existing networks. To adjust the mime types allowed for existing sites, developers can continue to use an approach as follows for filtering the upload_filetypes option:

Script Loader

Obsolete polyfills dependencies have been removed

In [57981], now obsolete polyfills such as wp-polyfill, wp-polyfill-inert and regenerator-runtime were removed from the react script dependency in WordPress, as they are no longer needed in modern browsers supported by WordPress. Developers relying on wp-polyfill need to manually add it as a dependency to their scripts.

See #60962 for more details.

Script modules can now be used in the WordPress adminadmin (and super admin)

With #61086, script modules can now be used in the WordPress admin. Before WordPress 6.6, script modules were only available on the front end.

Toolbar

Search has a much later priority

In [58215], the search input on the front-end admin bar is added at a different priority. It was previously inserted at priority 4 and then floated to appear at the end of the admin bar. It is now inserted at priority 9999 to load at the end of the admin bar without CSS manipulation.

Extenders placing admin bar nodes after the search or replacing core search should take the new priority into consideration.

Example: Assign different priority based on WordPress version

$priority = ( version_compare( $GLOBALS['wp_version'], '6.6-alpha', '>=' ) ) ? 4 : 9999;
add_action( 'admin_bar_menu', 'wpadmin_toolbar_test_link', $priority );
/**
 * Add a node to the WP admin toolbar.
 *
 * @param object $wp_admin_bar WP Admin Bar object.
 */
function wpadmin_toolbar_test_link( $wp_admin_bar ) {
	$wp_admin_bar->add_node(
		array(
			'parent' => 'top-secondary',
			'id'     => 'mylink',
			'href'   => '#',
			'title'  => __( 'My Link' ),
		)
	);
}

See #60685 for more details.


Props to @swissspidy, @jorbin, @johnbillion, @audrasjb, @joedolson, @ironprogrammer, @ramonopoly, @jonsurrell, @sabernhardt, @jdy68, @afercia and @juanmaguitar for their contribution and/or reviews.

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

Roster of design tools per block (WordPress 6.6 edition)

Below you find a table that lists all coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. blocks available in the inserter marks in the grid the feature they support in 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. It’s a basic lookup table that helps developers to find the information quickly.

While this post is released as part of 6.6, the content summarizes changes between 6.1 and 6.6. This is an update of the post published for the 6.1 release and provides a cumulative list of design supports added with the last five WordPress releases.

The features covered are:

  • Align
  • Typography,
  • Color,
  • Dimension,
  • Border,
  • Layout,
  • Gradient,
  • Duotone,
  • Shadow,
  • Background image*
  • Pattern overrides / Block Bindings (PO/BB)

*Note: In WordPress 6.6, the background image tools are only available for Group, Pull quote, Site Logo blocks and as side-wide feature. For Quote, Verse and Post content blocks, it’s only in 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/ 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 18.6 and slated for WordPress 6.7.

Updated on July 3 with the list tracking issues to add various design tools to core blocks, so one can follow along the progress.

Work in progress

The issue Tracking: Addressing Design Tooling Consistency lists tracking issues for individual block supports.

Props to @annezazu and @juanmaguitar for review.

#6-6, #dev-notes, #dev-notes-6-6, #editor