Yearly Archives: 2024

Birgit Pauli-Haack 12:11 pm on October 17, 2024
Tags: , , ,   

Roster of design tools per block (WordPress 6.7 edition)

Below you find a table that lists all coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. blocks available in the inserter marks in the grid the feature they support in the 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. editor. It’s a basic lookup table that helps developers to find the information quickly.

While this post is released as part of 6.7, the content summarizes changes between 6.1 and 6.7. This is an updated of the 6.6 edition and provides a cumulative list of design supports added with the last six WordPress releases. The icon ☑️ indicates new in 6.7.

Besides adding Border Controls to a long array of blocks, In version 6.7 writingMode was added to Site title, Site tagline, verse blocks and the button element. As that’s typography subletting it’s not indicated separately in below roster.

The features covered are:

  • Align
  • Typography,
  • Color,
  • Dimension,
  • Border,
  • Layout,
  • Gradient,
  • Duotone,
  • Shadow,
  • Background image
  • Pattern overrides / Block Bindings (PO/BB)

Work in progress

The issue Tracking: Addressing Design Tooling Consistency lists tracking issues for individual block supports.

BlockAlignTypographyColorDimensionBorderLayoutGradientDuotoneShadowBackgr.ImgPO/BB
Archives ✅✅–✅––––
Audio✅––✅–––
AvatarAvatar An avatar is an image or illustration that specifically refers to a character that represents an online user. It’s usually a square box that appears next to the user’s name.✅–✅✅–✅
Button✅✅✅✅–✅–✅✅
Buttons✅✅✅✅☑️✅✅–✅
Calendar✅✅✅––––
Categories✅✅–✅☑️––
Code✅✅✅✅✅––
Column✅✅✅☑️✅✅–✅
Columns✅✅✅✅✅✅✅–✅
Comment Author Avatar–✅✅✅––
Comment Author Name✅✅✅☑️–✅–
Comment Content✅✅✅☑️–✅–
Comment Date✅✅✅☑️––
Comment Edit Link✅✅✅☑️––
Comment Reply Link✅✅✅☑️––
Comment Template✅✅–✅–––
Comments✅✅✅✅✅–
Comments Pagination✅✅✅––✅–
Comments Pagination Next✅✅–––✅–
Comments Pagination Numbers✅✅–––✅–
Comments Pagination Previous✅✅–––✅–
Comments Title✅✅✅✅✅–✅–
Cover✅✅✅✅✅–✅✅
Details✅✅✅✅✅✅
Embed✅–✅–––
File✅–✅✅☑️–✅–
Footnotes✅✅✅✅
Gallery✅✅✅☑️✅✅–
Group✅✅✅✅✅✅✅–☑️✅
Heading✅✅✅✅☑️––⭐️
Home Link – Navigation✅–––––
HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers.––––––
Image✅–☑️✅–✅✅✅
Latest Comments✅✅☑️✅✅––
Latest Posts✅✅✅–✅–✅
List✅✅✅☑️––
List Item✅–✅☑️––
Login/logout––––––
Media & Text✅✅✅✅☑️–✅–
More (Read More)––––––
Navigation✅–✅–✅–
Navigation Link✅–––––
Navigation Submenu––––––
Next Page (Page Break)––––––
Page List✅–––––
Paragraph✅✅✅☑️–✅–✅
Post Author✅✅✅☑️–✅–
Post Author Biography✅✅✅☑️–✅–
Post Author Name✅✅✅☑️–✅–
Post Comments Count✅✅✅––✅–
Post Comments Form✅✅✅☑️–✅
Post Comments Link✅✅✅––✅
Post Content✅✅✅✅☑️✅✅✅
Post Date✅✅✅☑️–✅–
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.✅✅✅☑️–✅–
Post Featured ImageFeatured image A 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.✅–✅✅–✅✅
Post Navigation Link✅✅––––
Post Template✅✅✅✅–✅✅
Post Terms✅✅✅☑️––
Post Title✅✅✅✅☑️–✅–
Preformatted✅✅ no link✅☑️–✅–
Pullquote✅✅✅✅✅–✅–✅
Query✅–––✅–
Query No Results✅✅✅–––✅–
Query Pagination✅✅––✅–
Query Pagination Next✅✅–––✅–
Query Pagination Numbers✅✅–––✅–
Query Pagination Previous✅✅–––✅–
Query Title✅✅✅✅☑️–✅–
Quote✅✅☑️–––☑️
Read More✅✅✅✅––
RSS––––––
Search✅✅☑️✅–✅–
Separator✅–✅✅––✅–
Site Logo✅–✅✅–––✅
Site Tagline✅✅✅✅☑️––
Site Title✅✅✅✅☑️––
Social Link––––––
Social Links✅–✅✅☑️✅✅–
Spacer––✅–––
Table✅✅✅✅✅–✅–
Tag Cloud✅✅–✅☑️––
Template Part✅
Term Description✅✅✅✅☑️––
Verse✅✅✅✅–✅–☑️
Video–✅–––

Props to @fabiankaegy for review.

#6-7, #dev-notes, #dev-notes-6-7, #editor

Dennis Snell 10:27 am on October 17, 2024
Tags: , ,   

Updates to the HTML API in 6.7

After important internal changes to the HTML API in 6.6, WordPress 6.7 brings forward a major leap in support with the HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. Processor.

Major Updates

Full HTML Support

After a long time of only supporting a subset of HTML, the HTML Processor now supports practically all HTML and all HTML tags1. The internal work during the past few releases made it possible to add the remaining support needed to tackle all the colorful varieties of HTML that exist. Only in the rarest situations will the HTML Processor now give up, and in none of these cases is it because the processor doesn’t know how to handle a given 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.).

Effectively, the HTML 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 entering a new phase, where the rules for understanding HTML are finally baked in, and the API can start to proliferate into new developer APIs and replace older and buggier HTML processing code.

Ability to modify most text in a document

The first of a new set of modification methods has been added to the HTML API: set_modifiable_text(). When paused on a text node, a special self-contained element like SCRIPT, STYLE, or TITLE, or on a comment, it’s possible to replace the text content of that node.

while ( $processor->next_tag( 'SCRIPT' ) ) {
    $existing_script = $processor->get_modifiable_text();
    $prefix          = "// Careful, this is executable!\n";
    $processor->set_modifiable_text( "{$prefix}{$existing_script}" );
}

This method will handle the appropriate escaping for the kind of node it is. For example, it will escape the text for a SCRIPT element in a different way than for a STYLE element or a raw text node. This is important, because it means you don’t have to think about what kind of text it is, but it will remain reliable.

It’s important to understand here that this operates on the level of individual text nodes. set_modifiable_text() is different than set_inner_text(). A given element may contain multiple text nodes which are separated by things like HTML comments, specific byte sequences, and 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. markup which is interpreted as a comment. For set_inner_text() it will be best to wait until the HTML API itself supports these operations.

A full-parser mode in the HTML Processor

Until now, the HTML Processor has provided a slightly unexpected interface. Creating a processor involved a call to create_fragment(), which creates something called a “fragment parser.” There was a good reason for this: the fragment parser is the version that’s used in JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com when assigning node.innerHTML = newHtml. Unfortunately, the fragment parser cannot ingest an entire document from start to finish. If you worked with the HTML Processor you would have noticed that it gave up as soon as it found the starting <!DOCTYPE html> or <html> tokens.

In WordPress 6.7 the HTML Processor offers create_full_parser() to fill this need. Thanks to completing support for all of the remaining contexts in a document, the HTML Processor can now start with arbitrary HTML and understand how it turns into a DOM tree.

While possibly unexpected, the default implementation with the fragment processor is still the best option in most cases. If you’ve ever had to deal with HTML parsing libraries adding <!DOCTYPE html><html><head> (and other tags) to the start of every snippet of HTML that they process, it’s because these tools are performing full parses and full serialization. When working with anything other than a complete HTML document, the fragment parser remains the most appropriate tool. Process fragments of HTML with the fragment parser, and full documents with the full parser.

Normalization of input documents

With the HTML specification rules in place it’s possible to start building higher-level tools and helpers without having to worry about the complexities of HTML. The first of these is WP_HTML_Processor::normalize(), which gives us the HTML we always wanted. Normalizing is the process of taking any HTML input and returning a fully well-formed equivalent document. Since a picture is worth a thousand words:

$html = '</p><p class=wp class=duplicate><[GETTING[started]]><p><?not a tag?></p done=yet?><script><!--<script></script>';
echo WP_HTML_Processor::normalize( $html );
// <p></p><p class="wp">&lt;[GETTING[started]]></p><p><!--?not a tag?--></p>

This little function is packed with utility. It interprets the input HTML the way a browser would, meaning that it applies all of the complicated parsing rules, and it prints out a new serialization of that parsed structure. Attribute quoting, mismatched tags, missing tags, invalid syntax, unexpected whitespace, comments, and more – it prints out tags without duplicates, where each value is double-quoted, where all relevant syntax characters are encoded, and it even removes partial tokens at the end of the input. That’s right, normalize() won’t leave you hanging – literally!

$html = 'Just a <em>sneaky but <!-- foiled attempt to hide the rest of the page';
echo WP_HTML_Processor::normalize( $html );
// Just a <em>sneaky but </em>

Significantly, there’s something extremely valuable in the output of this function: once HTML has been normalized, it’s considerably safer to process with naive parsing tools. There’s a guarantee on how the text it produces will appear, so string-based and regular-expression-based tools will instantly become more reliable; the edge cases they fail to handle will never make it out of normalize().

CSS selectors and HTML interact via the document mode, which is either in standards mode or quirks mode. In standards mode, CSS selectors match classes and IDs in a byte-for-byte match. Otherwise they are matched in an ASCII case-insensitive manner. Confusing!

Thankfully, the entire HTML API was audited to ensure compliance even in how CSS class selectors work, and the behavior of methods like has_class(), add_class(), and remove_class() will now respect each document’s mode. For almost every case this should be the “standards mode” and so both of the HTML API processors default to it, matching class names in a byte-for-byte manner. When creating an HTML Processor though with the full parser, since it’s able to determine the document mode from the input HTML, it will make the same choice a browser makes, and when appropriate, will match case-insensitively.

Important changes for existing code.

There should be no significant changes required to existing code written with previous versions of the HTML API. While almost all HTML documents are now supported, it’s still required to verify if the HTML Processor bailed while attempting to process unsupported input.

There were several changes to the way null bytes and whitespace are handled in specific circumstances. These cases represent invalid sections of documents and normal HTML inputs aren’t affected by them.

Since changes were also made with the handling of ASCII casing in CSS class names, there may be cases where a class name previously matched and now won’t. For example, a browser will not match the CSS class name selector for full-width with an element containing FULL-WIDTH in its class attribute unless the document is parsed in quirks-mode. The HTML API is now processing its inputs in standards mode, matching the behavior of a browser, unless created with a full parser containing the appropriate DOCTYPE to indicate quirks mode. Code that relied on has_class() need not change, but the results in WordPress 6.7 may be different at times because it has become more reliable to the proper handling of these class names.

Enhancements

  • Low-level parsing updates improved the scanning speed of the Tag Processor by 3.5-7.5%. [Core-61545]
  • When removing class names, leading whitespace in front of the class name is now removed. [Core-61531]
  • CSS class names and class selectors behave according to the document mode for the input document, or standards mode if none can be directly inferred. [Core-61531]
  • Improved spec-compliance by handling remaining HTML tags and insertion modes, including SVG, TABLE, TEMPLATE, and more. [Core-61576]
  • Added WP_HTML_Processor::create_full_parser() to process entire HTML documents from start to finish. [Core-61576]
  • Added get_qualified_tag_name() and get_qualified_attribute_name() to return case-variants for certain tags inside foreign content where the HTML rules specify. [Core-61576]
  • It’s now possible to replace the value of modifiable text. [Core-61617]
  • Added get_unsupported_exception() to provide more debugging information when the HTML Processor bails on unsupported input. [Core-61646]
  • set_attribute() returns false when WordPress rejects the update. [Core-61719]
  • Added subdivide_text_appropriately() to aid in algorithms wanting to skip null byte or whitespace-only prefixes of text nodes. [Core-61974]
  • Added normalize() and serialize() to return a normalized representation of parsed input HTML. [Core-62036]

Bug Fixes

  • class_list() now replaces null bytes with the Unicode replacement character. [Core-61531]
  • The HTML Processor now properly generates implied end tags. Previously, in some cases, it would generate the end tag but leave the element open on the stack of open elements, leading to mistakes in how it handled later tags in the document. [Core-61576]
  • The HTML Processor now respects the array form of a next_tag() query when specifying the tag_name. [Core-61581]
  • The HTML API no longer hangs when fed documents ending with open SCRIPT elements and which end in one of the - or < characters. [Core-61810]
  • The Tag Processor now reports all un-closed funky comments as having paused at incomplete input. Previously, when the document ended immediately after opening the funky comment, e.g. </# with no more characters, it failed to report the incomplete token. [Core-61831]
  1. There are some unusual situations in HTML which are not supported. They relate to what HTML calls “fostering” and “adoption,” where a node’s placement in the document tree does not correspond to where it appears in the HTML source. This arises in roughly 0.5% of all websites on the web and isn’t currently supported in the HTML API. The deprecated PLAINTEXT element is also unsupported. ↩︎

Props @jonsurrell and @fabiankaegy for review.

#dev-notes, #dev-notes-6-7, #html-api

Joe McGill 10:00 pm on October 15, 2024
Tags: , ,   

Agenda, Dev Chat, Oct 16, 2024

The next WordPress Developers Chat will take place on Wednesday at 01:00 UTC in the core channel on Make WordPress Slack.

The live meeting will focus on the discussion for upcoming releases, and have an open floor section.

Additional items will be referred to in the various curated agenda sections below. If you have ticketticket Created for both bug reports and feature development on the bug tracker. requests for help, please continue to post details in the comments section at the end of this agenda.

Announcements

WordPress 6.7 Beta 3 was released on October 15. Thank you to everyone who contributed to this release and attended the release party! There is a helpful guide here on how to help test this release.

Forthcoming releases

Next major releasemajor 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.: 6.7

We are currently in the WordPress 6.7 release cycle. WordPress 6.7 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). 1 is scheduled for Tuesday, October 22. For specific release times, review the release party schedule post.

Next maintenance release

There are no maintenance releases planned at this time.

Next 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/ release: 19.5

The next Gutenberg release will be 19.5, scheduled for October 23, and will include the following issues.

Discussions

The discussion section of the agenda is to provide a place to discuss important topics affecting the upcoming release or larger initiatives that impact the CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Team.

If you want to nominate a topic for discussion, please leave a comment on this agenda with a summary of the topic, any relevant links that will help people get context for the discussion, and what kind of feedback you are looking for from others participating in the discussion.

Highlighted Posts

Editor updates

You can keep up to date with the major Editor features that are currently in progress by viewing these Iteration issues.

A reminder that there are a number of bugs on the 6.7 Editor project board that need addressing. Specifically, the new Zoom Out Mode has many issues. Most are minor, but additional help on these would be great.

Open floor

Any topic can be raised for discussion in the comments, as well as requests for assistance on tickets. Tickets in the milestone for the next major or maintenance release will be prioritized.

Please include details of tickets / PRs and the links in the comments, and if you intend to be available during the meeting for discussion or if you will be async.

#6-7, #agenda, #dev-chat

Emily Clarke 4:05 pm on October 15, 2024
Tags: , , , ,   

Performance Chat Summary: 15 October 2024

Meeting agenda here and the full chat log is available beginning here on Slack.

Announcements

  • Welcome to our new members of #core-performance
  • WordPress 6.7 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. 3 is October 15, with RC1 on October 22
  • Reminder due to daylight savings, this meeting will shift to 16:00 UTC from October 29

Priority Items

  • WordPress performance TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. tickets
  • Performance Lab 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 other performance plugins)
  • Active priority projects

WordPress Performance Trac Tickets

Performance Lab Plugin (and other Performance Plugins)

  • @westonruter Yesterday a major improvement to Optimization Detective was merged, Leverage URL metrics to reserve space for embeds to reduce CLS. On the surface this improves the Embed Optimizer plugin so that layout shifting caused by embeds (e.g. Tweets) is nearly eliminated. Under the covers, the improvements here change when a gathered URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org metric is sent: instead of being sent after page load, it is sent later on when the page is left. This opens the door for capturing more metrics during the life of the page, including INP metrics. Additionally, this PR introduces a client-side extension framework using script modules.
  • @swissspidy will attempt to expand OD for video poster images this week
  • @joemcgill Last week, I updated https://github.com/WordPress/performance/issues/1511 with a summary of some technical discovery work from @mukesh27 and I, and shared that we’ll be picking up work on an implementation that uses the 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. context 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 improve sizes calculations based on layout context.
    • In support of that effort, we’re still working on solving #62046. The latest PR for that is here, which I hope to get some time to review today

Active Priority Projects

    Improving the calculation of image size attributes

    • Updated shared above

      Enable Client Side Modern Image Generation

      • @swissspidy Slow progress at the moment, GB folks are busy with 6.7 so I don’t really get much feedback for any open PRs. Also, a key dependency I’m using for web workers was just deprecated, so now I need to consider alternatives 

      Enhance Onboarding Experience of Performance Lab Plugin

      • @flixos90 This already predated last week’s meeting, but I don’t think I shared it here: In https://github.com/WordPress/performance/issues/1032#issuecomment-2384151984 I summarized some of the responses for the onboarding feedback form so far.
        • I think the biggest priority based on the onboarding feedback is to make the feature/plugin activation work via AJAX. Because right now it results in a fresh page load, it means quickly activating multiple features is unnecessarily slow. It can sometimes even lead to weird errors if users click multiple buttons too fast (before the page reloaded)
        • @flixos90 to open an issue for this

      Open Floor

      • @mukesh27 ran the benchmark for 6.7 Beta 3 and it shows the regressionregression A software bug that breaks or degrades something that previously worked. Regressions are often treated as critical bugs or blockers. Recent regressions may be given higher priorities. A "3.6 regression" would be a bug in 3.6 that worked as intended in 3.5.. For more details https://wordpress.slack.com/archives/C02KGN5K076/p1728969097396969
      • @adamsilverstein I have been working on a colab to measure the impact of the Improved Responsive Images plugin / improved sizes work. I plan to keep expanding it, but results look promising so far
      • @adamsilverstein At a high level, sites installing the plugin saw a 4 or 5 % improvement in CWV pass rates (mobile/desktop)
      • @westonruter Any idea why this would be since only lazy-loaded images get auto-sizes? Which in theory wouldn’t be relevant for LCP? Are some of the lazy-loaded images with auto-sizes erroneously in the initial viewport, and so a smaller size of the image is getting downloaded and thus is reducing networknetwork (versus site, blog) contention for the LCP image?
      • @joemcgill I’ve wondered the same thing. At least part of this could be that some of those sites are not lazy loading their LCP images properly. Some of that improvement could also be correlation with other Performance Lap improvements, since it’s hard to isolate causation in these queries
      • @adamsilverstein some of it is correlation – for example when users install more than one optimization at a time; in the colab I’m also digging into some numbers like the Lighthouse “Properly size images” audit that are more directly impacted by the plugin. There we can also see the impact with less image optimization left to do in the audit after the plugin is installed

      Our next chat will be held on Tuesday, October 22, 2024 at 15:00 UTC in the #core-performance channel in Slack.

      #core-performance, #hosting, #performance, #performance-chat, #summary

      Emily Clarke 12:19 pm on October 15, 2024
      Tags: , , ,   

      Performance Chat Agenda: 15 October 2024

      Here is the agenda for this week’s performance team meeting scheduled for October 15, 2024 at 15:00 UTC.

      • Announcements
        • Welcome to our new members of #core-performance
        • WordPress 6.7 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. 3 is October 15, with RC1 on October 22
        • Reminder due to daylight savings, this meeting will shift to 16:00 UTC from October 29
      • Priority items
        • WordPress performance TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. tickets
        • Performance Lab 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 other performance plugins) including:
          • Enhanced Responsive Images
          • Embed Optimizer
          • Image Prioritizer
          • Image Placeholders
          • Modern Image Formats
          • Optimization Detective
          • Performant Translations
          • Speculative Loading
          • Web Worker Offloading
        • Active priority projects
      • Open floor

      If you have any topics you’d like to add to this agenda, please add them in the comments below.

      This meeting happens in the #core-performance channel. To join the meeting, you’ll need an account on the Make WordPress Slack.

      #agenda, #meeting, #performance, #performance-chat

      David Arenas 8:06 am on October 15, 2024
      Tags: , ,   

      Subscribe to changes in the Interactivity API state and context on client-side navigation in 6.7

      Interactivity 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. offers a region-based navigation feature that dynamically replaces a part of the page without a full page reload. In fact, the Query 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. natively supports this feature when the “Force page reload” toggle is disabled. Developers can use the same functionality in custom blocks by calling action.navigate from the @wordpress/interactivity-router script module. In WordPress 6.7, several changes were introduced to improve the developer experience by making the behavior fully predictable.

      During WordPress 6.7 development, we found an issue with the client-side navigation feature the @wordpress/interactivity-router provides: interactive blocks outside of interactive regions could be updated as a result of an actions.navigate call if they depended on state properties. The main problem was that the state properties were always overwritten with the values from the new HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. page, leading to unexpected updates.

      Moreover, the same issue affected blocks using the data-wp-context directive, making them work differently depending on whether they were placed inside a router region. In that case, the context was overwritten anytime the HTML was updated with an actions.navigate call.

      As a result, this “overwrite behavior” was turned off for both the Interactivity API state and context. Calling actions.navigate will now only add new properties to the state or context and will never overwrite existing properties.

      However, updating blocks based on state/context changes is still a legitimate use case. Since WordPress 6.7, a new API is available to subscribe to those changes, exposed from the @wordpress/interactivity module: getServerState() and getServerContext().

      These functions return an object that is analogous to the state/context returned by store()/getContext(), with a couple of differences:

      • The object returned is read-only.
      • The object is updated after actions.navigate() calls, using the values defined in the HTML of the page loaded by actions.navigate().
      • Developers cannot directly use its properties in directives, but they can use callbacks to subscribe to changes in its properties and update the usual state/context.

      The following example is incomplete but explains how to use the new API. Let’s say we want to develop an interactive Quiz block that updates the question on the screen every time the user submits the answer. Below is a simplified HTML snippet for such a block.

      <form
  class="wp-block-quiz-question"
  data-wp-interactive="example/quiz"
  data-wp-router-region="quiz-question"
  data-wp-on--submit="actions.goToNextQuestion"
  data-wp-watch="callbacks.updateQuestion"
  data-wp-context='
    {
      "question": "What is the capital of France?",
      "answers": ["Paris", "London", "Rome", "Berlin"],
      "correctAnswer": 0,
      "nextQuestion": "/link-to-next-question"
    }
  '
>
  <fieldset>
    <legend data-wp-text="context.question"></legend>
    <template data-wp-each--answer="context.answers">
      <div>
        <input
          type="radio"
          data-wp-bind--id="context.answer"
          data-wp-bind--value="context.answer"
        />
        <label
          data-wp-bind--for="context.answer"
          data-wp-text="context.answer"
        ></label>
      </div>
    </template>
    <button type="submit">Submit</button>
  </fieldset>
</form>

      As we can see, the <form> element contains the following directives:

      • data-wp-namespace, with value example/quiz.
      • data-wp-router-region, defining a region that should update on navigation.
      • data-wp-context, with all the data relative to a single question. On the HTML inside the <fieldset> element, we can see all the directives that depend on the context.
      • data-wp-on—submit, which assigns the actions.goToNextQuestion function to navigate to the next question.
      • data-wp-watch, with callbacks.updateQuestion to update the context. This one is important, as it will run every time any read properties inside change, including properties from getServerContext().

      Next is a reduced implementation of these functions:

      import {
  store,
  getContext,
  getServerContext,
} from "@wordpress/interactivity";

store("example/quiz", {
	actions: {
    *goToNextQuestion(event) {
      event.preventDefault();
      const { actions } =
        yield import("@wordpress/interactivity-router");
      yield actions.navigate(getContext().nextQuestion);
    },
  },
  callbacks: {
    updateQuestion() {
      const clientContext = getContext();
      const serverContext = getServerContext();
      clientContext.question = serverContext.question;
      clientContext.answers = serverContext.answers;
      clientContext.correctAnswer = serverContext.correctAnswer;
      clientContext.nextQuestion = serverContext.nextQuestion;
    },
  },
});

      Now, imagine we click “submit” and navigate to the next question, and the Interactivity API runtime receives the HTML below. As we can see, the data-wp-context data has changed in the server. That will trigger the data-wp-watch directive using callbacks.updateQuestion, and the context will be updated in the client, making all the HTML inside <fieldset> to be modified accordingly.

      <form
  class="wp-block-quiz-question"
  data-wp-interactive="example/quiz"
  data-wp-router-region="quiz-question"
  data-wp-on--submit="actions.goToNextQuestion"
  data-wp-watch="callbacks.updateQuestion"
  data-wp-context='
    {
      "question": "Which is the closest planet to the Sun?",
      "answers": ["Mercury", "Venus", "Earth", "Mars"],
      "correctAnswer": 0,
      "nextQuestion": "/link-to-another-question"
    }
  '
>
	<fieldset>
		<!-- The fieldset element's content remains the same. -->
	</fieldset>
</form>

      In order not to extend too much, suffice it to say that the example would be similar for getServerState(), with the difference that the data is defined in the current page with the wp_interactivity_state() function in PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher, instead of the data-wp-context directive.

      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 by the repository owner. https://github.com/ Pull Request: #65151

      #6-7, #dev-notes, #dev-notes-6-7

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

      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, #dev-notes, #dev-notes-6-7, #javascript, #script-loader

      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 7.4 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

      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

      Abha Thakor 11:22 pm on October 10, 2024
      Tags: ,   

      Dev Blog editorial meeting summary, October 3, 2024

      Summary of the WordPress Developer Blogblog (versus network, site) meeting which took place in the  #core-dev-blog channel on the Make WordPress 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/. Start of the meeting on Slack.

      Summary from last meeting on September 5, 2024 – props to @bph

      Agenda

      Site updates and new posts

      Project Board

      • In Progress
        Topics needs review
        Topics need writer
      • Topics to be approved

      Open Floor

      Thanks to everyone who has contributed to the last meeting: Summary of the Developer Blog editorial meeting on 5 September 2024. Thanks to @bph for putting these together.

      No comments on the previous meeting actions and notes.

      Site updates and new posts

      Updates

      Congratulations to Troy Chaplin (@areziaal ) for his first Developer Blog article and obtaining the Documentation Contributor badge.

      The Dev Blog is always keen to welcome new contributors.

      New posts

      A big thank you was shared to both writers and reviewers. Also a thank you to everyone who comments on a proposal and helps move it forward to publication. It really is a community effort.

      Project board status

      @webcommsat: To encourage async contribution and those who are unable to join, as well as gather wider feedback, do add comments after the meeting to the 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 by the repository owner. https://github.com/ tickets that items in this section are linked to.

      Optimizing your WP_Query queries for better performance

      On the first item, optimizing your WP_Query queries for better performance, the second version is available to review. I have it down as a task for later today. Is anyone else also planning to go through it?

      Birgit and I have been going through this last week, and I am hoping to catch up with Olga about it too.

      Aware that WCUS has been in the middle. Thanks Justin and Milana for your comments on this too. Justin and Milana have offered additional assistance on GitHub.

      Create Figma designs for WordPress Block Theme

      There are some comments already on the ticketticket Created for both bug reports and feature development on the bug tracker.. Birgit has suggested some actions.

      If anyone else has comments, please can you add them to the ticket.

      Posts: in progress

      1. Case Study: How Pew Research Center is using the interactivity api to use blocks as interactive components
      2. Why you might not need a child theme
      3. Customizing and extending the Formatting Toolbar
      4. How to build a theme demo with WP Playground blueprints
      5. Tutorial on how to create custom components 
      6. An overview of available directives for the Interactivity API
      7. Classic themes: tutorial on moving away from widgets to template parts

      @ndiego will follow up on Customizing and extending the Formatting Toolbar.

      @greenshady: there has been a roadblock with the Playground blueprint one. There’s a 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. that’s likely to hold up its progress for a bit. The issue has already been reported and some discussion around it.

      Posts: to-do column, assigned to writers

      1. Overview of the coding standards tooling available to WordPress developers
      2. Tour Guide for First-time writers on the Developer Blog
      3. Migrate classic sidebars and widgets to block for themers
      4. Overview of “block theme” stuff you can do with classic/hybrid themes
      5. Performance best practices
      6. Creating a low-code block theme development workflow with WordPress Playground and the Create Block Theme plugin
      7. You don’t need CSS for that: All the ways you can use theme.json for styling – @greenshady will be looking into this.
      8. Exploring post formats in a block theme world (maybe with 6.7 additions) – this relies on some things that may not be part of WordPress 6.7. @greenshady doing a progress check on it, and believes it’s possible to still do a good walkthrough of what you can do without the extra changes in CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress..
      9. How to add `contentOnly` editing support to a custom block – @ndiego: will start working on the contentOnly one once 6.7 RC1 has passed.

      Approved topics that require a writer

      To be approved

      Lots of new ideas coming in.

      The discussion in this section of the meeting focus on the topic in general and not a review of the proposal.

      Modifying text with the HTML API in WordPress 6.7 (not approved, about to be closed in favor of this new topic/idea by Nick Diego  N ways to use the HTML API in WordPress#313

      To give more context from the last meeting:

      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. @greenshady has brought it back to the October meeting should the topic be deemed mature enough for a blog post.

      Justin commented on the discussion: “I’m leaning toward closing this one in favor of N ways to use the HTML API in WordPress #313

      Let’s get some of those foundational examples in place and wait for set_inner_html() for some ideas around this.“

      The ticket was left open in case anyone had additional ideas, and will be closed shortly.

      Two new topic proposals from @greenshady before this meeting:

      @greenshady: On those two topics, particularly 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. Bindings, they came up late in the Dev Cycle. I think they’d be solid additions to showcase WP 6.7 features. I need to do some more testing myself to roll out better outlines. But anyone is free to pick them up before I get to them (as always).

      @webcommsat thanked everyone for participating. @bph will create issues for each of the approved topics, so they can get on the to do-list.

      Open floor

      Proposal for new content type:

      • @greenshady raised a separate proposal about a content type rather than a specific topic: Snippets/shorts/bite-sized tutorials. “I have a ton of code that doesn’t make sense for long-form tutorials, but they’d make great quick tutorials that’d only take a couple of paragraphs and a single code block to explain. I think they have a place on the Dev Blog, but I wanted to get feedback from you all.”
      • The approved conditional pattern topic would be ideal for this sort of thing.
      • He asked if anyone was opposed to doing some of these smaller tutorials and adding a custom categoryCategory The 'category' taxonomy lets you group posts / content together that share a common bond. Categories are pre-defined and broad ranging./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.) for them (snippets? shorts?).
      • @meszarosrob felt there was value in this idea. Many times I have been inspired by seeing what somebody did.
      • @greenshady: if necessary, offered to write the conditional patterns one as a proof of concept and get feedback from the group

      @webcommsat reminded people to continue to comment on the tickets on GitHub and add ideas for future pieces. Thank you to all contributors during the last month.

      Next meeting

      The next Developer Bog editorial group meeting will be on November 7, 2024, at 13:00 UTC in the #core-dev-blog channel.

      Props to @bph for reviewing the notes.

      #dev-blog, #summary