The WordPress coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. development team builds WordPress! Follow this site for general updates, status reports, and the occasional code debate. There’s lots of ways to contribute:
Found a bugbugA 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.?Create a ticket in the bug tracker.
WordPress’s HTMLHTMLHyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers.APIAPIAn 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. is developing at a rapid pace. Introduced in WordPress 6.2, and expanded in each release since, the HTML Processor is expected to support all HTML inputs1 in WordPress 6.7. What does this mean for you and where does development go once “full support” has been reached?
The HTML Processor also gained a new constructor method: create_full_parser(). The full parser expects an HTML document in its entirety, including the doctype declaration, <html>tagtagA directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.), and all. The existing mechanism, create_fragment(), assumes that the given input exists within an existing HTML context, such as inside a <body> tag. If you’ve ever wondered by DOMDocument creates an HTML and HEAD element even when none exists, it’s because it’s performing a full document parse. While both methods have their place, create_fragment() is probably still what you want to use because WordPress rarely presents a complete HTML document to its functions, plugins, and themes.
All supported tags, but with a caveat
There are a few situations that the HTML Processor still won’t support for WordPress 6.7. These are cases where nodes are supposed to be re-parented and they have remained an obstacle for the past few releases. The problem isn’t knowing how to parse these situations, but rather that they imply that parts of a document have changed after the processor has already seen them. They occur most frequently when formatting elements are implicitly closed and then need to be re-opened and when content inside a TABLE element is not in a cell. Such can be seen with the following HTML:
<table><td>1</td>2
This looks innocent enough, but the 2 belongs in front of the TABLE element. When nodes are moved around after the fact like this, it’s possible that the parser might have seen hundreds of kilobytes of content in the meantime. This disconnect between the order of the HTML text and the traversal order in the DOM tree raises complicated questions, including for situations where inner markup is being modified.
A cursory analysis of high-ranked domains on the broader internet suggests that around 1% of real web pages involve these and other unsupported situations. Luckily, most content within WordPress and all content generated by frameworks like ReactReactReact is a JavaScript library that makes it easy to reason about, construct, and maintain stateless and stateful user interfaces. https://reactjs.org/. avoid these invalidinvalidA resolution on the bug tracker (and generally common in software development, sometimes also notabug) that indicates the ticket is not a bug, is a support request, or is generally invalid. HTML constructions.
Reading and modifying inner HTML
One question that has delayed the introduction of methods like set_inner_html() is how to know whether content is already escaped or not. Can a system be built that allows “trusted” input without introducing opportunities for vulnerabilities? With the expansion of support and the unlocking of new fragment parser contexts, there’s finally a way forward to address this question: do what a browser does.
To set inner content, the HTML Processor will create a new fragment parser using the current element as the context element. It will run the fragment parser to its end and transfer the parsed nodes into the target, just like node.innerHTML = 'string of <code>HTML</code>' in the DOM does. This approach seems obvious from some angles, but implies that the HTML API will be parsing (and possibly re-parsing) any contents that are being set into a target document – this is a slower approach than naïvely slicing in new HTML.
This approach has a fascinating upside though: in addition to ensuring that content is properly escaped, it will normalize the content and prevent the new HTML contents from escaping its outer node. It properly isolates HTML updates. For example, suppose one wants to set the inner HTML for a DIV element.
What should happen with the </div>? If the HTML API were simply replacing text or concatenating HTML, then the update would close the open <div> and the “ do?” content would now appear outside of the intended spot.
// Broken by string concatenation unaware of HTML.
<main><div>What will </div> do?</div></main>
Since the HTML API creates a fragment parser in the appropriate context, however, when it finds the </div> token it will realize that there’s no open <div> and ignore the token (note the extra space below, which in a browser will collapse into single space). The content will remain inside the original DIV.
<main><div>What will do?</div></main>
Things can appear fairly wacky at times, but the normalization process will leave the HTML better than when it found it.
Modifying HTML content mostly depends on being able to create a new fragment parser in the context of the current element. Since this is an ongoing project it will not likely make it into WordPress 6.7, but should be available early in the 6.8 development cycle.
Review of all CSSCSSCascading Style Sheets. semantics
The job of the HTML API is to know all of the minute details of HTML parsing so that you don’t have to. To that end, all of the CSS-related methods have been audited to ensure that they reliably match the behavior in a browser. This mostly involved examining the impact of “quirks mode,” which determines if class selectors match names in a case sensitive manner or not.
So if you ask whether CSS class names are matched case-sensitively or not then the HTML API will answer based on the HTML document it was provided. The Tag Processor and fragment parser will assume no-quirks mode (standards mode) while the full parser will choose based on the rules in the HTML specification.
What’s coming after reaching full tag support?
Continuing towards 100%
Parsing HTML involves no uncertainly: WordPress needs to understand all possible HTML documents. In the coming releases work will continue on the tricker design details of supporting the final unsupported bits.
In some situations an element is found outside where it should be. For example, a <p> tag might appear after a BODY element is closed, but it belongs inside the BODY element. The HTML Processor could report this at the proper breadcrumbs (because it knows it belongs at HTML > BODY > P), but that would appear as though the parser jumped backwards in the document back into the BODY. A document should only ever open and close the BODY once. Whether it’s an errant <meta> tag, a <script> after the BODY, or an HTML comment after the BODY, these situations account for about half of the situations that aren’t supported.
The other half of the unsupported situations are more complicated. They involve things which are easy in the DOM but hard in HTML. Specifically, there are times where elements get moved up higher in the tree, or earlier, or are duplicated in different parts of the tree. The HTML API knows where these elements should move, but it doesn’t know until after it has parsed and moved on from those places. It may be possible to look ahead in the document and rearrange the virtual sequence in the HTML, but this is a complicated and delicate operation that requires lots of care.
However these situations are handled, they will probably be done so in an opt-in manner. Lookahead might resolve the problem of accurately representing the document, but in some extreme cases, it may be required to fully parse the entire document before returning control to the calling code. Potentially there could be a user-selectable amount of lookahead before the processor gives up, and a small default value could strike a good balance between fully-supported parsing and surprise performance behaviors.
$processor->set_allowable_lookahead( 3 )
These unsupported situations present some design issues that also need to be solved when discussing modification of an HTML document. For example, in cases where formatting elements are reconstructed, if some code adds a new attribute to the real formatting token then the attribute value appears also on all of the recreated versions of it. How should the HTML API know if someone wanted to set an attribute only on the first element or if they wanted to set it also on all reconstructed elements?
In some cases this can all be avoided by using the HTML API to normalize a document before processing, but in other cases these questions need to be explored before making any hasty decisions. Supporting out-of-order elements makes reading and writing inner HTML significantly more complicated because it can’t return a simple substring; while auto-fixing could invoke catastrophic backtracking into the parser.
Reading sourced blockBlockBlock 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. attributes on the server
Although this feature has also been pushed back a couple of releases the work continues. There wasn’t sufficient HTML support in WordPress 6.6 to allow reading block attributes reliably enough to be usable. With the practically-complete support in WordPress 6.7 this will no longer be a problem. The primary challenge now is building an interface to parse a CSS selector in a way that properly translates into HTML API code.
When this work was first explored it relied on the Tag Processor and started searching in a top-down manner based on the selector. This isn’t the most efficient way to search, however. In rebuilding the block attribute sourcer for the HTML Processor, the parsing of the CSS selector is going to need to figure out how to search in a bottom-up manner. It’s also going to need to pay attention to things like class names, attribute values, and nth-child counts for relevant tokens while parsing.
WordPress Bits
WordPress 6.7 is not going to see any major work on the Bits proposal, but the work is still being actively pursued. Other developments on templating, custom data types/fields, and block bindings continues to explore the space from the UIUIUser interface and UXUXUser experience angle.
Native PHPPHPThe web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher support
The HTML API will be significantly faster when it’s available in PHP, written in C instead of user-land PHP. The first proposal to move the HTML API into PHP itself is in the RFC process, adding a decode_html() function corresponding to the recently-introduced WP_HTML_Decoder class.
Additional notes
An HTML API debugger makes exploring HTML fun
@jonsurrell built a WordPress plugin to add a visual HTML API debugger in wp-admin and it’s built with the Interactivity API. This is a fun tool that shows how the HTML API parses a given HTML input. In addition, it provide insight into the parsing mechanics that lead to the final structure. One can learn a lot about HTML parsing just by seeing how different inputs are processed. For example, the “virtual” nodes in the output represent tags that weren’t in the HTML text but were implicitly created based on HTML’s parsing rules.
Following the progress
For updates to the HTML API keep watch here for new posts.
If you want to follow the development work you can review Trac tickets in the HTML API component or start watching new HTML API tickets from the component overview page. If you want to talk details or bugs or applications, check out the #core-html-api channel in WordPress.orgWordPress.orgThe community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/SlackSlackSlack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/..
“All” is mostly correct, because while all HTML tags are supported, there are still situations that account for around 1% of all HTML documents on the internet that get into edge cases that it can’t parse. These cases all deal with content that’s found outside of the place it should be, where the tree-order of the nodes in a DOM are rearranged from the order in which the HTML tags are found. The HTML Processor still aborts parsing when it encounters unsupported markup, so it should continue to be reliable for everything it supports. ↩︎
Over the years of working on the GutenbergGutenbergThe 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/ project, we developed some common practices. These help us preserve the quality and the long-term viability of the project. They differ and often contradict what people are used to in other projects (especially outside WordPress CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress.).
These practices should be applied during implementation and PR reviews. Sharing and embracing them helps contributors make the right decisions and be more autonomous, when working on the project.
This list is non exhaustive and subject to change. These are guidelines to always keep in mind but shouldn’t be treated as hard rules. Context is always important to consider.
Start APIs as private
Gutenberg is organized in packages. Implementing features means introducing new APIs to one or multiple packages. It’s important to understand that most of the packages‘ APIs are public WordPress APIs. Anything exported from a package and consumed by another package becomes a defacto WordPress APIAPIAn 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 API needs to be maintained forever to adhere with the WordPress backwards compatibility strategy. Thus, It’s recommended to start with private APIs.
Be intentional about providing public APIs
Extensibility is important to WordPress. We do want pluginPluginA 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 authors to extend what WordPress provides. We also want them to reuse tools that WordPress uses internally. This point can read as a contradiction with the previous one. But what’s important here is that it needs to be intentional. Before making an API public during the feature work, we should ask ourselves these questions:
Do we want to allow users to use this API?
And are we willing to support it for the next 10 years without breaking changes?
If the answer to both these questions is yes, then we can consider making this API public.
Avoid opening APIs for convenience, embrace copy/paste
Some times, for convenience and to abide to the DRY principle, we, developers create APIs and abstractions. This is seen as a good practice in most projects. But in the context of Gutenberg and WordPress, it is something to avoid. The cost of maintaining APIs is too high because of the backward compatibility strategy.
Say you have a low-level function or component already available to plugin authors or npm package users. To achieve their use-case, they maybe have to write some duplicate boilerplate code. Creating a higher-level abstraction to avoid the duplication should be avoided as much as possible. It is true that providing a great Developer Experience is important though. There are cases where a higher-level abstraction is required. The main approach is that we should have very strong arguments for it and be intentional.
Prefer Semantic Extensibility
Plugin authors in WordPress want to be able to extend every piece of the UIUIUser interface. They also want to give way too much prominence to their own extensions and upsells. As WordPress history teaches us, this quickly leads to a degraded user experience. Who has never seen a WP Adminadmin(and super admin) with hundreds of notices? Who has never seen a WP Admin with menu items and call to actions competing for the user’s attention?
A non curated set of extensibility APIs can lead to stagnation as well. One example here is the metaMetaMeta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. boxes API in the classic editor and how it created a lot of constraints for the development of the blockBlockBlock 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. This kind of APIs prevent iteration and evolution. It becomes very hard to improve the UI and UXUXUser experience of these screens. Any change, no matter how small, can lead to breaking changes for plugin authors.
To alleviate these issues, extensibility in Gutenberg is curated and semantic. APIs to register/unregister semantic pieces (blocks, patterns, actions, fields) are prefered. APIs that are too broad and whose purpose is unclear should be avoided. For example:
A slot in the editor headerHeaderThe header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes. is not a very semantic API. It’s unclear what it will be used for. This will prevent any redesign and iteration to the header area of the editor.
The ability to set a priority or order to extensions is often an API that we want to avoid. It’s very prone to abuse. Often, plugins authors use these to give priority to their own extensions over what Core provides. It quickly leads to a degraded experience for users.
One package = one clear purpose
Developing features in Gutenberg often involves modifications to multiple packages at the same time. We need to ask ourselves: where should this piece of code live? To answer the question, it’s important to understand the purpose of each package. Here are some common examples:
Most of the editor UI is built within the @wordpress/block-editor package. So developers often change this package directly to accommodate their specific needs in the UI. The problem though is that it’s not the sole package responsible for adding UI to the editor. It is important to understand that this package is the Tinymce of Gutenberg. It can be used to build and integrate block editors within WordPress and outside WordPress. It’s a framework to build block editors. If a part of the UI is specific to WordPress, it’s not the right place to do this change. A recent example I noticed here is the addition of a button to the block settings menu. That button was used to open the WordPress editor sidebarSidebarA sidebar in WordPress is referred to a widget-ready area used by WordPress themes to display information that is not a part of the main content. It is not always a vertical column on the side. It can be a horizontal rectangle below or above the content area, footer, header, or any where in the theme. but editor sidebars are specific to WordPress block editors.
Making a REST APIREST APIThe REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/rest-api/. request in a UI component is another common pitfall that happens often. For example, you may want to build a Language Switcher UI component. And you want it to be reusable in the @wordpress/components package. You can’t use a REST API call within the component to fetch the available languages. The components package is a generic WP agnostic UI components package. So instead, it’s better to have a prop to pass of the available languages instead.
It’s also not recommended to add new packages just to share code between two existing packages. Most of the time,There’s a better solution to the code sharing problem. @wordpress/utils package doesn’t exist for a reason. Utility packages are a place where we can just dump shared code without purpose. As mentioned earlier, copy/pasting is not always a bad idea when it comes to code sharing. It is preferable to avoid early abstractions as much as possible.
Measure then optimize
We, developers have a tendency to over optimize our code. Often these optimizations involve adding some complexity to the code making it harder to maintain. It is better to avoid these early optimizations. Instead, measure the impact of the change you want to perform to validate that the optimization is worth the added complexity. Important metrics are tracked in the codevitals dashboard.
Other random common pitfalls
Besides the principles above that one needs to follow to make the right calls, here are some common pitfalls that we’ve learn to avoid over time:
Avoid passing editor settings as inline JSJSJavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors. from the backend to the frontend. It is a pattern we used heavily early on in the project. We should ideally move away from it and prefer a better separation between client and server (use REST API calls).
Adding settings to the BlockEditorProvider (and the @wordpress/block-editor package) is ok. But we should be intentional about it: what does the setting mean for third-party block editors? Always remember the block editor framework use case.
Be declarative as much as possible. Using state actions and selectors to share UI state is acceptable. But know that it’s risky. It can lead to bugs and race conditions quickly if multiple components compete to set the right state. This happened to us at least in two recent situations:
Insertion position: We moved away from declaratively computing the insertion position based on the selected block. We used setInsertionPoint action and state instead. The issue is that the inserting point is now incorrectly set at times. Or it persists as we navigate away…
Block editing mode: To support different UI modes for blocks (content-only, locking, template-locked mode, zoom-out mode) we introduced a state to manipulate what we call “block editing mode” using setBockEditingMode action. We now have some hidden bugs because of that. These different modes compete with each other to set the right block editing mode.
Avoid using stores in new packages. Be careful when introducing new data stores. Each time we register a new store, there’s added complexity in the system. Stores are singletons by default, they can only be present once in the page. We do support multiple instances of the same store on the page but it’s not without complexity. We need to extend the global registry. We have also seen that using stores in bundled packages like @worpdress/interface is not a good idea. When a plugin wants to use that package/store it leads to the store trying to be registered twice. The wrong store will be accessed from the components when it happens.
Next major releasemajor releaseA 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 BetaBetaA 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. The Road Map post can be found here.
Next minor releaseMinor ReleaseA 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.3
Following the recent WordPress 6.6.2 release, the next maintenance release (if needed) will be WordPress 6.6.3. There were not updates shared in the meeting.
Next GutenbergGutenbergThe 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.2
The next Gutenberg release will be 19.2, scheduled for September 11 (this release occurred after the meeting).
Discussion
@peterwilsoncc requested that we discuss the BlockBlockBlock 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. Bindings UIUIUser interface feature, TracTracAn open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress.ticketticketCreated for both bug reports and feature development on the bug tracker.#61945.
To summarize his concern:
My main concern here is that the approach is to hide the UI from users with low permissions. I don’t feel that this is a great approach to handling a UI that is considered too technical, as I don’t think there is anything to suggest that an administrator will understand what an author does not.
So I’m of the view the interface ought to be improved and made less technical before it’s shipped in coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress..
@noisysocks suggested waiting on an update from Mario Santos, who is working on the feature, but added:
I’d be fine with just updating this to use caps. The interface doesn’t strike me as being too technical. Can put it in the Advanced tab if we’re worried…
…The short of it is that I’m okay with fixing the cap issue (add a new cap, don’t check against a role) and shipping in 6.7 or leaving it in the pluginPluginA 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 for more testing. Up to the team working on it. We have until beta 1 to decide.
@joemcgill highlighted two additional Slack updates this week:
I’ve addressed the feedback by adding a deprecation notice to the pattern rather than removing it. I’d appreciate any thoughts on if this feels like a better approach.
@joemcgill pointed out #62004. @jrf recently asked all committers to review in full here. Julia shared the following updates during the meeting:
Ticket #53010 is basically the first step: splitting up the huge test classes to smaller classes which each only test one thing, i.e. one global function, one method in a class etc.
This includes making sure that the new test files comply with the PHPUnit naming conventions.
There are a number of patches attached to the ticket which can be used to see how to do this (mind: not all have been reviewed yet for the latest info).
I also think it would be great if we could get a decision on yes/no namespacing the test classes. I believe we should and that now is the time.
And followed up with
The other thing which would really really help, is to make sure that any new tests go in “clean”. As in: comply with the requirements for newer PHPUnit versions. The task is large enough as it is without having to clean up after new commits.
In the Figma file you can see what is completed by looking for a green circle. Designs in progress have a yellow circle, and anything that is blocked or not planned at this time, is labeled with a red circle.
Work on the style variations. There’s an open issue to address these.
Work on items that are set to [Priority] High.
Once we finish adding the remaining blockBlockBlock 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. patterns and templates, we’ll start adding issues and instructions on how to proceed with i18ni18nInternationalization, 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. (making strings translatable, etc.), indentation, and polishing the patterns/templates.
Open floor
@erichmond brought up that it is difficult to pick issues to work on, and that even if a contributor is assigned to an issue, there may be duplicate pull requests submitted.
The intention is to follow the assignment to the person who has shown interest in the issue first. A recommendation would be to see if there are pull requests open before starting to work on a given issue.
It is difficult to predict what kind of issues that may be open in the repository on the 17th and if they are suitable to work on during a contributor day. A new label in the repository can help contributor day attendees to select issues to work on.
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 ticketticketCreated 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 this week.
Forthcoming releases
Next major releasemajor releaseA 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 BetaBetaA 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 GutenbergGutenbergThe 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.2
The next Gutenberg release will be 19.2, scheduled for September 11.
Discussions
The discussion section of the agenda is to provide a place to discuss important topics affecting the upcoming release or larger initiatives that impact the CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. Team.
Topic(s) for this week:
Reviewing the BlockBlockBlock 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. Bindings UIUIUser interface feature, TracTracAn open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. ticket #61945 – @peterwilsoncc
If you want to nominate a topic for discussion, please leave a comment on this agenda with a summary of the topic, any relevant links that will help people get context for the discussion, and what kind of feedback you are looking for from others participating in the discussion.
You can keep up to date with the major Editor features that are currently in progress by viewing these Iteration issues.
Design: Advancing the WordPress Design System was shipped last week which is an important post to read, especially when thinking about phase 3, as the aim is to “bring together existing tools like @wordpress/components, the new Figma library, and Storybook into a unified design system reference site that anyone can use to contribute back to WordPress or extend WordPress in line with a shared design language.”
Styles: updated designs were shared on consider exposing the style book for classic themes with some early dev work around how to both address exposing the style book and iterating on the style book presentation.
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.
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.
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.
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 themeA 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;
}
}
Custom CSSCSSCascading Style Sheets. could place the site information links on the right side.
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_lifetimefilterFilterFilters 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.
#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.jsonJSONJSON, 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 UIUIUser 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.
MultisitemultisiteUsed 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 coreCoreCore 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.
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
This guide outlines major developer features and breaking changes in 6.6 and is published in the Release Candidaterelease candidateOne 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, CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. developers, and others.
This release includes 392 enhancements, 462 bugbugA 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 accessibilityAccessibilityAccessibility (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. gutenbergGutenbergThe 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.
BlockBlockBlock 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 ReactReactReact 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 APIAPIAn 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.
WordPress 6.6 includes updates for the Interactivity API, such as new async directives, support for derived state props from PHPPHPThe 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.
HTMLHTMLHyperText 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.
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.
I18Ni18nInternationalization, 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.
One of the highlight features included in WordPress 6.6 is the automatic rollback of pluginPluginA 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 HooksHooksIn 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.
Modified FilterFilterFilters 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
WordPress 6.6.2 is scheduled to be the next maintenance release for the 6.6 version. Its release will follow the following preliminary schedule:
September 4, 2024 – Release Candidaterelease candidateOne 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/coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. site.
September 10, 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 bugbugA 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 tracTracAn open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress.ticketticketCreated for both bug reports and feature development on the bug tracker. that you think should be considered, please put it in the 6.6.2 milestone. If you have a GitHubGitHubGitHub 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.2, 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.
Get involved with 6.6.2
Bug Scrubs will happen in the #core room during the following times:
Each of the open tickets is going to require development work along with testing and review. You can also run your own scrubs to help ensure that all of the correct tickets are fixed in this release. Additionally, while the intent is for no new translated strings in this release, some locales have strings in 6.6 in need of translation.
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 ReleaseA 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 @vcanales and myself (@hellofromtonya), with @jorbin mentoring us.
WordCampWordCampWordCamps 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 is coming up Sep 17-20 in Portland, Oregon – we will have a performance table at Contributor DayContributor DayContributor 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/. with Adam
WordPress 6.7BetaBetaA 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 October 1
Performance Lab next release scheduled for Sep 23
Priority items
WordPress performance TracTracAn open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. tickets
Current release milestone report. There are currently 20 tickets unresolved
Future release
Performance Lab pluginPluginA 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 other performance plugins) including:
You must be logged in to post a comment.