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.
Currently there is no easy way to identify TracTracAn open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. tickets specifically for adding unit tests. Some are added to the Build/Test Tools component, however the tests are not really “tools”. The reason for this is that unit tests, just like build and test tools, are “non-production code”. That means they can be committed at any time during the WordPress development cycle and do not follow the general milestones-based workflow.
Additionally, many tickets for adding unit tests are marked as “enhancements”. Following the release cycle workflow, enhancements cannot be committed during 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. and RCrelease 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).. However, in practice unit tests can be committed at any time. It can be difficult to isolate these today, as the Trac search form lacks a 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. for such tickets, which makes triaging a bit harder.
Some suggestions
During the discussion in #core, several ideas were proposed about how this can be made to work better. And while there isn’t currently much traction on adding E2E tests to CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress., any option explored should take this test type into account. In no particular order:
Component: A new Tests component, which would be exempt from the general workflow, similar to Build/Test Tools. Example component filter.
Keyword: A tests-only keyword to identify that it’s for unit/E2E tests only, and serve to filter tickets for triagetriageThe act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. reports. Example keyword filter.
Milestone: An Any Time milestone could indicate when this type of ticketticketCreated for both bug reports and feature development on the bug tracker. could be committed, being primarily reserved for tests- and docs-only tickets. Example milestone filter.
Type: A test ticket type, to clearly differentiate from the current defect (bug), enhancement, and task (blessed) types. Example type filter.
Type (alternative): A new non-production type could be introduced to broadly cover any ticket that does not affect build/production code. Example type filter.
I think that any of the proposed solutions would make searching and triaging test-oriented tickets a bit easier. Some are more flexible in that it’s easier to combine terms (focuses and keywords).
What are your thoughts on these ideas to make test-only tickets easier to distinguish? Please help continue the discussion in the comments below!
Since the introduction of 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. themes, theme authors have been able to create custom block templates. However, this possibility was limited to themes, leaving plugins without a straightforward way to register their own templates. To achieve similar functionality, plugins had to resort to complex methods, including hooking into multiple PHPPHPThe web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher filters, manually creating WP_Block_Template objects, and replicating internal WordPress logic.
WordPress 6.7 introduces a new 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. that will significantly simplify the process for plugins to register their own block templates. To enable this, two new functions have been introduced: register_block_template() for registering a block template and unregister_block_template() for unregistering it.
register_block_template( string $template_name, $args = array() ) accepts two parameters, that define how the template is registered:
$template_name: The name of the template in the form of plugin_uri//template_name (note that this requires a double //).
$args: An array of arguments for defining the template:
title: An internationalized title for the template.
description: An internationalized description of the template.
content: The default content (block markup) for the template when rendered in the editor or on the front end.
post_types: An array of post type slugs to make available to users as per-post custom templates.
For example, a 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 can register a template with the following snippet:
Plugins can also override templates from the WordPress template hierarchy, such as the archive page of a custom post typeCustom Post TypeWordPress can hold and display many different types of content. A single item of such a content is generally called a post, although post is also a specific post type. Custom Post Types gives your site the ability to have templated posts, to simplify the concept. or a specific author page.
Theme templates take priority over plugin-registered templates, allowing themes to override specific plugin templates just as they can with WordPress templates.
Currently, this API is limited to block templates and does not allow the registration of block template parts.
You can read more about this new feature in the following links:
Props to @aljullu for writing this dev notedev noteEach important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include a description of the change, the decision that led to this change, and a description of how developers are supposed to work with that change. Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase.. And thanks to @fabiankaegy for reviewing
The CustomSelectControl component has been completely rewritten using ariakit. Notably, this refactor enables the removal of the downshift library as a dependency of 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/ repository, causing a ~7.75 kB decrease for the @wordpress/components package bundle size.
While there are no breaking changes to the component public APIs, the refactor also allowed us to make a few improvements to the component:
the trigger button has the combobox role instead of button, in line with the WAI-ARIA specs;
the __experimentalShowSelectedHint and options[]. __experimentalHint props have been unprefixed and stabilized;
the select popover has a new entrance animation when opened, in line with other components;
while the select popover’s max-height hasn’t changed, the popover’s height adapts to the available space, without causing extra overflow on the page;
item hints can now wrap to a separate row from the item’s content when there isn’t sufficient space to render on the same line;
item internal padding now matches the trigger button padding for better visual consistency.
The ToggleGroupControlOption and ToggleGroupControlOptionIcon components can now be marked as disabled via the newly added disabled prop. While disabled, an option cannot be selected by the end user.
A few components have been stabilized or deprecated as part of an ongoing effort to progressively reduce the number of experimental APIs exported from the @wordpress/components package.
Stabilized Composite
Following the rewrite of the __unstableComposite (& related) components from ariakit to reakit in the WordPress 6.5 release, the 6.7 release introduces a new, stable version for the Composite component.
The new Composite component offers a more complete and versatile way to implement low-level composite widgets, and its APIs are more consistent with the rest of the @wordpress/components package.
The legacy set of __experimentalNavigator* APIs is deprecated and should instead be imported as Navigator. All of the sub-components are also available via the Navigator namespace.
Moreover, the __experimentalNavigatorToParentButton component and the goToParent() method available via the __experimentalUseNavigator hook are deprecated, and they now behave identically to the __experimentalNavigatorBackButton and the goBack() method.
The Button component had a __experimentalIsFocusable prop to keep the button focusable when disabled. This prop is now stabilized and renamed to accessibleWhenDisabled. (Existing usages of __experimentalIsFocusable will continue to work indefinitely.)
In most cases, it is recommended to set this to true. Disabling a control without maintaining focusability can cause 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) issues, by hiding their presence from screen reader users, or by preventing focus from returning to a trigger element.
The time input of the TimePicker component can now be used in isolation as <TimePicker.TimeInput />. In this case, the value will be passed as an object in a 24-hour format ({ hours: number, minutes: number }).
In TypeScript codebases, SelectControl will now be able to type-check whether the value type matches in the value, options, and onChange props. See detailed examples in the full dev note.
A number of UIUIUser interface components currently ship with styles that give them bottom margins. This can make it hard to reuse them in arbitrary layouts, where you want different amounts of gap or margin between components.
To better suit modern layout needs, we have gradually been deprecating these margins. A deprecation begins with an opt-in period where you can choose to apply the new margin-free styles on a given component instance. Eventually in a future version, the margins will be completely removed.
Continuing the effort started in previous releases, for the WordPress 6.7 release we will start logging deprecation warnings for the following components if they are not yet opting into the new margin-free styles:
BaseControl
CheckboxControl
ComboboxControl
DimensionControl
FocalPointPicker
FormTokenField
RangeControl
SearchControl
SelectControl
TextControl
TextareaControl
ToggleControl
ToggleGroupControl
TreeSelect
To start opting into the new margin-free styles, set the __nextHasNoMarginBottom prop to true.
Modal: Buttons in headerActions should use “small” size
The close button in the Modal component is now using the “small” Button size (currently 24px), down from the 36px default size in the old sizing scheme.
If you are using the headerActions prop to inject buttons beside the close button, we recommend you also use the “small” Buttonsize variant to match.
Props to @mirka for the help in writing these dev notesdev noteEach important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include a description of the change, the decision that led to this change, and a description of how developers are supposed to work with that change. Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase..
It’s time to get WordPress 6.7 ready for release, and help is needed to ensure it’s smooth and 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.-free. Whether you’re an experienced contributor or joining in for the first time, everyone is welcome at our bug scrubs! 🎉
Schedule Overview
Regular bug scrubs are being held every week leading up to the WordPress 6.7 release, with some cases including two sessions a day to cover a broader time frame. As the release date approaches and activity ramps up, the number of scrubs may be increased if necessary. These efforts will help ensure everything is on track for a smooth launch. Participation is welcome at any of these sessions, so feel free to join. Bring questions, ideas, and let’s scrub some bugs together!
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 below. If you have ticketticketCreated for both bug reports and feature development on the bug tracker. requests for help, please continue to post details in the comments section at the end of this agenda.
Announcements
WordPress 6.7 Beta 3 was released on October 15. Thank you to everyone who contributed to this release and attended the release party! There is a helpful guide here on how to help test this release.
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 RCrelease 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). 1 is scheduled for Tuesday, October 22. For specific release times, review the release party schedule post.
Next maintenance release
There are no maintenance releases planned at this time.
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.5
The next Gutenberg release will be 19.5, scheduled for October 23, and will include the following issues.
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.
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.
A reminder that there are a number of bugs on the 6.7 Editor project board that need addressing. Specifically, the new Zoom Out Mode has many issues. Most are minor, but additional help on these would be great.
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.
This post offers a proposal to create a private slackSlackSlack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. channel (#performance-hosting) where members of both the Performance Team and relevant representatives from hosting companies can come together to share information impacting the performance of sites, test relevant PRs, and have a quick feedback loopLoopThe Loop is PHP code used by WordPress to display posts. Using The Loop, WordPress processes each post to be displayed on the current page, and formats it according to how it matches specified criteria within The Loop tags. Any HTML or PHP code in the Loop will be processed on each post. https://codex.wordpress.org/The_Loop. for any performance regressions in new releases. This builds on the current private #security-hosting channel that’s already in place and has proven to be an area of collaboration.
Background
In talking to folks last week at WCUS alongside @harishanker, it became clear that in some cases hosting companies would benefit from a more curated and focused space for contribution that aligns with areas where they can make the biggest impact. In talking with folks, the following areas came to mind: performance, infrastructure, support, and security. This was a repeated topic in all conversations and, in these conversations, the #security-hosting channel came up as an already functional pathway.
Format
Create a new private slack channel for #performance-hosting that includes members from the Performance team for monitoring and engagement alongside relevant members from hosting companies. This is private in order to allow for more sharing and it’s centered around performance in order to provide a curated path for contribution, bringing in folks from the Performance team to engage directly.
What will this group work on?
Below are some of the ideas that were shared in the conversations. See these are starting ideas and not entirely encompassing:
Share anonymized data around plugins that are impacting sites the most in order to do outreach to them with performance suggestions, see what we can learn from them to improve CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress., and update the plugin checker for anything that might be missing to help future contributors.
Share common user configuration to provide better tests for real world performance situations, rather than solely relying on lab metrics.
Test performance PRs early.
Create a tight feedback loop after releases for any performance degradations.
Why performance?
It’s clear there are a specific areas that hosts are best equipped to make the biggest impact and contribution, including performance. At the same time, the Performance team is a strong team with a clear roadmap, sponsored contributors, and a dedicated space already. In my time in the FSE Outreach Program, I found out how critical it is to create a space that’s managed, maintained, and specific. This checked all the boxes and I anticipate there will be more areas that will, like Support.
Why a private channel?
In talking to folks, a private channel came up as a safer space to share information. I am not personally opposed to a public channel but I want to recognize the reality that for folks in the hosting space, it felt advantageous to have private.
What do you all think? Please share by October 9th, 2024.
Please share your thoughts below. While there was an appetite for this idea when talking to folks in person, I want to know what blockers there might be and whether there are reasons not to pursue this, especially from the Performance team who will be impacted by this.
Twenty Twenty-Five embodies ultimate flexibility and adaptability, showcasing the many ways WordPress enables people to tell their stories with many patterns and styles to choose from. The glimpses of natural beauty and ancestry woven into the theme evoke ideas of impermanence, the passage of time, and continuous evolution.
The demo content imagery, all from the Public Domain, carries a poetic, universal, and ubiquitous tone that complements the coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. concept. There was an opportunity to visually lean into a positive tone to bring softness, lightness, and inspiration through its aesthetic.
Patterns
Structurally, Twenty Twenty-Five offers a robust set of patterns, promoting interoperability and enabling users to compose intentional pages quickly. A broad range of patterns was designed for categories such as services, about, landing pages, products, calls to actions, events, and others.
Styles
Given the theme’s global use, high-quality and comprehensive fonts that support multiple languages have been considered from the first conceptual steps of the design. Furthermore, we’re refining a set of diverse color palettes to be bundled within the theme as style variations.
Templates
Twenty Twenty-Five also features a versatile set of blogblog(versus network, site)templates: text-centric blogs with sidebars, photo blogs that highlight featured images, and more complex blogs with diverse content. Twenty Twenty-Five will be fully compatible with the Site Editor and will use many of the new design tools like the Grid 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. and Pattern/Section Styles.
Personal Blog (Default)
In keeping with the idea of simplicity, the personal blog tendency is to lean on a default template that just works, whether you want to write a post with a title and featured imageFeatured imageA featured image is the main image used on your blog archive page and is pulled when the post or page is shared on social media. The image can be used to display in widget areas on your site or in a summary list of posts. or not, and showing all the post’s content out-of-the-box, instead of just excerpts.
Photo Blog (Alternative)
The alternative “photo blog” templates tailored primarily for photography or portfolios lean on an image-heavy approach, with interesting layouts that can be used for a variety of purposes.
Complex Blog (Alternative)
Lastly, the set of complex blog alternative templates would be more suitable for websites with greater complexity in content. Some of these templates, with more variety in type scales and more opinionated designs can also appeal to different audiences.
Development
As part of the 6.7 release, Carolina Nymark (@poena) and Juanfra Aldasoro (@juanfra) are leading development while Beatriz Fialho (@beafialho) is leading design. If you’re interested in contributing, make sure you’re following this blog; we look forward to your involvement and support throughout the process.
The Figma file is the design source of truth. Comments in the main file are open, and anyone should feel free to duplicate the Figma to their drafts and remix. Both of these actions are free, whereas every edit access is paid and therefore reserved.
Theme development will happen on the Twenty Twenty-Five GitHub repository. You can contribute by submitting and reviewing pull requests or opening new issues and, as usual, once the theme is stable, it will be merged into Core and the 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/ repository will be archived.
Starting on Wednesday August 21st at 3:00 PM UTC , there will be weekly Slack meetings in #core-themes to coordinate development of the theme. Agenda notes will be posted before meetings and summaries posted after the meeting.
Learn more
For information about previous default themes, read the following posts:
WordPress 6.7 introduces a new @wordpress/a11y script module and a new 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. to pass script module data from the server to the client.
These “CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. Editor Improvement…” posts (labeled with the #core-editor-improvementtagtagA directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.)) are a series dedicated to highlighting various new features, improvements, and more from Core Editor related projects.
Various improvements to font management, including managing font size presets and refinements to the Font Library experience, are coming to WordPress 6.7. Taken together, expect more control over your fonts and an easier time using them exactly as you want. Below is a video showcasing some of these new options and improvements:
Edit and apply font size presets
Create, edit, remove, and apply font size presets with a new addition to the Styles interface. You can now modify presets provided by a theme or create your own custom options. A key feature is the ability to toggle fluid typography, which enables responsive font scaling, with the option to set custom fluid values for finer control over responsiveness. Of note, individual font sizes may opt out of fluid typography if it is turned on globally and vice versa, ensuring more flexibility.
Alongside these overall improvements and new functionality, the Styles interface has been refined to make applying site-wide font changes more discoverable. Namely, the font presets, along with the color presets, are now available to select between from the Styles 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. under the “Browse styles” option. The Font Library is also better surfaced whether you’ve added fonts or not. The aim is to ensure high level font options are right where you want them with more advanced customization options available for anyone who wants to go a step further.
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 7.4 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. ↩︎
You must be logged in to post a comment.