annezazu 5:10 pm on September 23, 2024
Tags: ,   

Proposal: Create connections between Performance Team and Hosts

This post offers a proposal to create a private slackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. 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 loopLoop The 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 CoreCore Core 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.

#hosting, #performance

Andrew Ozz 1:37 am on October 11, 2024
Tags: ,   

Proposal: Make unit test tickets easier to distinguish

This is a follow-up of a conversation in #core on Slack.

Currently there is no easy way to identify TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. tickets specifically for adding unit tests. Some are added to the Build/Test Tools component, however the tests are not really “tools”. The reason for this is that unit tests, just like build and test tools, are “non-production code”. That means they can be committed at any time during the WordPress development cycle and do not follow the general milestones-based workflow.

Additionally, many tickets for adding unit tests are marked as “enhancements”. Following the release cycle workflow, enhancements cannot be committed during betaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. and RCrelease candidate One of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta).. However, in practice unit tests can be committed at any time. It can be difficult to isolate these today, as the Trac search form lacks a filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. for such tickets, which makes triaging a bit harder.

Some suggestions

During the discussion in #core, several ideas were proposed about how this can be made to work better. And while there isn’t currently much traction on adding E2E tests to CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress., any option explored should take this test type into account. In no particular order:

  • Component: A new Tests component, which would be exempt from the general workflow, similar to Build/Test Tools. Example component filter.
  • Focus: A tests focus, similar to the existing docs focus. Example focus filter.
  • Keyword: A tests-only keyword to identify that it’s for unit/E2E tests only, and serve to filter tickets for triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. reports. Example keyword filter.
  • Milestone: An Any Time milestone could indicate when this type of ticketticket Created for both bug reports and feature development on the bug tracker. could be committed, being primarily reserved for tests- and docs-only tickets. Example milestone filter.
  • Type: A test ticket type, to clearly differentiate from the current defect (bug), enhancement, and task (blessed) types. Example type filter.
  • Type (alternative): A new non-production type could be introduced to broadly cover any ticket that does not affect build/production code. Example type filter.

I think that any of the proposed solutions would make searching and triaging test-oriented tickets a bit easier. Some are more flexible in that it’s easier to combine terms (focuses and keywords).

What are your thoughts on these ideas to make test-only tickets easier to distinguish? Please help continue the discussion in the comments below!

Thanks @costdev and @ironprogrammer for the suggestions and reviews.

#proposal, #trac

Jon Surrell 2:20 pm on October 14, 2024
Tags: 6.7, , ,   

Updates to Script Modules in 6.7

WordPress 6.7 introduces a new @wordpress/a11y script module and a new APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. to pass script module data from the server to the client.

Continue reading →

#6-7-2, #dev-notes, #dev-notes-6-7, #javascript

Scott Kingsley Clark 5:10 pm on October 13, 2024
Tags: core-fields,   

Fields API team seeking new leadership

Hello all, I must first preface this by saying this is not a post to get into the specifics of what’s going on with the community right now.

I am no longer contributing to WordPress as things stand. As a result of me stepping down, we need new leadership to take Fields APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. to where it needs to be for WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress..

I have believed over the past decade that we need a Fields API within WordPress itself. I still believe this and many others do too. I’m hopeful someone will step up and hop into the #core-fields channel on the .org SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. to continue coordinating things from where they are. We need someone with passion and the ability to bring everyone to the table.

The vision as it was during WCUS week before things got sidetracked:

  • Data Views are awesome and there are things like the PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher DataKit which prove how we can build upon them without leaving many PHP developers behind
  • Data Forms are really just getting started in core / GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ and it’s important that work is done to open them up to consume configurations from JSONJSON JSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML. or the REST APIREST API The 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/. for screens
  • Both Data Views and Data Forms will eventually spread across the rest of the UIUI User interface like the User edit screen and plenty of other forms — this means the Fields API itself will be spread everywhere if we become integrated properly
  • We should start with the Quick Edit experience which is currently an experiment in Gutenberg you can enable
  • We should offer a PHP API to register ‘forms’, ‘sections’, and ‘fields’ for those forms — however we get there
  • We should include those registered configs in the REST API for the post type

A great deal of research was done originally and Fields API has been through a number of concepts:

There’s so much more I wish I could share in my vision on this and spend lots of time with images + video screencast showing you through what I was extremely excited about at WCUS.

Finally, I want to say thank you to everyone who believed in me and the project. Thank you to many of the Gutenberg contributors who spent their time with me at WCUS contributor dayContributor Day Contributor Days are standalone days, frequently held before or after WordCamps but they can also happen at any time. They are events where people get together to work on various areas of https://make.wordpress.org/ There are many teams that people can participate in, each with a different focus. https://2017.us.wordcamp.org/contributor-day/ https://make.wordpress.org/support/handbook/getting-started/getting-started-at-a-contributor-day/. unblocking our overall goal. They were on board with this. I will always be a fan of those contributors doing their best to make WordPress better.

We were so close here, I believe that if someone steps up then we could see some semblance of a Fields API finally committed to WordPress 6.8. I just won’t be there to enjoy the fruits of that labor.

Goodbye everyone, but I won’t be that far away. I’ll be rooting for those of you making WordPress the best it can be and choosing your own paths going forward. Who knows what the future holds, I may return one day in the future if circumstances change for me personally.

#fields-api

Birgit Pauli-Haack 7:17 pm on October 10, 2024  

Hallway Hangout: What’s next for DataViews and DataForm components (Oct 23, 2024)

Join us on Wednesday, October 23, 2024, 12:00 GMT to discuss what’s next for DataViews and DataForm with Riad Benguella @youknowriad and André Maneiro @oandregal, both working on the feature and the component.  

DataViews and DataForm have been the foundation of the overall admin design efforts, for now, visible in the site editor. PluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party and agency developers can already start using the components for their WordPress customizations. 

The `DataForm` API was introduced in GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ 18.8 as part of a larger effort to reduce duplicated form code in Data Views. Work has continued over the last few releases, and Gutenberg 19.4 added support for the `combinedFields` layout, enabling multiple fields to be rendered in the same row.

Join this informal discussion and learn about the work in progress. Zoom link will be shared in the #outreach SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. channel and in a comment on this post on Oct. 23, 2024

Learn more about the APIs:

GitHubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ issues for context:

Props to @youknowriad and @greenshady for input and review

annezazu 5:15 pm on September 3, 2024
Tags: ,   

Roadmap to 6.7

WordPress 6.7 is set to be released on November 12th, 2024. Along with a new default theme, there are new features, like the ability to zoom out to compose content with patterns, and new APIs, like the Template Registration APIAPI An 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.. More than anything though, this release brings refinement to how everything connects together to create a more seamless WordPress experience, whether you’re trying to upload an HEIC image to your site or display a selection of posts with the Query LoopLoop The 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. blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience..

As always, what’s shared here is being actively pursued, but doesn’t necessarily mean each will make it into the final release of WordPress 6.7.

For a more detailed look at the work related to the block editor, please refer to the 6.7 board and review the currently open Iteration issues. After a recent organization effort, Iteration issues are meant to reflect active work that’s been scoped down for a major releasemajor release A release, identified by the first two numbers (3.6), which is the focus of a full release cycle and feature development. WordPress uses decimaling count for major release versions, so 2.8, 2.9, 3.0, and 3.1 are sequential and comparable in scope.. To get a sense of some of what’s being worked on both for this release and beyond, check out the demos shared in a recent hallway hangout.

New default theme

6.7 marks the next edition of a default WordPress theme, designed to showcase the latest in WordPress and set a new standard for block themers. This year the theme seeks to be the ultimate use case for a spectrum of bloggers: simple blogs, suitable for personal blogs like ma.tt; photo blogs, tailored primarily for photography or portfolios, and complex blogs, suitable for websites that require a wider set of blocks, with more complexity in content, like a news site. 

Four same sized images in a row followed by big, bold text saying Twenty Twenty-Five.

Follow the Twenty Twenty-Five GitHub repo and read the announcement post for more information. 

Foundational experience

Refining Data Views 

After an initial launch in 6.5 and advancements in 6.6, this release is focused on refining the experience with a few new features planned:

Ultimately, the aim is to make these views more flexible for customization and more functional to use. 

Follow this tracking issue for more information.

Polishing the Query Loop 

The Query Loop block is one of the more powerful and complex blocks in the site building experience. While it’s important for the block to be robust in what it can accomplish, it also needs to strike the balance of being intuitive to customize. From reviewing the block’s settings copy to improving the context detection, the Query Loop is being intentionally revisited and improved. 

Follow this iteration issue for more information. 

Zoom out to compose with patterns

With patterns getting more feature-rich and pervasive, the option to zoom out to edit and create at the pattern level over granular block editing is underway. This effort aims to provide a new, high-level approach to building and interacting with your site, with several key features in development:

  • A zoomed out experience in the editor when inserting patterns to facilitate high level overview of the site.
  • A zoomed out experience when adding a new page that emphasizes patterns.
  • Ability to manipulate patterns in the template via moving, deleting, etc while zoomed out, including a new vertical toolbar. 
  • Improvements to UXUX User experience for dragging patterns (e.g. vertical displacement).
  • Option to toggle zoom out on and off in the preview panel. 
  • Option to enter and exit editing at the block level when zooming out. 
  • Advancing contentOnly editing to aid in this new experience. 
Pattern inserter open to Banner patterns with the content of the site zoomed out, showing more of the template that the pattern is going to be added to.

Follow this iteration issue for more information. 

Media improvements

Adding and interacting with media is taking a big leap forward in this release with HEIC support, auto sizes for lazy loaded images, and more background image support at an individual and global level:

Follow this tracking issue for more information. 

View metaMeta Meta 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 in the iframed Post Editor

Previously, after an effort to iframe the post editor, meta boxes prevented the editor content from loading in an iframeiframe iFrame is an acronym for an inline frame. An iFrame is used inside a webpage to load another HTML document and render it. This HTML document may also contain JavaScript and/or CSS which is loaded at the time when iframe tag is parsed by the user’s browser., causing a fair amount of disruption and workarounds. To resolve this and ensure that both metaboxes and canvas content is visible when working on content, a split view is being implemented to allow you to access both. This change will provide a consistent WYSIWYGWhat You See Is What You Get What You See Is What You Get. Most commonly used in relation to editors, where changes made in edit mode reflect exactly as they will translate to the published page. experience between the Editor and frontend views.

Review the PR introducing this change for more information.

Design tools

Consolidating and expanding block supports

Various blocks are loaded up with more supports to achieve ever more designs with a special shout out to the long requested shadow support on Group blocks for designers and themers alike:

  • Buttons: Add border, color, and padding block supports. (63538)
  • Categories: Add border support (63950)
  • Column: Enable border-radius support. (63924)
  • Comment Template: Add Border Block Support. (64238)
  • Gallery: Add border block support. (63428)
  • Group: Add block support for shadow. (63295)
  • Heading: Add border support. (63539)
  • Image: Adopt margin block support (63546)
  • Latest comments: Add color block support (63419)
  • List Item: Add color support (59892)
  • Media Text: Add border support (63542)
  • Paragraph: Add border support (63543)
  • Post Comments Form: Add Border Block Support. (64233)
  • Post Content: Add background image and padding support (62499)
  • Post Date: Add border support (64023)
  • Post ExcerptExcerpt An excerpt is the description of the blog post or page that will by default show on the blog archive page, in search results (SERPs), and on social media. With an SEO plugin, the excerpt may also be in that plugin’s metabox.: Add border support (64022)
  • Post Terms: Add border support (64246)
  • Post Title: Add border support (64024)
  • Quote: Add border support (63544), add spacing supports (63545), add background image and minimum height support (62497)
  • Search: Add margin support. (63547)
  • Site Tagline: Add border support (63778)
  • Site Title: Add border support (63631)
  • Social Links: Add border block support (63629)
  • Term Description: Add border block support (63630)
  • Verse block: Add background image and minimum height support (62498)
View of the border and shadow support controls with the drop shadow options open.

Edit and apply font size presets

The Styles interface introduces an enhanced feature for creating, editing, removing, and applying font size presets allowing users to easily modify theme provided presets and provide custom options. For each preset, custom or otherwise, this also includes the ability to toggle on fluid typography for baked in responsiveness with the option to set custom fluid values.

Review the PR that implements this feature. 

Stabilize experimental block supports

To ensure confidence in using typography block supports for extenders, work is underway to stabilize these options by removing their _experimental status. 

Follow this iteration issue for more information.

API launches and iterations

Template Registration API 

A new API is set to land for WordPress 6.7 to streamline registering templates and template parts for the many plugins that register their own. Previously, plugins needed to rely on several filters to get started, adding a barrier of entry and adoption. With this new API, there will be a more seamless extension experience for developers that aligns with what users have come to expect when interacting with templates and template parts. 

Review the PR introducing this API for more information.

Preview Options API

A new API seeks to extend the Preview dropdown menu in the post/page editor allowing plugins to add custom menu items to the Preview dropdown. This extension point allows for greater flexibility in preview functionality, enabling pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party developers to integrate custom preview options seamlessly into the WordPress editor with the following key features:

  • Introduces PreviewDropdownMenuItem component for adding custom items to the Preview dropdown
  • Allows plugins to add menu items with custom titles and click handlers
  • Maintains the existing Preview dropdown structure while allowing for extensibility

Review the PR introducing this API for more information. 

Interactivity API

In WordPress 6.7, work will continue on internal improvements to ensure that the Interactivity API’s code is as simple and stable as possible and to make the Interactivity API resilient when used asynchronously (e.g., adding directives or stores after initialization). This will pave the way for performance improvements such as directive code splitting or lazy loading of interactive blocks. Finally, efforts are underway to add more built-in functionality to current blocks, starting with adding lightbox support to the Gallery block. 

Follow this iteration issue for more information.

Block Bindings

The Block Bindings API launched in 6.5 and iterated upon in 6.6 allows you to bind dynamic data to block attributes, solving many use cases for custom blocks and powering other features, like overrides in synced patterns. After the 6.6 iteration, several dedicated areas of work are underway with a key focus around adding a user interface (UI) that allows users to connect attributes with their binding sources, making it possible to create bindings through the UI instead of the Code Editor. The block bindings editor’s APIs also need refinement to be more accessible for external developers, as some coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. sources, like “Post Meta,” currently use private APIs to manage bindings. Testing support for additional core sources will help ensure the editor APIs are flexible enough for future needs. There is also work needed to support new features related to pattern overrides.

Follow this iteration issue for more information.

HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. API

Building on recent iterations, the HTML API is focused on improving support across blocks to increase confidence in markup manipulation on the server for block rendering, while ensuring seamless integration with the interactivity API. Efforts are also underway to complete the “IN BODY” insertion mode, initiated in version 6.6, to support most tags in various situations. This work is essential to prepare the HTML Processor for reliable use with any HTML document, allowing Core to build on it without concerns about failures. Feature development is currently aimed at enhancing the CSSCSS Cascading Style Sheets. selector interface by adding querySelector() or a similar method to the HTML API, which is crucial for sourcing block attributes. Additionally, efforts continue on the Server Directive Processor and the replacement of block bindings to rely more on the HTML Processor instead of the Tag Processor.

Follow this iteration issue for more information.

Continuing to improve PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher 8.x support

To continue improving support for PHP 8.x, code specific to prior PHP versions that are no longer supported have been removed.

Find something missing? Want to help?

If you have something you’re working on that you don’t see reflected in this post, please share a comment below so we can all be aware! If you’re reading this and want to help, a great place to start is by looking through each issue associated with each area or by diving into the Polish board where a curated set of issues are in place that anyone can jump in on.

Changelog:

  • September 5th: removed mention of quick edit from Data Views section.

#6-7, #release-roadmap

Stoyan Georgiev 5:21 pm on August 27, 2024
Tags: , , ,   

Bug Scrub Schedule for WordPress 6.7

It’s time to get WordPress 6.7 ready for release, and help is needed to ensure it’s smooth and bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority.-free. Whether you’re an experienced contributor or joining in for the first time, everyone is welcome at our bug scrubs! 🎉

Schedule Overview

Regular bug scrubs are being held every week leading up to the WordPress 6.7 release, with some cases including two sessions a day to cover a broader time frame. As the release date approaches and activity ramps up, the number of scrubs may be increased if necessary. These efforts will help ensure everything is on track for a smooth launch. Participation is welcome at any of these sessions, so feel free to join. Bring questions, ideas, and let’s scrub some bugs together!

Continue reading →

#6-7, #bug-scrub, #core, #props

annezazu 8:50 pm on October 8, 2024
Tags:   

Core Editor Improvement: New features and flows for Font Management

These “CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Editor Improvement…” posts (labeled with the #core-editor-improvement tagtag A directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.)) are a series dedicated to highlighting various new features, improvements, and more from Core Editor related projects. 

Various improvements to font management, including managing font size presets and refinements to the Font Library experience, are coming to WordPress 6.7. Taken together, expect more control over your fonts and an easier time using them exactly as you want. Below is a video showcasing some of these new options and improvements:

Edit and apply font size presets 

Create, edit, remove, and apply font size presets with a new addition to the Styles interface. You can now modify presets provided by a theme or create your own custom options. A key feature is the ability to toggle fluid typography, which enables responsive font scaling, with the option to set custom fluid values for finer control over responsiveness. Of note, individual font sizes may opt out of fluid typography if it is turned on globally and vice versa, ensuring more flexibility.

Font Library enhancements

Fonts are now grouped by source helping you understand at a glance where each font comes from. A new “Select All” option means you can quickly activate or deactivate a set of fonts at once, streamlining font management. When no fonts are installed, a message now displays in the library tab improving awareness around what’s available. Finally, the “No fonts installed” state has been upgraded to better clarify situations when fonts are installed but not yet activated. 

Consistent interfaces

Alongside these overall improvements and new functionality, the Styles interface has been refined to make applying site-wide font changes more discoverable. Namely, the font presets, along with the color presets, are now available to select between from the Styles sidebarSidebar A sidebar in WordPress is referred to a widget-ready area used by WordPress themes to display information that is not a part of the main content. It is not always a vertical column on the side. It can be a horizontal rectangle below or above the content area, footer, header, or any where in the theme. under the “Browse styles” option. The Font Library is also better surfaced whether you’ve added fonts or not. The aim is to ensure high level font options are right where you want them with more advanced customization options available for anyone who wants to go a step further. 

#core-editor-improvement

Dennis Snell 12:30 am on September 11, 2024
Tags: , html-api-progress-report   

Progress Report: HTML API

Quick review

WordPress’s HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. APIAPI An 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?

What’s being worked on right now?

Full HTML support

The major internal changes to the HTML Processor in WordPress 6.6 opened the door to finish adding HTML support, meaning things like TEMPLATE tags, tables, SVG, and forms. These are now all supported in the HTML API.

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> tagtag A 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.

This snippet is equivalent to the following HTML.

2<table><tbody><tr><td>1</td></tr></tbody></table>

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 ReactReact React is a JavaScript library that makes it easy to reason about, construct, and maintain stateless and stateful user interfaces. https://reactjs.org/. avoid these invalidinvalid A 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.

$processor = WP_HTML_Processor::create_fragment( '<main><div>Content here</div></main>' );
if ( $processor->next_tag( 'DIV' ) ) {
    $processor->set_inner_html( 'What will </div> do?' );
}
echo $processor->get_updated_html();

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.

if ( $processor->next_tag( 'DIV' ) ) {
    $processor->set_inner_html(
        '<em class=i class="dup"></p class="not-here"></div><li>1<li>2<!--'
    );
}

echo $processor->get_updated_html();
<main><div><em class="i"><p></p><li>1</li><li>2</li></div></main>

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 CSSCSS Cascading 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 blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. 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 UIUI User interface and UXUX User experience angle.

Native PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher support

The HTML API will be significantly faster when it’s available in PHP, written in C instead of user-land PHP. The first proposal to move the HTML API into PHP itself is in the RFC process, adding a decode_html() function corresponding to the recently-introduced WP_HTML_Decoder class.

Additional notes

An HTML API debugger makes exploring HTML fun

@jonsurrell built a WordPress plugin to add a visual HTML API debugger in wp-admin and it’s built with the Interactivity API. This is a fun tool that shows how the HTML API parses a given HTML input. In addition, it provide insight into the parsing mechanics that lead to the final structure. One can learn a lot about HTML parsing just by seeing how different inputs are processed. For example, the “virtual” nodes in the output represent tags that weren’t in the HTML text but were implicitly created based on HTML’s parsing rules.

Following the progress

For updates to the HTML API keep watch here for new posts.

If you want to follow the development work you can review Trac tickets in the HTML API component or start watching new HTML API tickets from the component overview page. If you want to talk details or bugs or applications, check out the #core-html-api channel in WordPress.orgWordPress.org The 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/ SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/..

See also the previous Progress Report and Updates to the HTML API in 6.6 for recently-completed developments.

Acknowledgements

Thanks to @annezazu, @gziolo, @jonsurrell, @westonruter for review and guidance when writing this post.

  1. “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. ↩︎

#html-api, #html-api-progress-report

Alex Lende 4:03 pm on June 19, 2024
Tags: , , ,   

Theme.json version 3

The theme.jsonJSON JSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML. version is incremented whenever a breaking change would need to be made to the APIAPI An 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 allows consumers to opt-in to the breaking change by updating the version. Older theme.json versions will always be supported in the latest versions of WordPress.

Updating to version 3 is recommended when your minimum supported WordPress version reaches 6.6. See theme.json version 3 frequently asked questions for more information on when to update. Then check out the theme.json reference for migrationMigration Moving the code, database and media files for a website site from one server to another. Most typically done when changing hosting companies. instructions when you are ready to update.

Breaking changes in version 3

Starting with theme.json version 3 the default behavior for using the same slugs as the default fontSizes and spacingSizes presets has been changed to match how other theme.json presets work: from always overriding the default presets to requiring defaultFontSizes or defaultSpacingSizes to be false in order to override the default presets.

Default font sizes

settings.typography.defaultFontSizes is a new option in theme.json v3. It controls whether the coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. provided default settings.typography.fontSizes presets are shown and used.

The default fontSizes presets’ slugs are: small, medium, large, and x-large.

  • When defaultFontSizes is true it will show the default font sizes in the editor and prevent the theme from creating presets using the default slugs.
  • When defaultFontSizes is false it will hide the default font sizes in the editor and allow the theme to use the default slugs.

For blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. themes defaultFontSizes is true by default. This is consistent with how other default* options work such as settings.color.defaultPalette.

For classic themes there is a new theme support default-font-sizes which is also true by default. However, unlike block themes, it is set to false when editor-font-sizes theme support is defined.

In theme.json v2, the default font sizes were only shown when theme sizes were not defined. A theme providing font sizes with the same slugs as the defaults would always override the defaults.

To keep behavior similar to v2 with a v3 theme.json:

  • If you do not have any fontSizes defined, defaultFontSizes can be left out or set to true.
  • If you have some fontSizes defined, set defaultFontSizes to false.
--- theme.json v2
+++ theme.json v3
@@ -1,24 +1,25 @@
 {
-	"version": 2,
+	"version": 3,
 	"settings": {
 		"typography": {
+			"defaultFontSizes": false,
 			"fontSizes": [
 				{
 					"name": "Small",
 					"slug": "small",
 					"size": "10px"
 				},
 				{
 					"name": "Medium",
 					"slug": "medium",
 					"size": "14px"
 				},
 				{
 					"name": "Large",
 					"slug": "large",
 					"size": "20px"
 				}
 			]
 		}
 	}
 }

Default spacing sizes

settings.spacing.defaultSpacingSizes is a new option in theme.json v3. It controls whether the core provided default settings.spacing.spacingSizes presets are shown and used.

The default spacingSizes presets’ slugs are: 20, 30, 40, 50, 60, 70, and 80.

  • When defaultSpacingSizes is true it will show the default spacing sizes in the editor and prevent the theme from creating presets using the default slugs.
  • When defaultSpacingSizes is false it will hide the default spacing sizes in the editor and allow the theme to use the default slugs.

defaultSpacingSizes is true by default. This is consistent with how other default* options work such as settings.color.defaultPalette.

For classic themes there is a new theme support default-spacing-sizes which is also true by default. However, unlike block themes, it is set to false when editor-spacing-sizes theme support is defined.

In theme.json v2, the default spacing sizes were only shown when theme sizes were not defined. A theme providing spacing sizes with the same slugs as the defaults would always override the defaults.

Furthermore, there are two settings that can be used to set theme level spacing sizes: spacingSizes and spacingScale. With theme.json v3, presets from both will be merged together and sorted numerically by slug. Presets defined in spacingSizes will override those generated by spacingScale if the slugs match.

In theme.json v2, setting both spacingSizes and spacingScale would only use the values from spacingSizes.

To keep behavior similar to v2 with a v3 theme.json:

  • If you do not have any spacingSizes presets or spacingScale config defined, defaultSpacingSizes can be left out or set to true.
  • If you disabled default spacing sizes by setting spacingScale to { "steps": 0 }, remove the spacingScale config and set defaultSpacingSizes to false.
  • If you defined only one of either spacingScale or spacingSizes for your presets, set defaultSpacingSizes to false.
  • If you defined both spacingScale and spacingSizes, remove the spacingSizes config and set defaultSpacingSizes to false.
--- theme.json v2
+++ theme.json v3
@@ -1,27 +1,25 @@
 {
-	"version": 2,
+	"version": 3,
 	"settings": {
 		"spacing": {
-			"spacingScale": {
-				"steps": 0
-			},
+			"defaultSpacingSizes": false,
 			"spacingSizes": [
 				{
 					"name": "Small",
 					"slug": "40",
 					"size": "1rem"
 				},
 				{
 					"name": "Medium",
 					"slug": "50",
 					"size": "1.5rem"
 				},
 				{
 					"name": "Large",
 					"slug": "60",
 					"size": "2rem"
 				}
 			]
 		}
 	}
 }

Props to @scruffian and @juanmaguitar for assistance with writing and reviewing this post.

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