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.
WordCamp US 2023 will be holding a 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://make.wordpress.org/support/handbook/getting-started/getting-started-at-a-contributor-day/ on August 24, 2023 at the Gaylord National Resort & Convention Center in National Harbor, Maryland, USA. This is a perfect opportunity to attend Contributor Day on August 24, 2023 and join the CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. table in person or online on SlackSlackSlack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/.
🕰️ New contributor orientation will begin at 8:30 AM at 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. Returning contributors are invited to join at 9:30 AM.
If you are wanting to join in remotely and work on tickets, WordCamp US is welcoming remote contributors from 10:00 AM. Information on Contributor Day can be found on the Make WordPress Slack channel:
How to prepare to be productive at Contributor Day
In advance of the Contributor Day, it is recommended that contributors:
Create WordPress account and join the Make WordPress Slack – some help information is available on Learn.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/
And don’t be afraid that someone will take your ticketticketCreated for both bug reports and feature development on the bug tracker. and solve it first, there are more than 8,000 tickets. There are plenty of choices for everyone, and opportunities to collaborate with others. For example, open your new WordPress 6.3 and find the Get Involved tab of the About page. The number of people who worked on this one is around 50.
For more information, see the previous and more detailed post on this topic prepared by Abha Thakor, Jonathan Desrosiers and other contributors to the Core Team.
💡 If you have wished to contribute to WordPress Core, but were not sure how to begin and were telling yourself: “Oh, well, possibly next time”, then this could be your time to get involved. Join the core tables in person or remotely, and seasoned contributors will help you start enjoying working with the code. It is poetry!
Beyond the code there are many different ways to contribute. Follow the links below for the Core-Test team and the Core-Performance team, which will be at WordCamp US Contributor Day. Details of other Core teams at WCUS are being finalized and will be linked from this post.
To ensure the Site Editor can be used by everyone, this hallway hangout aims to dive deep into the current 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) of this new experience with the aim to iterate and improve.
How to join
If you’re interested in joining, the Hallway Hangout will happen on 2023-09-14 15:00. A Zoom link will be shared in the #accessibilitySlackSlackSlack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/ channel before starting and all are welcome to join, whether to listen or participate, for as long or as little as you’d like.
Agenda
At a high level, we’ll go through the following:
Quick intros.
Discussions around current concerns.
Demos of pain points from @alexstine and @joedolson.
Discussion about ways to resolve/address current, known issues.
As a reminder, hallway hangouts are meant to be casual and collaborative so come prepared with a kind, curious mind along with any questions or items you want to discuss around this important area of the project. Outside of the time for demos, we’ll intentionally have space for open discussion.
Font management is planned for WP 6.4 which will include Font Library and Font Face (formerly Fonts 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.) being introduced in CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress..
Font Face is ready.
Last week, the PHPPHPThe web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher backend part of the Font Library was merged into 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/.
Both are disabled from, loading until the frontend piece is ready and merged in Gutenberg.
This is an important release which makes significant changes to improve the accuracy, performance, stability and maintainability of all sniffssniffA module for PHP Code Sniffer that analyzes code for a specific problem. Multiple stiffs are combined to create a PHPCS standard. The term is named because it detects code smells, similar to how a dog would "sniff" out food., as well as makes WordPressCS much better at handling modern PHPPHPThe web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher.
Most rules which were proposed in the Make post from March 2020 have been added to the Coding standards guidelines. Proposed rules which yielded a lot of discussion or to which objections were raised, have not been added. The intention is to publish separate Make posts for each of these over time, to discuss these more controversial proposals further.
For a large number of the new rules, sniffs have been added to WordPressCS to enforce these rules. More sniffs may be added in future WordPressCS releases to comprehensively cover the new and updated rules.
New architecture
WordPressCS previously had only one runtime dependency, which was PHP_CodeSniffer and end-users would need to manually register WordPressCS with PHP_CodeSniffer (or use a Composer 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. to do so).
As of WordPressCS 3.0.0, WordPressCS will have four run-time dependencies and because of this, Composer will be the only supported way to install WordPressCS.
Mind: it is still perfectly possible to install WordPressCS and its dependencies without using Composer. It is just not an installation method for which support will be provided.
PHPCSUtils is a set of utility functions for use with PHP_CodeSniffer. PHPCSExtra is an additional set of sniffs. Composer Installer is a Composer plugin which will make sure that WordPressCS, PHPCSUtils as well as PHPCSExtra will be registered correctly with PHP_CodeSniffer.
New, non-WordPress-specific, sniffs will now be added to PHPCSExtra, while all WordPress-specific sniffs continue to be maintained in WordPressCS. Some of the pre-existing WordPressCS sniffs, which could benefit the wider PHP community, have been removed and replaced by similar (and improved!) sniffs which were added to PHPCSExtra.
Upgrading to WordPressCS 3.0.0
WordPressCS 3.0.0 contains breaking changes, both for people using ignore annotations, people maintaining custom rulesets, as well as for sniffsniffA module for PHP Code Sniffer that analyzes code for a specific problem. Multiple stiffs are combined to create a PHPCS standard. The term is named because it detects code smells, similar to how a dog would "sniff" out food. developers who maintain a custom PHPCSPHP Code SnifferPHP Code Sniffer, a popular tool for analyzing code quality. The WordPress Coding Standards rely on PHPCS. standard based on WordPressCS.
Please read the provided documentation carefully before you upgrade.
WordPress CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. will upgrade to WordPressCS 3.0.0 in the near future as well. Follow 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.#59161 if you want to stay informed and be sure to run composer update --with-all-dependencies once the patchpatchA special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing. has been committed to benefit from the latest & greatest sniff goodies.
Why did it take so long for this release to be “ready” ?
This release is basically the result of four big projects combined. It wasn’t necessarily the intention when work on WordPressCS 3.0.0 started that these projects would be combined into one release, but internal and external influences had an impact on timing, which made it so.
Also, please keep in mind that this project is basically maintained by a very, very small group of unpaid volunteers, who also have real jobs to do.
The four big projects we are talking about are:
A big refactor.
Adding new rules based on the Make post from March 2020.
Making the sniffs compatible with PHP 7.4, 8.0, 8.1 and 8.2 (* 8.2 in so far currently possible as PHP_CodeSniffer doesn’t fully support all 8.2 syntaxes yet).
Improving the available documentation.
Now let’s talk a little about each of these.
The refactor
WordPressCS previously had only one runtime dependency, which was PHP_CodeSniffer and end-users would need to manually register WordPressCS with PHP_CodeSniffer (or use a Composer plugin to do so). PHP_CodeSniffer offers some limited “utility” functions for sniffs and some basic abstracts.
But… WordPressCS – and other external standards, like PHPCompatibility – wanted more utility functions and better abstracts to be available, so these projects added their own and these utilities then had to be maintained in each of those projects.
Moving this work to a separate project was a setback and meant having to rework a lot. This separate project was published as PHPCSUtils in January 2020.
By that time, PHP 8.0 also started to come into play and it was becoming very clear that this would involve lots of changes for Coding Standards projects and both PHP_CodeSniffer, as well as the utilities, would have to be made compatible with PHP 8.0 before a new version of WordPressCS could be released.
In practical terms, most non-WordPress-specific utility functions are now available via PHPCSUtils. The remaining utility functions, i.e. the few exceptions + the WordPress-specific utilities, have all been moved to separate “helper” classes and traits to make the code more re-usable for sniffs not based on the WordPressCS specific base Sniff class.
New rules
The Make post from March 2020 proposed a lot of new rules, which resulted in a healthy discussion on the post and save for a few rules, most of the new rules met with approval.
This meant two things:
Research needed to be done whether there were any pre-existing sniffs that could be used to implement the approved rules.
For anything for which no sniff existed, a new sniff would need to be written.
A whopping 35 new sniffs were written for this release, 32 of these were added to PHPCSExtra, and 3 to WordPressCS itself.
To see a list of all the rules included in a particular standard, use:
vendor/bin/phpcs -e --standard=WordPress
(you can replace WordPress with, for instance, WordPress-Core or Universal or PSR12 to see the sniffs included in a particular standard)
Making sniffs compatible with PHP 7.4, 8.0, 8.1 (and 8.2)
Making a PHP project compatible with a new PHP version is one thing, doing so for a static analysis tool is something else altogether.
Making sniffs compatible with a new PHP version, basically involves three things:
Making sure the existing code will run on the new PHP version without errors or notices.
Making sure that sniffs do not throw a false positive/negative when confronted with a new syntax. Example: if a sniff looks for function calls to analyse and excludes method calls – function calls preceded by a -> or :: -, for PHP 8.0, these sniffs needed to be adjusted to also exclude function calls preceded by the nullsafe object operator ?->.
Add explicit support for new PHP features. Example: if a sniff would examine the name of a class-like structure, like a class, interface, or trait, the sniff would probably benefit from new code to also examine the names of PHP 8.1 enum structures.
Now, aside from 1, for 2 and 3, WordPressCS has a BIG dependency on PHP_CodeSniffer itself as PHP_CodeSniffer needs to support the new syntaxes first before an individual sniff can start to support them.
At the time work started for WordPressCS 3.0.0, PHP_CodeSniffer didn’t fully support PHP 7.4 yet, which added quite some new syntaxes and then PHP 8.0, 8.1 and 8.2 came along adding yet even more.
PHP 7.4, 8.0, 8.1, 8.2 added more new syntaxes to PHP than all of the PHP 5 and 7 releases before it combined.
Now you may ask yourself: “Why should the sniffs take all those new PHP syntaxes into account ?” After all, WordPress still supports PHP 7.0 (PHP 5.6 prior to WP 6.3), so those syntaxes cannot be used in code written for WordPress Core…
Well, the WordPress Coding StandardsWordPress Coding StandardsThe Accessibility, PHP, JavaScript, CSS, HTML, etc. coding standards as published in the WordPress Coding Standards Handbook.
May also refer to The collection of PHP_CodeSniffer rules (sniffs) used to format and validate PHP code developed for WordPress according to the PHP coding standards. are a community standard and WordPressCS codifies this into automated checks and as such, WordPressCS is not only used by WordPress Core, but also by the wider WordPress community, including agencies, plugin and theme authors etc. And plugins and themes may have a higher minimum supported PHP version, especially when we’re talking in-company/closed source plugins and themes.
Aside from that, sooner or later, WP will raise the minimum supported PHP version to a version including these new syntaxes, so the work would need to be done anyway and it’s easier to do this when what’s changed in PHP is still fresh in our minds.
So, a new waiting game started, where PHPCS needed to be updated first, then PHPCSUtils and only then could support for the new syntaxes be added to WordPressCS.
Safe for the PHP 8.2 Disjunctive Normal Form Types, which isn’t supported yet by PHP_CodeSniffer itself, all new syntaxes which were introduced in recent PHP versions are now taken into account in all sniffs in as far as our (my) imagination reached.
If you run into a situation where a sniff appears to not be fully compatible with modern PHP syntaxes yet, please open a bug report.
Improving the documentation
PHPCS has a built-in sniff documentation feature. Until recently, WordPressCS didn’t really support this feature and WordPress sniffs didn’t provide the documentation needed.
A start was made to add documentation to sniffs during the 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://make.wordpress.org/support/handbook/getting-started/getting-started-at-a-contributor-day/ at 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. Europe 2019.
This effort has continued during the WordPressCS 3.0.0 cycle and the majority of sniffs used by and provided by WordPressCS now include documentation with code samples of what a sniff expects.
To view the documentation for any of the included standards use:
(you can replace WordPress with, for instance, WordPress-Core or Universal or PSR12 to see the documentation for other standards)
The future of WordPressCS
While WordPressCS is currently in a good place with this release, this won’t last long with the pace at which PHP is going.
WordPressCS 3.0.0 has costs thousands of hours of work and the vast majority of work has been done by one, mostly unpaid, contributor, with code review support from two fellow maintainers.
If we are being realistic, the bus factor of WordPressCS is 1, which is the most dangerous situation for any project to be in.
A large part of the WordPress community, including WordPress Core, relies heavily on the WordPress Coding Standards for code quality and security checks and while the community has been pretty vocal with copious complaints about the delayed release, barely anyone has stepped up and actually contributed.
The majority of the work for WordPressCS requires specialized knowledge. Knowledge which can be learned with enough time investment, but in recent years nobody has stepped up to do so.
This is an unsustainable situation and it ends now.
Unless funding is found to continue maintaining WordPressCS and its dependencies, the future is bleak and maintenance will be halted.
Let this be a call to action for the corporate/agency users of WordPressCS to come together and figure out a way to fund the continued maintenance and development of WordPressCS as that one person on which the whole project, including all dependencies, leans, is done with the current status quo.
If you want to help change this situation, please reach out to the WordPressCS maintainer team (@jrf, @GaryJ, @dingo_d) via WordPress SlackSlackSlack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/ to discuss.
The Tag Processor was introduced into Core with 6.2, but development on the 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 continuing as we build a more complete system for interacting with HTML. This posts covers why the HTML API was first introduced, how to take advantage of it today, and preview what’s coming with the second phase, the HTML Processor.
Glossary of Terms
HTML API: the new PHPPHPThe web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher subsystem in WordPress designed to reliably and efficiently interact with HTML and HTML-related needs.
HTML Tag Processor: the first (and lower-level) interface in the HTML API. This class scans through an HTML document from 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.) to tag and makes it possible to read and modify attributes on existing HTML tags. Because it’s only tokenizing the input stream, it doesn’t understand HTML structure and can’t match starting and ending tags or know if something is a child element of another.
HTML Processor: the second (and higher-level) interface in the HTML API. This class makes it possible to interact with nested HTML structure, insert and remove tags, change inner and outer contents, and perform complicated and CSSCSSCascading Style Sheets.-based queries. Because it knows the semantic rules for handling HTML it’s able to properly cope with so-called “malformed markup” including unclosed and overlapping tags.
Why was the HTML API introduced?
The Tag Processor is the culmination of many years of struggling to properly handle HTML within WordPress and within PHP. It follows perennial issues surrounding corruption of HTML, security vulnerabilities, and escaping problems. The HTML API has been designed to provide a convenient and reliable way to interact with HTML.
As many of you are already aware, all of the existing tools (mostly regular expressions and DOMDocument) are insufficient for conveniently and reliably querying and modifying HTML. In addition to carrying a heavy runtime cost and raising availability issues, DOMDocument misinterprets HTML for many common scenarios (e.g. it thinks tags can exist inside a TEXTAREAwhich they cannot, and also that <3 is a tag and not a heart which it is – there are too many cases to enumerate here).
DOMDocument was never the escape hatch.
Consider the contents of a function attempting to use DOMDocument appropriately.
// Make sure we parse in HTML mode and not XML mode.
$document = ( new DOMImplementation() )->createDocument( null, 'html' );
// Disable error reporting because it spits out a lot of noise.
libxml_use_internal_errors( true );
// Force HTML5 mode and UTF-8 to avoid encoding troubles.
$preamble = '<!DOCTYPE html><meta charset="utf-8"><body>';
$document->loadHTML( $preamble . $html );
// process the document somehow
// Build the output while avoiding the addition of extra tags that weren't in the source.
$output = '';
$body = $document.getElementsByTagName( 'body' )->item( 0 );
foreach ( $body->childNodes as $node ) {
$output .= $document->saveHTML( $node );
}
return $output;
This code looks like it should be solid and supporting everything it needs to, but in fact it still fails in a variety of common kinds of input.
<script>
<!-- console.log( "<script>This is just text</script>" ); -->
</script>
In this case DOMDocument converts the --> into -->, which leaves the SCRIPT element unclosed, and this will cause the following HTML to be interpreted as JavaScriptJavaScriptJavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser.
https://www.javascript.com instead of as HTML.
<textarea>This is not an <img src="dangerous.pdf"> because it's inside a </textarea>
Here DOMDocument finds an IMG element inside the contents of the TEXTAREA and will visit it. By interpreting these contents it opens up opportunities for user input to change the parse of the document and lead to unexpected vulnerabilities.
<a title="A ¬in B">A ¬in B</a>
In both the title attribute and the link text the named character reference is 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.. However, in the browser the title attribute evaluates to A ¬in B while the link text evaluates to A ¬in B. DOMDocument breaks the markup by rewriting the link text to the following, which preserves the & in the rendered output instead of interpreting it as the “not in” mathematical symbol.
<a title="A ¬in B">A ¬in B</a>
At face value these may seem like rare exceptions, but many inputs contain these kinds of issues and others that translate into corrupted rendering and worse. Each of these failures presents an opportunity for someone to construct malicious inputs which exploit them to inject unwanted behaviors into your site.
After a sequence of crashing bugs in 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/ related to HTML parsing a couple of developers reached an exasperated tipping point (that started brewing at least as far back as 2016 with the introduction of srcset support) and determined to build a reliable, performant, and convenient API within WordPress for working with HTML. Typical regexp-based approaches are fast when examined in isolation but are very unreliable; attempts to improve their reliability end up in a never-ending cycle of growing complexity that sacrifices readability and eventually some of the same runtime performance that made them compelling in the first place.
Robust regular expressions are extremely confusing and still unreliable.
Given the following regex-based code, try to determine what the goal of the snippet is, what it’s trying to do.
$class_name = gutenberg_get_elements_class_name( $block );
// Like the layout hook this assumes the hook only applies to blocks with a single wrapper.
// Retrieve the opening tag of the first HTML element.
$html_element_matches = array();
preg_match( '/<[^>]+>/', $block_content, $html_element_matches, PREG_OFFSET_CAPTURE );
$first_element = $html_element_matches[0][0];
// If the first HTML element has a class attribute just add the new class
// as we do on layout and duotone.
if ( str_contains( $first_element, 'class="' ) ) {
$content = preg_replace(
'/' . preg_quote( 'class="', '/' ) . '/',
'class="' . $class_name . ' ',
$block_content,
1
);
} else {
// If the first HTML element has no class attribute we should inject the attribute before the attribute at the end.
$first_element_offset = $html_element_matches[0][1];
$content = substr_replace( $block_content, ' class="' . $class_name . '"', $first_element_offset + strlen( $first_element ) - 1, 0 );
}
return $content;
If you think you can quickly and clearly understand this, did you notice that it breaks if the class attribute is quoted with a single quote ' or without quotes? Did you notice that if there’s an attribute containing > that it breaks apart the tag? Did you notice that it makes the wrong replacement if we find something like <img data-custom-class="zebra" src="zebra.jpg" class="full-width">? Did you notice that it’s calling preg_quote() needlessly? Did you notice that it removes all the existing classes if there’s extra but allowable space in class = "all my existing classes"? Did you notice that it won’t find the attribute if someone spells it in uppercase with CLASS="classes"? Are you confident that you could find this code as the source of a problem that mangles an HTML page?
The above is a typical regular-expression-plus-string-replace approach and it gets complicated.
The following, on the other hand, was an actual update inside of Gutenberg to replace the above with the Tag Processor from the HTML API.
// Add the class name to the first element, presuming it's the wrapper, if it exists.
$tags = new WP_HTML_Tag_Processor( $block_content );
if ( $tags->next_tag() ) {
$tags->add_class( gutenberg_get_elements_class_name( $block ) );
}
return $tags->get_updated_html();
Which would you rather work with?
One may wonder, “why is WordPress only now getting a reliable HTML parser?” or “why hasn’t anyone built this before?” and the answer is probably related to how complicated and major a task it is to build the required safety and security into the system (thanks Matt and Automattic for sponsoring this massive investment into WordPress).
There’s another reason though that isn’t as obvious: it’s easy to push the proverbial cart before the horse with HTML. Tools like DOMDocument expose a full DOM interface, and given that, it seems obvious that it’s the right tool for the job. Surprisingly, this is a rare need and the interface is a poor match for the kind of processing typically done on the server. Typical changes involve things like scanning the HTML for specific content, modifying attributes, or making small changes to the HTML structure. In addition, the server needs to be lean in its memory use and as fast as can be. A streaming parser is more appropriate here but the relative availability of DOMDocument and similar parsers has given the impression that a suitable tool is at hand. It distracted us from simpler approaches that work better for WordPress.
How can we use the HTML API today?
It’s easy to get started with the HTML API today by using the Tag Processor and reading through its documentation. The Tag Processor is useful for reading and writing attributes on HTML tags.
$processor = new WP_HTML_Tag_Processor( $html );
// For all images in a document:
while ( $processor->next_tag( 'img' ) ) {
// If they already have a non-empty ALT text, leave them alone.
$alt = $processor->get_attribute( 'alt' );
if ( null !== $alt && ! empty( $alt ) ) {
continue;
}
// Otherwise try to generate a description for the image
// from an AI source and replace the ALT with that description.
$src = $processor->get_attribute( 'src' );
$alt = ai_generate_image_alt( $src );
if ( null !== $alt ) {
$processor->set_attribute( 'alt', $alt );
}
}
return $processor->get_updated_html();
Here are three quick things to know about the HTML API:
The Tag Processor is the first in a series of new interfaces to work with HTML. It’s a low-level API on top of which more convenient functions are being built. If you want to use it today, the “sweet spot” is replacing existing regular expressions and invocations of DOMDocument where the goal is to modify HTML attributes. More complicated work is possible, but that work will be easier in the future with the expansion of the HTML API.
Updates through the HTML API are properly handled by default. Because it’s aware of the context in which it’s operating, you don’t need to call esc_attr(), esc_html(), or other escaping (or unescaping) functions. The inputs are plain PHP values while the outputs will be the HTML which faithfully represents those values in the browser. get_attribute() will, for example, return " (a double quote) whether the HTML attribute contains """ or '"'.
Today it’s only possible to modify HTML attributes: it’s not possible to insert tags, wrap a tag, replace inner HTML, etc. The HTML API work prioritizes reliability and trust over power and flexibility, so the good things to come will appear in good time as we’re able to build it and maintain full confidence in the system.
What’s in the future for the HTML API?
Working with HTML structure
The most obvious direction for the evolution of the HTML API is the HTML Processor, the high-level counterpart to the Tag Processor. It’s designed to query and manipulate nested HTML structure, providing the ability to do things like add or remove HTML tags, wrap or unwrap HTML tags, replace HTML tags, and more. Expect a CSS selector interface for querying specific locations in a document.
It may not make sense why this wasn’t a basic project requirement – to be able to add a new tag – but there’s a major increase in complexity moving from being able to understand the stream of tokens in an HTML document and being able to manipulate the structure those tags represent. There are far more complicated rules and edge cases (for example, what should occur when closing tags are missing or when tags overlap), and parsing the structure requires more memory and more time. The Tag Processor is designed to present predictable performance, but when examining the structure of an HTML document it’s not possible to provide those same guarantees since the performance also depends on the contents of that document. For this reason the two interfaces will remain separate and serve distinct purposes. In fact, for many cases, even when the HTML Processor is complete there will be good reason to stick with the simpler Tag Processor.
The HTML Processor is being developed and tested in stages.
The HTML Processor in its most basic form was merged into WordPress immediately after the WordPress 6.3 branchbranchA directory in Subversion. WordPress uses branches to store the latest development code for each major release (3.9, 4.0, etc.). Branches are then updated with code for any minor releases of that branch. Sometimes, a major version of WordPress and its minor versions are collectively referred to as a "branch", such as "the 4.0 branch". was created. It includes the most basic scaffolding necessary to provide the means for handling HTML in all its colorful renditions, but does very little at the moment.
It adds a new method for querying a location in an HTML document by “breadcrumbs.” For example, “find the next image that’s a child of a figure element.”
With the scaffolding in place it’s possible to incrementally support more and more of the HTML5 specification. It would have been possible to bring this in all at once, but the absolute minimum size of the change would involve thousands of lines of codeLines of CodeLines of code. This is sometimes used as a poor metric for developer productivity, but can also have other uses. that would be unreasonable for anyone to review or test. By building the smallest usable pieces at a time it gives space to focus on each change and the many complications it might imply.
The HTML Processor is going to be able to add and remove tags.
Before it’s finished, the HTML Processor is going to expose several functions reminiscent of DOM interfaces: set_inner_html(), set_outer_html(), parent_node(), insert_before(), insert_after(), remove_node(), replace_node() etc…
These functions will provide a safe means of modifying HTML content without breaking the document.
The full details of the function names and specific interfaces are currently being explored, but in the end we are going to try and balance two competing tensions: meeting frequent needs for CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress., 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 theme developers within WordPress; and remaining familiar to those who have worked in JavaScript and/or with the DOM.
Some functions will be intentionally distinct from the DOM to communicate the different ways this streaming interface behaves. For example, consider a case where replacing a stretch of text would break the HTML document structure. This isn’t possible when setting node.innerHTML = … from JavaScript, but it might be in the HTML API. In a case like this the function will not be called set_inner_html() because it breaks the expectations one might have for that function. Instead, it might be called something like set_raw_inner_markup() to suggest different or new expectations.
For now, the decisions for how to handle situations like these aren’t answered as they involve careful tradeoffs between performance, clarity, and convenience. This is part of current ongoing explorations as the fundamental aspect of parsing HTML structure progresses.
The HTML Processor refuses to break HTML.
It’s going to have bugs and they’ll be fixed, but the philosophy behind the HTML Processor is that if it ever encounters HTML that it can’t confidently understand and parse, then it will stop processing and refuse to proceed. While this leads to what feels like a slow start in building out the API, it also means that you can trust it from day one to do what it claims to do, and support will only improve with time. You don’t have to worry that it will break with certain kinds of input until the day comes when it has the support for it; instead, the HTML Processor will halt processing and communicate that it encounters unsupported markup.
HTML Templating
One idea that’s particularly exciting is the possibility to use the features from the HTML API (which are normally used for reading HTML) to create a context-aware auto-escaping HTML templating system. We’ve been exploring an sprintf-like function that relies on some obscure HTML syntax to create placeholders that avoid creating new syntax like {$var} or [icon]; whatever is in the template is 100% HTML and will work in any standard HTML editor.
Traditional templating systems are convenient, but also suffer from a few of problems related to their custom syntax. (the use of the triple curly brackets is supposed to be illustrative of the concept and any resemblance to existing templating engines is entirely coincidental).
It can be difficult at times to know what is a template and what is normal HTML, and it can be unclear how syntax errors should be resolved. For example, if wanting to store placeholder values as {{{title}}}, how should this resolve? <a href="/reviews">{{{title</a> It’s not clear if that’s supposed to be normal HTML with three curly brackets or a typo adding the placeholder. It can be even more confusing if HTML existings inside the template: for example, with {{{<em>display_name</em>}}} or <p>{{{count out of {{{available}}} available</p>.
These kinds of template placeholders leave escaping needs up to the programmer. In <a href="{{{url}}}" title="{{{url}}}">{{{url}}}</a> there are three separate ways that the url value needs to be escaped. It’s often possible to add inline filters such as {{{url|attribute}}} or {{{url|json}}} or {{{url|script|json|titlecase|dangit}}} but this is fundamentally a broken process that relies on humans remembering to do the right thing every time.
While some templating systems are supported in popular editors, each one is required to manually add support and manually make choices about the syntax errors and how to represent them. In most cases, unless someone can find an appropriate extension, there’s no syntax highlighting or error linting in an editor for such an HTML template.
If WordPress can provide an HTML templating solution that only uses existing HTML syntax then all editors should at least provide syntax highlighting as HTML is already a universal language. Relying on HTML syntax means that in cases of syntax errors, everyone will agree on how to resolve the error: the browsers, text editors, WordPress, and more. Finally, by parsing a template when rendering it’s possible to know if a placeholder is found within HTML markup, within an attribute, within a script, within a URLURLA specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org-referencing attribute like src or href, and automatically escape provided values as is appropriate.
While this is still early in its exploratory phase and almost all of the details remain unsettled, this will open up a new, clear, and safe way of constructing HTML where WordPress developers are freed from the need to escape values or think about escaping at all. It can make the escaping decisions reliably and the calling code need only to think about the actual data values as PHP sees them.
Expanding access to blocks from within PHP
Finally, one long-awaited feature at the end of this work is gaining access to a 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.’s sourced attributes on the server. Using the CSS selectors in a block.json file, the HTML Processor will be able to read all of a block’s attributes inside PHP (this is all attributes, not only those found in the 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. attributes in the block comment delimiter).
Similarly, being able to read and understand the block markup and attributes on the server also means that it will be be possible to run block updates on posts in the database without loading them in the editor. All you’ll need to update those old blocks is a transformer function and a batch process to bulk-update your posts, pages, widgets, and theme templates.
These updates can happen ad-hoc on render as well and this mechanism is being explored for modifying a rendered block to replace one of its block attributes with values from custom fields and other sources. The ability to parse the HTML and the CSS selector in the block.json attribute definition is what makes this possible.
Rewiring WordPress internals
Having a reliable HTML parser opens a wide range of opportunities that didn’t previously seem possible. It was proposed during the Core merge that the Tag Processor might be able to replace functionality in wp_kses() and in the numerous functions in formatting.php. It may seem odd to consider them HTML parsers since none of the code snippets expressly communicate that’s what they’re doing, but a cursory examination revealed at least 46 different existing HTML parsers in formatting.php alone. These are a handful of regular expressions and state machines in PHP, each of which has its own quirks and failure modes, each of which has its own interface, almost all of which are very similar but subtly different, all of which are unreliable HTML parsers.
It may be possible to replace a significant amount of this legacy code with the HTML API and come out not just more reliable, but potentially faster overall as well. Any of this work will be slow though given the need to be careful and avoid breaking existing code and plugins and themes. Nevertheless, the future is bright in regards to some of the longest-standing sources of corruption and breakage that are due to parsing failures.
Summary
The HTML API is a set of reliable interfaces for reading and modifying HTML from within PHP. It trades some amount of performance in order to avoid breaking pages but remains fast enough to be usable without worry. It borrows the language that HTML uses to talk about itself so that your code can clearly express what it wants in talking about tags, attributes, and classes instead of characters, regular expression patterns, and quoting mechanisms.
As the HTML API is still new, try exploring and see if the Tag Processor can clear up your HTML-mangling code, and if you are feeling adventurous, follow the ongoing work in the HTML Processor.
Following the progress
For updates to the HTML API keep watch here for new posts.
Finally, 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/.
Developer Hours are now firmly established as a regular monthly event in the calendar of WordPress’ developer community.
If you want to catch up with the recordings of previous events they are all available on wordpress.tv and in a YouTube playlist.
The next Developer Hours event is scheduled for Wed 30 August at 15:00UTC.
This session will feature Dennis Snell who will be delivering a presentation on the HTML API and demonstrating what can be achieved with it. This 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. enables new ways to reliably work with and modify HTMLHTMLHyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers., and will help alleviate difficult and tiresome wrangling of regular expressions which was previously the only way to achieve many of the things that the HTML API will enable.
The Tag Processor is already available for developers to use, as of WordPress 6.2, and is the first of a number of technologies which will eventually make up the HTML API.
Dennis is a key member of the team developing the HTML API so there is no-one better to introduce this exciting new technology to us. After his presentation he will be available to answer your questions.
All are welcome. If you wish to join please RSVP on the meetup event. The zoom link will be available there for registered attendees.
The dev blogblog(versus network, site) is going to use the Learn WordPress organization repository on 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 by the repository owner. https://github.com/ to host code samples, gists and the like. That will save writers and editors from having to use their personal GH accounts. @greenshady has volunteered to be the first to use it, and the board will develop some processes and guidelines from his experience. If you have thoughts on anything surrounding these repositories, please share on this GitHub issue.
The Marketing team as of August 2, the Marketing team is sharing Developer Blog posts on the official WordPress social profiles.That means a post author has one more step on the post-publish checklist—write some copy for the social-media post and add it to the issue for the post.
And A tutorial about the highlights of the browser and focus modes of the Navigation was on hold pending the publication of the 6.3 Field GuideField guideThe field guide is a type of blogpost published on Make/Core during the release candidate phase of the WordPress release cycle. The field guide generally lists all the dev notes published during the beta cycle. This guide is linked in the about page of the corresponding version of WordPress, in the release post and in the HelpHub version page..
The group needs some ways to approve topics outside the monthly meetings. As it stands, potential authors are having to wait more than a month for a green light. See the discussion.
Here’s an overview of what’s happened in TracTracAn open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. between July 31 and August 14, 2023:
40 commits
50 contributors
164 tickets created
15 tickets reopened
138 tickets closed
and 5 new contributors in this period ❤️
Status update on the Interactivity API: Get the latest updates on this proposal and where to track its progress. This post also includes info on valuable learning resources so you can dive in and explore the 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.’s possibilities.
What’s new for developers? (August 2023): Do “new shiny objects”, “bag of goodies”, and “kid in a toy shop” spark your interest? Thought so! Check out the newest stuff in 6.3 and 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/ in this latest post on 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/’s own Developer Blogblog(versus network, site).
What’s new in Gutenberg 16.4: Inside: A new progress bar component, updates to the Command Palette and Footnotes 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 auto-inserting blocks are highlighted in the latest 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. release.
See the WordPress 6.3 developer notes. The Field GuideField guideThe field guide is a type of blogpost published on Make/Core during the release candidate phase of the WordPress release cycle. The field guide generally lists all the dev notes published during the beta cycle. This guide is linked in the about page of the corresponding version of WordPress, in the release post and in the HelpHub version page. has had 6,500 views since it was published on July 18!
WordPress 6.3.1
There are some urgent fixes that have been identified for a quick turnaround 6.3.1 release, but as of this writing, timing is still being decided. For the latest updates, follow discussions in the #6-3-release-leads channel.
WordPress 6.4
Stay in the 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 with 6.4 by checking out:
The Rollback Update Failure plugin has received several recent updates, and is awaiting security audit and additional feedback.
Plugin Dependencies
Plugin dependencies (Trac #22316) has been updated with the latest round of feedback, and is ready for commit consideration. Trac #59112 has been created to encompass remaining design input for this feature, which could be incorporated during the feature’s merge to CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress..
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 Contributor Day is next week! There is a Core blog draft underway that aims to promote and provide info to new contributors ahead of the event. The post is to be finalized after Dev Chat, and it is requested that Core community members provide feedback in the #core channel. Core Team RepTeam RepA Team Rep is a person who represents the Make WordPress team to the rest of the project, make sure issues are raised and addressed as needed, and coordinates cross-team efforts.@webcommsat is collating details for the event.
Volunteers Needed
Volunteers are needed to help facilitate in person at tables and remotely on Slack during Contributor Day. Contributors are asked to raise their hand in Slack, or add their name and level of participation in the post comments.
A handful of chat attendees raised their hands to help attend to Core tables throughout the day, as well as help remote attendees in Slack, but there are still no clear Core table leads.
TicketticketCreated for both bug reports and feature development on the bug tracker. Focus
There was a question about whether “ancient” Trac tickets should be a point of focus during Contributor Day, and there was general agreement that good-first-bug tickets were likely better candidates to focus on, given the limited time and resources available at the event.
New contributors to Core are encouraged to set up their local environments in advance of WCUS, and to join the next New Core Contributor meeting on 2023-08-23 at 19:00 UTC in the #core channel.
Fields API
A status update was provided for the WordPress Fields API, with a Make/Core post to come later this week. Those interested in this project are invited to help with project research, stop on by and chat with @sc0ttkclark at WCUS, and to join the conversation over in the #core-fields channel.
6.4 Scrub Schedule
The 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. scrub schedule is still being finalized, but the first session is to take place on 2023-08-17 at 17:00 UTC in #core. All are welcome to join the scrub!
Following sessions are dedicated to move things forward and be ready in time according to 6.4 Release Schedule.
Everyone is welcome to join not only to triagetriageThe act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. tickets but also to look for tickets you can contribute by creating patches, making code review and testing. Keep in mind that all features and enhancements should be in the TrunktrunkA directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running "trunk", then you are on the latest revision. before 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 and most bugs and all strings need to be there before RC1. If you are working on a patchpatchA special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing., plan your contribution to have enough time for other contributors to make suggestions, review and test.
Monday September 25, 2023 at 19:00 UTC for a last scrub before 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
Monday October 16, 2023 at 17:00 UTC for a last scrub before 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
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). Bug Scrubs (if needed)
Focus: issues reported from the previous RC.
TBD
Check this schedule often, as it will change to reflect the latest information.
Regular component scrubs and triage sessions
For your reference, here are some of the recurring sessions:
Have a regular component scrub or triage session? PingPingThe act of sending a very small amount of data to an end point. Ping is used in computer science to illicit a response from a target server to test it’s connection. Ping is also a term used by Slack users to @ someone or send them a direct message (DM). Users might say something along the lines of “Ping me when the meeting starts.”@audrasjb, @oglekler or @marybaum on SlackSlackSlack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/ to have it added to this page.
You can start your own triage sessions
Decide what you want to work on
6.4 triage session are our priority and moving forward tickets which already are scheduled for the release is most needed task. If you want to lead some of them, they can be added on this schedule.
But if you are interested in particular component or user focus, for example to take care about RTL-tickets, this will be most welcome too.
Especially interested can be the session to scrub old tickets. We are continuously closing new tickets with the same topic in favor of existing ones and because these tickets are looking complicated just because they’re age not, so many contributors are eager to work on them, but there are actual treasures hidden among very difficult or tricky topics.
Ping@oglekler or @marybaum on Slack with the day and time you’re considering as well as the report or tickets you want to scrub.
Use this list to focus on highest priority tickets first.
Use this list to focus on tickets that haven’t received love in a while.
Report 6 provides a list of open 6.4 tickets ordered by workflow.
Need a refresher on 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. scrubs? Checkout Leading Bug Scrubs in the coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. handbook.
You must be logged in to post a comment.