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.
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.
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.
In the spirit of Matt’s “simple things should be easy and intuitive, and complex things possible”, the Query 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_LoopblockBlockBlock 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. has been refreshed with a focus on ensuring the most intuitive default state possible out of the box and increased clarity when trying to achieve anything more complex with custom queries. All of what’s shared below is slated for inclusion in the upcoming WordPress 6.7 release on November 12th, 2024.
Strong defaults
With recent updates, you no longer need to manually enable “Inherit query from template.” The Query Loop block now automatically inherits the query by default, ensuring expected posts are displayed both in the editor and on the front end. This change simplifies the process for most users, who typically just want to see their posts appear without complications. It also minimizes the likelihood of confusion, such as when a Query Loop block is added but posts don’t show up. Now, whenever you add a Query Loop block—whether starting from scratch or using a pattern—your posts will display immediately. This includes when adding a Query loop block to single post or page where the settings will automatically be configured to work in that context. Additionally, the Post List variation has been removed from the Inserter, as its default settings often caused posts to not display, leading to a confusing user experience.
To make this complex block more user-friendly and predictable, the settings have been simplified. Now, there’s a toggle to choose between using the default options or creating a custom query. If you select a custom query, another toggle lets you choose between posts or pages, with the usual filtering options. For custom post types, this section becomes a dropdown for easier selection. In response to feedback about scattered settings for the Query Loop block, options for Posts Per Page, Offset, and Max Pages to Show have been moved to the Settings panel. This change makes the settings 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. the central place to configure the Query Loop block fully.
The details matter, and these refinements are no exception: a preview now appears when selecting the Query Loop block, and the “Add a new post” prompt now reflects the specific type of content you’re querying. The help text for sticky posts has been updated to clarify that sticky posts will always appear first. Additionally, the enhanced pagination setting has been moved to the Advanced section with a new label for better clarity.
To help take steps towards post formats in Block themes, the Query Loop block has a new parameter called “format” that allows you to 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. the content shown by post format, in the same way you’d filter by any other option. This additional filter can be combined with others so you can create custom queries for something as nuanced as posts by a specific author across two categories and with a certain post format.
In the Figma file you can see what is completed by looking for a green circle. Designs in progress have a yellow circle, and anything that is blocked or not planned at this time, is labeled with a red circle.
Work on the style variations. There’s an open issue to address these.
Work on items that are set to [Priority] High.
Once we finish adding the remaining blockBlockBlock is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. patterns and templates, we’ll start adding issues and instructions on how to proceed with i18ni18nInternationalization, or the act of writing and preparing code to be fully translatable into other languages. Also see localization. Often written with a lowercase i so it is not confused with a lowercase L or the numeral 1. Often an acquired skill. (making strings translatable, etc.), indentation, and polishing the patterns/templates.
Open floor
@erichmond brought up that it is difficult to pick issues to work on, and that even if a contributor is assigned to an issue, there may be duplicate pull requests submitted.
The intention is to follow the assignment to the person who has shown interest in the issue first. A recommendation would be to see if there are pull requests open before starting to work on a given issue.
It is difficult to predict what kind of issues that may be open in the repository on the 17th and if they are suitable to work on during a contributor day. A new label in the repository can help contributor day attendees to select issues to work on.
Next major releasemajor releaseA release, identified by the first two numbers (3.6), which is the focus of a full release cycle and feature development. WordPress uses decimaling count for major release versions, so 2.8, 2.9, 3.0, and 3.1 are sequential and comparable in scope.: 6.7
We are currently in the WordPress 6.7 release cycle. WordPress 6.7 BetaBetaA pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. 1 is scheduled for Tuesday, October 1. The Road Map post can be found here.
Next minor releaseMinor ReleaseA set of releases or versions having the same minor version number may be collectively referred to as .x , for example version 5.2.x to refer to versions 5.2, 5.2.1, 5.2.3, and all other versions in the 5.2 (five dot two) branch of that software. Minor Releases often make improvements to existing features and functionality.: 6.6.3
Following the recent WordPress 6.6.2 release, the next maintenance release (if needed) will be WordPress 6.6.3. There were not updates shared in the meeting.
Next GutenbergGutenbergThe Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc.
https://wordpress.org/gutenberg/ release: 19.2
The next Gutenberg release will be 19.2, scheduled for September 11 (this release occurred after the meeting).
Discussion
@peterwilsoncc requested that we discuss the BlockBlockBlock is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. Bindings UIUIUser interface feature, TracTracAn open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress.ticketticketCreated for both bug reports and feature development on the bug tracker.#61945.
To summarize his concern:
My main concern here is that the approach is to hide the UI from users with low permissions. I don’t feel that this is a great approach to handling a UI that is considered too technical, as I don’t think there is anything to suggest that an administrator will understand what an author does not.
So I’m of the view the interface ought to be improved and made less technical before it’s shipped in coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress..
@noisysocks suggested waiting on an update from Mario Santos, who is working on the feature, but added:
I’d be fine with just updating this to use caps. The interface doesn’t strike me as being too technical. Can put it in the Advanced tab if we’re worried…
…The short of it is that I’m okay with fixing the cap issue (add a new cap, don’t check against a role) and shipping in 6.7 or leaving it in the pluginPluginA plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party. for more testing. Up to the team working on it. We have until beta 1 to decide.
@joemcgill highlighted two additional Slack updates this week:
I’ve addressed the feedback by adding a deprecation notice to the pattern rather than removing it. I’d appreciate any thoughts on if this feels like a better approach.
@joemcgill pointed out #62004. @jrf recently asked all committers to review in full here. Julia shared the following updates during the meeting:
Ticket #53010 is basically the first step: splitting up the huge test classes to smaller classes which each only test one thing, i.e. one global function, one method in a class etc.
This includes making sure that the new test files comply with the PHPUnit naming conventions.
There are a number of patches attached to the ticket which can be used to see how to do this (mind: not all have been reviewed yet for the latest info).
I also think it would be great if we could get a decision on yes/no namespacing the test classes. I believe we should and that now is the time.
And followed up with
The other thing which would really really help, is to make sure that any new tests go in “clean”. As in: comply with the requirements for newer PHPUnit versions. The task is large enough as it is without having to clean up after new commits.
Over the years of working on the GutenbergGutenbergThe Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc.
https://wordpress.org/gutenberg/ project, we developed some common practices. These help us preserve the quality and the long-term viability of the project. They differ and often contradict what people are used to in other projects (especially outside WordPress CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress.).
These practices should be applied during implementation and PR reviews. Sharing and embracing them helps contributors make the right decisions and be more autonomous when working on the project.
This list is non-exhaustive and subject to change. These are guidelines to always keep in mind but shouldn’t be treated as hard rules. Context is always important to consider.
Start APIs as private
Gutenberg is organized in packages. Implementing features means introducing new APIs to one or multiple packages. It’s important to understand that most of the packages‘ APIs are public WordPress APIs. Anything exported from a package and consumed by another package becomes a defacto WordPress APIAPIAn API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways.. This API needs to be maintained forever to adhere with the WordPress backwards compatibility strategy. Thus, it’s recommended to start with private APIs.
Be intentional about providing public APIs
Extensibility is important to WordPress. We do want pluginPluginA plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party. authors to extend what WordPress provides. We also want them to reuse tools that WordPress uses internally. This point can read as a contradiction with the previous one. But what’s important here is that it needs to be intentional. Before making an API public during the feature work, we should ask ourselves these questions:
Do we want to allow users to use this API?
And are we willing to support it for the next 10 years without breaking changes?
If the answer to both these questions is yes, then we can consider making this API public.
Avoid opening APIs for convenience, embrace copy/paste
Sometimes, for convenience and to abide to the DRY principle, we, developers create APIs and abstractions. This is seen as a good practice in most projects. But in the context of Gutenberg and WordPress, it is something to avoid. The cost of maintaining APIs is too high because of the backward compatibility strategy.
Say you have a low-level function or component already available to plugin authors or npm package users. To achieve their use-case, they maybe have to write some duplicate boilerplate code. Creating a higher-level abstraction to avoid the duplication should be avoided as much as possible. It is true that providing a great Developer Experience is important, though. There are cases where a higher-level abstraction is required. The main approach is that we should have very strong arguments for it and be intentional.
Prefer Semantic Extensibility
Plugin authors in WordPress want to be able to extend every piece of the UIUIUser interface. They also want to give way too much prominence to their own extensions and upsells. As WordPress history teaches us, this quickly leads to a degraded user experience. Who has never seen a WP Adminadmin(and super admin) with hundreds of notices? Who has never seen a WP Admin with menu items and call to actions competing for the user’s attention?
A non curated set of extensibility APIs can lead to stagnation as well. One example here is the metaMetaMeta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. boxes API in the classic editor and how it created a lot of constraints for the development of the blockBlockBlock is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. editor. These kinds of APIs prevent iteration and evolution. It becomes very hard to improve the UI and UXUXUser experience of these screens. Any change, no matter how small, can lead to breaking changes for plugin authors.
To alleviate these issues, extensibility in Gutenberg is curated and semantic. APIs to register/unregister semantic pieces (blocks, patterns, actions, fields) are preferred. APIs that are too broad and whose purpose is unclear should be avoided. For example:
A slot in the editor headerHeaderThe header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes. is not a very semantic API. It’s unclear what it will be used for. This will prevent any redesign and iteration to the header area of the editor.
The ability to set a priority or order to extensions is often an API that we want to avoid. It’s very prone to abuse. Often, plugins authors use these to give priority to their own extensions over what Core provides. It quickly leads to a degraded experience for users.
One package = one clear purpose
Developing features in Gutenberg often involves modifications to multiple packages at the same time. We need to ask ourselves: where should this piece of code live? To answer the question, it’s important to understand the purpose of each package. Here are some common examples:
Most of the editor UI is built within the @wordpress/block-editor package. So developers often change this package directly to accommodate their specific needs in the UI. The problem though is that it’s not the sole package responsible for adding UI to the editor. It is important to understand that this package is the Tinymce of Gutenberg. It can be used to build and integrate block editors within WordPress and outside WordPress. It’s a framework to build block editors. If a part of the UI is specific to WordPress, it’s not the right place to make this change. A recent example I noticed here is the addition of a button to the block settings menu. That button was used to open the WordPress editor sidebarSidebarA sidebar in WordPress is referred to a widget-ready area used by WordPress themes to display information that is not a part of the main content. It is not always a vertical column on the side. It can be a horizontal rectangle below or above the content area, footer, header, or any where in the theme., but editor sidebars are specific to WordPress block editors.
Making a REST APIREST APIThe REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”)
https://developer.wordpress.org/rest-api/ request in a UI component is another common pitfall that happens often. For example, you may want to build a Language Switcher UI component. And you want it to be reusable in the @wordpress/components package. You can’t use a REST API call within the component to fetch the available languages. The components package is a generic WP agnostic UI components package. So instead, it’s better to have a prop to pass of the available languages instead.
It’s also not recommended to add new packages just to share code between two existing packages. Usually, there’s a better solution to the code sharing problem. @wordpress/utils package doesn’t exist for a reason. Utility packages are a place where we can just dump shared code without purpose. As mentioned earlier, copy/pasting is not always a bad idea when it comes to code sharing. It is preferable to avoid early abstractions as much as possible.
Measure then optimize
We, developers have a tendency to over optimize our code. Often these optimizations involve adding some complexity to the code, making it harder to maintain. It is better to avoid these early optimizations. Instead, measure the impact of the change you want to perform to validate that the optimization is worth the added complexity. Important metrics are tracked in the codevitals dashboard.
Other random common pitfalls
Besides the principles above that one needs to follow to make the right calls, here are some common pitfalls that we’ve learned to avoid over time:
Avoid passing editor settings as inline JSJSJavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors. from the backend to the frontend. It is a pattern we used heavily early in the project. We should ideally move away from it and prefer a better separation between client and server (use REST API calls).
Adding settings to the BlockEditorProvider (and the @wordpress/block-editor package) is ok. But we should be intentional about it: what does the setting mean for third-party block editors? Always remember the block editor framework use case.
Be declarative as much as possible. Using state actions and selectors to share UI state is acceptable. But know that it’s risky. It can lead to bugs and race conditions quickly if multiple components compete to set the right state. This happened to us at least in two recent situations:
Insertion position: We moved away from declaratively computing the insertion position based on the selected block. We used setInsertionPoint action and state instead. The issue is that the inserting point is now incorrectly set at times. Or it persists as we navigate away…
Block editing mode: To support different UI modes for blocks (content-only, locking, template-locked mode, zoom-out mode) we introduced a state to manipulate what we call “block editing mode” using setBockEditingMode action. We now have some hidden bugs because of that. These different modes compete to set the right block editing mode.
Avoid using stores in new packages. Be careful when introducing new data stores. Each time we register a new store, there’s added complexity in the system. Stores are singletons by default, they can only be present once in the page. We do support multiple instances of the same store on the page but it’s not without complexity. We need to extend the global registry. We have also seen that using stores in bundled packages like @worpdress/interface is not a good idea. When a plugin wants to use that package/store it leads to the store trying to be registered twice. The wrong store will be accessed from the components when it happens.
“What’s new 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/…” posts (labeled with the #gutenberg-new tag) are posted following every Gutenberg release on a biweekly basis, showcasing new features included in each release. As a reminder, here’s an overview of different ways to keep up with Gutenberg and the Editor.
The latest Gutenberg release introduces several key updates. Among them is the BlockBlockBlock is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. Bindings UIUIUser interface, which restricts creation and modification to adminadmin(and super admin) users by default but, most importantly, removes the experimental flag from the feature. This version also enhances Zoom Out mode, allowing for more straightforward navigation, includes an experimental feature for client-side media processing, and adds Preview Options extensibility via the PluginPluginA plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party.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.. Alongside these highlights, users will find improvements in data views and refinements to the overall editing experience.
Block Bindings UI out of experimental phase.
In Gutenberg 19.2, the Block Bindings UI has moved out of its experimental phase, marking a significant milestone. Removing the experimental flag means this feature is now integrated into the editor, offering a stable way to connect block attributes to external data sources. By default, only admin users can create and modify these bindings, providing an additional layer of control and security.
Preview Options extensibility via the Plugin API
With this release, the Preview Options have gained new extensibility, making it easier for developers to customize how content is previewed within the block editor. The extensibility feature allows plugins and themes to introduce their own options into the preview dropdown. This provides greater flexibility for users who need to see content in various formats or environments, improving the editing experience.
Other Notable Highlights
New Experiment: Client-side Media Processing: Introduces an experimental feature for processing media client-side, reducing server load and enhancing performance. (#64650)
Zoom Out Mode Enhancements: Adds an “Edit” button to the toolbar and allows users to exit Zoom Out mode by double-clicking blocks. The “Shuffle” block toolbar button has also been removed. (#64571, #64573, #64954)
Content Only Mode: Adds support for block styles on top-level content-only locked blocks and displays block icons in the toolbar. (#64872, #64694)
Changelog
Enhancements
Add: Reorder control at the field level on the new view configuration UI. (64381)
CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. Data Types: recordId can be a number. (64796)
Core Data: Derive collection totals for unbound queries. (64772)
Create Block: Set minimum supported WordPress version to 6.6. (64920)
Dataviews 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. search widgetWidgetA WordPress Widget is a small block that performs a specific function. You can add these widgets in sidebars also known as widget-ready areas on your web page. WordPress widgets were originally created to provide a simple and easy-to-use way of giving design and structure control of the WordPress theme to the user.: Do not use Composite store. (64985)
Dataviews list view: Do not use Composite store. (64987)
Move bulk actions menu to the Footer, consolidate with floating toolbar and total items display. (64268)
Add warning in attributes connected to 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. sources. (65002)
Allow only admin users to create and modify bindings by default. (64570)
Lock editing in fields in editor if metaMetaMeta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. fields panel is opened. (64738)
Rely on Text component instead of Truncate in bindings panel. (65007)
Remove getPlaceholder API and rely on key argument or source label. (64910)
Data Views
Add: Reorder control at the field level on the new view configuration UI. (64381)
Dataviews Filter search widget: Do not use Composite store. (64985)
Dataviews list view: Do not use Composite store. (64987)
Move bulk actions menu to the Footer, consolidate with floating toolbar and total items display. (64268)
Block Editor
Add ‘Reset’ option to MediaReplaceFlow component. (64826)
Block Patterns List: Do not use Composite store. (64983)
Add experiment for client-side media processing. (64650)
REST APIREST APIThe REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”)
https://developer.wordpress.org/rest-api/
Core Data: Resolve entity collection user permissions. (64504)
Block Transforms
Details block: Add transform from any block type. (63422)
New APIs
Extensibility
Editor: Add extensibility to PreviewOptions v2. (64644)
Fix site editor broken when fontWeight is not defined or is an integer in theme.jsonJSONJSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML. or theme styles. (64953)
Fixes the default fluid value on the UI based on the global typography fluid value. (64803)
Block bindings
Change placeholder when attribute is bound. (64903)
Fix empty custom fields not being editable in bindings. (64881)
CSSCSSCascading Style Sheets. & Styling
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. Block: Reduce CSS specificity. (64463)
Retain the same specificity for non iframed selectors. (64534)
Pattern: Don’t render block controls when an entity is missing. (65028)
Site Editor
DataViews: Fix pattern title direction in RTL languages. (64967)
Typography
Site Title, Post Title: Fix typography for blocks with a children. (64911)
NUX
Fix visibility of the template Welcome Guide in the Site Editor. (64789)
Document Settings
Fix: Adjust Site URLURLA specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org Styles to Prevent Overflow in Pre-Publish Component. (64745)
Zoom Out
Focus selected block in editor canvas when clicking edit button on zoom out mode toolbar. (64725)
Templates API
Make plugin-registered templates overriden by themes to fall back to plugin-registered title and description. (64610)
Block Style Variations
Block Styles: Ensure unique classname generation for variations. (64511)
Distraction Free
Make Distraction Free not conditional on viewport width. (63949)
Media
Limit the max width of image to its container size. (63341)
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)
Components
AlignmentMatrixControl: Simplify styles and markup. (64827)
TimePicker: Use ToggleGroupControl for AM/PM toggle. (64800)
Block Editor
Layout content and wide width controls: Remove confusing icon and clarify labels. (64891)
Font Library
Font Library Modal: Group font variations as a list. (64029)
Post Editor
Fix the post summary Status toggle button accessibility. (63988)
Performance
Core Data: Avoid loops in ‘registry.batch’ calls. (64955)
Core data: Performance: Fix receive user permissions. (64894)
Reusable blocks: Fix performance of __experimentalGetAllowedPatterns. (64871)
Corrected HTMLHTMLHyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. Syntax for Closing Tags in api-reference.md file. (64778)
DataViews docs: Fix typo in direction values. (64973)
DataViews: Add story about combining fields. (64984)
[Docs]: Update Usage Example for block variation picker: Fix Import from Wrong Package. (55555)
Code Quality
Button: Add lint rule for 40px size prop usage. (64835)
Dataviews filter: Move resetValueOnSelect prop to combobox item. (64852)
Rename refs to fix tons of ‘Mutating a value’ errors in reactReactReact is a JavaScript library that makes it easy to reason about, construct, and maintain stateless and stateful user interfaces.
https://reactjs.org-compiler. (64718)
Rich text: Add comment on placeholder approach. (64945)
Typography: BackportbackportA port is when code from one branch (or trunk) is merged into another branch or trunk. Some changes in WordPress point releases are the result of backporting code from trunk to the release branch. comment changes only. (64859)
UnitControl: Add lint rule for 40px size prop usage. (64520)
UnitControl: Move to stricter lint rule for 40px size adherence. (65017)
Use rectIntersect instead of a custom argument to rectUnion. (64855)
Site Editor
Add Custom Template modal: Do not use Composite store. (65044)
Video Block: Remove custom CSS code for placeholder style. (64861)
Global Styles
Allow referenced zero value and simplify getValueFromObjectPath calls. (64836)
Navigator: Replace deprecated NavigatorToParentButton with NavigatorBackButton. (64775)
Block Directory
Downloadable Block List: Do not use composite store. (65038)
Design Tools
Color panel hook: Rename to remove ambiguity. (64993)
Tools
Add remaining i18ni18nInternationalization, or the act of writing and preparing code to be fully translatable into other languages. Also see localization. Often written with a lowercase i so it is not confused with a lowercase L or the numeral 1. Often an acquired skill. rules to recommended ESLint ruleset. (64710)
Scripts: Added chunk filename in webpack configuration to avoid reading stale files. (58176)
Scripts: Import CSS files before optimization. (61121)
Summary of the WordPress Developer Blogblog(versus network, site) meeting, which took place in the #core-dev-blog channel on the Make 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/. Start of the meeting in Slack.
Congrats to @ajlendelende and @aljullu to receiving their Documentation Contributor badges for their contributions to the Developer Blog.
Call for contributors to take on What’s new for Developers roundup post for November? @greenshady@ndiego or I (@bph) will be right with you to guide you through the research as well as the writing part. If you want to take it on, come to the #core-dev-blog channel or DM either one of us.
Newly published posts since last meeting
Since the last meeting, we published the following articles
The project board for Developer Blog content is 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/.
If you are interested in taking on a topic from this list or know someone who would be a good person to write about them, comment on the Issue or 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.”@bph in Slack either in the #core-dev-blog channel or in a DM.
The topic idea Modifying text with the HTML API in WordPress 6.7 needs to simmer some more to see if there will be more elaborate examples coming in the next major WordPress version. Justin will bring it back to the October meeting should the topic deemed mature enough for a blog post.
Open floor
@greenshady inquired about the possibility of translating the content of the Developer blog into other languages. Currently, there isn’t a formal proposal for a process and tools. It’s worth exploring, though. It was stated that it’s complicated for Rosetta sites, and it might not be easy to translate. It would be better if the translationtranslationThe process (or result) of changing text, words, and display formatting to support another language. Also see localization, internationalization. can be put right into the adminadmin(and super admin). If there is someone who translated an article, we could publish it on the Dev Blog under “other languages” and once we have a critical mass, we can create categories for Spanish, German etc. The bigger issue than the technological implementation is the recruiting and onboarding of translators to be contributors.
@bph is to reach out to the training team, to learn about their process, as they are a few steps ahead in working with translators.
@greenshady will open an issue, where we can follow up on discussion and progress.
Next meeting: October 3rd, 2024, at 13:00 UTC in the #core-dev-blog channel
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. ↩︎
(published already ) 
You must be logged in to post a comment.