Hallway Hangout: Performance Considerations for Block Themes

As more is being done to work on performance as it relates to 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, a hallway hangout has been planned to bring together folks from various backgrounds to see what else can be worked on, unblocked, and better understood. This is meant to be both a knowledge sharing and alignment creating session between folks from various areas including but not limited to @flixos90 @adamsilverstein @spacedmonkey @youknowriad @desrosj @tweetythierry @oandregal @aristath.

If you’re interested in joining, the Hallway Hangout will happen on 2023-01-10 14:30. a Zoom link will be shared in the #core-performance 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 before starting.

At a high level, we’ll go through general intros (what each person does/focuses on), current work underway to address performance, what work is being done specifically for block themes, and general open Q&A. Hallway hangouts are meant to be casual and collaborative so come prepared with a kind, curious mind along with any questions or items you want to demo/discuss.

Recording

Attendees:

@flixos90 @adamsilverstein @spacedmonkey @tweetythierry @oandregal @priethor @clarkeemily @daisyo @greenshady @annezazu @scruffian @josephscott @mihai2u @joegrainger @delawski @sergiomdgomes @luminuu @hellofromtonya mukesh27 Felix Arnes, Didier Mahaux, and Simon (didn’t catch a last name).

Notes

Overall themes to the conversation:

  • There’s difficulty in this work partially due to how backports happen from 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/ to CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. both for finding and fixing regressions.
  • There’s still a big need to have solid measurements and track them in some level of granularity for both Core and Gutenberg.
  • There’s great potential in Block theme performance because of how they are built to improve performance.
  • Some level of changes in performance is okay but we need to avoid major regressions and not let perfect get in the way of good enough.
  • A Performance role for the upcoming 6.2 release squad should be considered to improve coordination between various teams and focuses.

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. performance & avoiding major performance regressions with merging Gutenberg into Core 

  • We kicked the call off discussing issues in 6.1 around caching data in theme.json, which led to a broader discussion around merging Gutenberg into Core in a way that avoids regressions.
  • Andre shared how performance is measured in Gutenberg (typing, time it takes to load a big post, etc) for each release. You can see the results of each test in the various release posts under “Performance Benchmark”.
  • Some performance concerns for 6.1 happened only via manual testing. How can we automatically find this rather than needing to manually manage much of this work?
  • Testing needs to happen both in Gutenberg and with Core.
  • It’s not always easy to spot performance concerns in the Gutenberg 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 for a variety of reasons:
    • How code is ported from Gutenberg to Core making it hard to track problems down with this example shared of the kind of large backports that happen.
    • Iteration happens much faster on the Gutenberg side than Core.
    • Inconsistencies in results depending on the tool used.
  • A question was raised around whether there is load time performance tracking on the front end for Gutenberg. This currently doesn’t exist but it was agreed that it should be explored.
  • Tonya shared how iteration happens much faster on the GB side with Core happening less frequently so when we think about performance, we want to think about strategies for how we can do it on a faster basis. Let’s not wait until we get into Core and let’s retest when it gets added to Core. 
    • Tonya’s team is working on improving the backporting process with sooner and smaller backports to Core to get them in throughout the development cycle. If it’s ready, backportbackport A port is when code from one branch (or trunk) is merged into another branch or trunk. Some changes in WordPress point releases are the result of backporting code from trunk to the release branch. it rather than waiting. 
    • Part of this work is making sure Gutenberg back end code is Core ready (runs against same thing so when backports are ready to go, it’s Core ready). 
    • Tonya is going to do a Make post to cover what her team is working on.
  • Jonny brought up confusion around where to make changes when performance concerns are found. This is a larger conversation and it was agreed to bring that discussion into a different space to preserve the conversation around performance.

Avoiding regressions in Classic themes & how performance is measured

  • Adam brought up an example of a performance concern with Classic themes that has yet to be addressed: https://core.trac.wordpress.org/ticket/56990 
  • Jonny is doing very manual testing to try to catch things as much as possible. Having automated tests would be huge along with being able to generate a spreadsheet comparing RCs, commits, etc.
  • Database queries are usually a sign that something is loading that shouldn’t be loaded. It’s not always obvious but it can act as an early warning sign that something isn’t working.
  • Joseph previously volunteered for the measurement side but got pulled into other things. It sounds like this is still a significant need to figure out, do measurements, and track them in some level of granularity (per day, per commit, per release) for both Core and the Gutenberg plugin. 
  • Sergio shared more around the WordPress.comWordPress.com An online implementation of WordPress code that lets you immediately access a new WordPress environment to publish your content. WordPress.com is a private company owned by Automattic that hosts the largest multisite in the world. This is arguably the best place to start blogging if you have never touched WordPress before. https://wordpress.com/ side of things with lots of tooling being run tools for WordPress.com servers which wouldn’t apply well to this situation since they are not particularly suitable to ongoing development. 
  • Felix discussed measuring server side performance by using server timing metrics to see how many ms certain processes take. In theory, you could have something that could receive server timing metrics. 
  • The performance dashboard for Gutenberg was discussed as a spot to make more robust and port in more tracking: https://codehealth.vercel.app/ 
  • The general topic of how to measure PRs to reflect real improvements in production came up with Andre sharing how depending on the tool used there are wildly different responses in performance impact. 
  • Jonny brought up how complex this can get when you add in object caching, PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher versions, etc. Any performance metrics would need to have a matrix of configurations to cover cases. 
  • In general, need to also look at regressions individually because they might be different to a different degree depending on environment. 
  • An example was shared of how to use the server-timing api in wordpress/gutenberg with an implementation of it to the Performance Lab plugin: https://github.com/WordPress/performance/pull/553 
  • Adam ended this section of the conversation with a great reminder that some level of small changes in performance in normal but we need to avoid major regressions. Let’s not let perfect get in the way of good enough.

Core web vitals and block themes. What parts of Core can be improved out of the box? What are we doing specifically around block themes? 

  • Jonny shared that because of theme.json, Block themes are slower than Classic themes with work underway for them to be on par with Classic themes. There’s an amazing opportunity to do performance work with Block themes because everything is a block. You could prefetch image assets, ensure images above the fold are loaded, etc once you know entire markup of page before headers are sent.
  • Joseph brought up an issue around lazy loading LCP images that was implemented in a previous release but didn’t make it to block themes (only made it to classic). This is pending for the next release
  • Discussed various ways enhancements could happen with script and resource loading (CSSCSS Cascading Style Sheets. file loading, font loading, etc) as well as lazy loading things as well beyond just images (what about CSS?). For example, if a block is in the footer of the page, could load later on.

Thoughts around better ways teams can work together around improving block themes. 

  • In particular, this refers to the Core Editor, Core, and the Performance teams since we’re all ultimately a part of broader WordPress efforts and we can use our unique expertise to be better together.
  • Discussed having another hallway hangout specific for WordPress 6.2 items to have more practical, hands on things to go through.
  • Anne threw out the idea of having a Performance related role for release squad and will follow up to more formerly propose.
  • Jonny brought up ensuring folks are giving the time to respond during releases and to pingPing The act of sending a very small amount of data to an end point. Ping is used in computer science to illicit a response from a target server to test it’s connection. Ping is also a term used by Slack users to @ someone or send them a direct message (DM). Users might say something along the lines of “Ping me when the meeting starts.” early. At the same time, Tonya reminded us to avoid having bottlenecks and to practice reviewing something after it’s merged to still fix what’s found.

Next steps:

  • @hellofromtonya will share a Make post about the work her team is doing at Automattic around more continually backporting items from Gutenberg into Core.
  • @annezazu will suggest a performance role on release squad (with +1 from Tonya, Jonny, and Thierry).
  • @annezazu will follow up with a 6.2 related performance hallway hangout once 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. 1 is released.
  • @adamsilverstein will share a Make post on an automated testing environment and possible steps there.

#hallwayhangout, #performance

Dev Chat Agenda: January 25, 2023

The WordPress developers chat meets in the core channel of the Make WordPress Slack on Wednesday January 25, 2023 at 20:00 UTC.

1. Dev Chat introduction

Summary from last week: January 18, 2023 – @webcommsat

2. Announcements

Gutenbery 15.0 landed last week.

Please add any relevant WordPress announcements in the comments.

3. Posts to note

Proposal: Old Tickets Trac Triage Sessions – these sessions start on January 26 and February 9, 2023 and all are welcome to come and help. If you can host a session, reply on the post.

What’s new in Gutenberg 15.0, January 20, 2023 – @mburridge.

A Week in Core – January 23, 2023@audrasjb

Any additional posts can be added in the comments.

4. Releases

Next major: 6.2

Development Cycle – this has information on the schedule, 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. scrubs, and more.
WordPress 6.2 Editor Tasks board is available.

Update from release squad and discussions to progress the release. 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. 1 is planned for February 7, 2023.

Squad members can also add comments to this post if they are unable to attend the dev chat live.

5. Help requests from component maintainers or for tickets

Component Maintainers or anyone wishing to highlight a ticketticket Created for both bug reports and feature development on the bug tracker. can also comment on this post if unable to attend the meeting live. Priority in the meeting will be given to tickets aimed at 6.2.

6. Open Floor

Please add comments on this post with any items you would like to suggest and indicate if you will be available in the meeting for any questions. The agenda is published the day before the meeting to help enable asynchronous contribution.

  • Reminder: if you are planning something for the coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. tables or can help support them at WordCampWordCamp WordCamps are casual, locally-organized conferences covering everything related to WordPress. They're one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. Learn more. Asia 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/. in February 2023, please can you let abhanonstopnewsuk (on 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/.) know too.

Thanks to @hellofromtonya and @francina for proofing the agenda.

#agenda, #dev-chat, #meeting

Proposal: Old Tickets Trac Triage Sessions

In a few months, we will celebrate the 20th anniversary of WordPress!

To mark the milestone, what could be better than taking a look at all of our old TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. tickets?

This post aims to put together several 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. scrub sessions dedicated to old tickets that haunt the depths of Trac, the ticketticket Created for both bug reports and feature development on the bug tracker. tool used for the development of WordPress.

To date, on Trac, we have for example:

Goal of the “Old Tickets Trac Triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. Sessions” initiative

The purpose of these sessions would be to take the oldest tickets, qualify them and move them forward according to their content or status.

  • Some tickets are probably no longer relevant today with the recent evolution of WordPress, in this case they must be closed as outdated (though this resolution status doesn’t exist in Trac for the moment)
  • Some tickets may require new discussions, this will be an opportunity to discuss them by adding new comments
  • Some tickets may be ready, but don’t have a patchpatch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing. yet, we may be able to find people to take care of it and milestone them accordingly
  • Some tickets also probably have a patch (check for the has-patch workflow keyword), but this one needs to be refreshed (check for the needs-refresh  workflow keyword). In that case we could find someone to take care of it and milestone them accordingly
  • Other tickets may have a patch ready to go (must be quite rare), in this case the idea would be to move them directly to the next milestones (WP 6.2 or 6.3)

How to participate?

Everyone is invited to contribute to this initiative. There could be several types of sessions:

  • “Classic” triage sessions on the 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/. Make, coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. channel, where we would review tickets (read the dedicated post on the Core handbook: Leading a bug scrub)
  • Local triage sessions: local communities, or even companies, are welcome to organize an event to help move forward old tickets

During the meeting, the idea is to take one of the Trac reports listed at the beginning of this post and to go through each ticket.

What can I do to help move a ticket forward?

Depending on its status and progress, several types of contributions can help move a ticket forward:

  • Mark as close tickets that are no longer relevant. A Bug Gardener or a Component Maintainer will close it later
  • Extend the discussion to try to find how to move towards a resolution
  • Try to reproduce a bug that has not been reproduced yet, then share the steps of the reproduction procedure as well as screenshots or screencasts (when applicable)
  • Propose a patch, for tickets that do not yet have one, if the ticket is relevant and the existing discussion has resulted in a conclusion
  • Test existing patches and share screenshots or screencast (when applicable), using the test report template
  • Refresh an existing patch, if the ticket contains a patch that no longer applies to the current state of the WordPress source code

Some of these actions require a developer profile, others are accessible to anyone who knows enough WordPress and is able to run a test site.

Planned meetings

Let’s start with a first session on the Make Slack #core channel on Thursday, January 26, 2023 at 15:00 UTC. This session will last about 1 hour, and everyone is welcome!

If you are interested in hosting an “Old Tickets Trac Triage Session”, feel free to comment on this post!

For more info, read the dedicated post on the Core handbook: Leading a bug scrub.

Planned meetings, as confirmed,will be added to the list below:

DateLocationOrganizer
January 26, 2023 at 15:00 UTC“Classic” triage session on Slack (core channel)@audrasjb
February 9, 2023 at 15:00 UTC“Classic” triage session on Slack (core channel)@audrasjb
Another dateA locationYour name here!

This proposal is a follow-up to a discussion on Twitter with @defries and other WordPress contributors.

Props to @defries, @webcommsat and @costdev for proofreading.

#trac-cleanup, #triage, #wp20

Bug Scrub Schedule for 6.2

With 6.2 well underway, it’s time to schedule the 6.2 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. scrub sessions. These 6.2 specific ticketticket Created for both bug reports and feature development on the bug tracker. scrubs will happen each week until the final release.

Alpha Bug Scrubs

Hosted by @costdev

Hosted by @mukesh27 (APAC-Friendly)

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. Bug Scrubs
Focus: issues reported from the previous beta.

Hosted by @costdev

Hosted by @mukesh27 (APAC-friendly)

Release Candidaterelease 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). Bug Scrubs (if needed)
Focus: issues reported from the previous 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)..

Hosted by @costdev

Hosted by @mukesh27 (APAC-Friendly)

Check this schedule often, as it will change to reflect the latest information.

What about recurring component scrubs and triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. sessions?

For your reference, here are some of the recurring sessions:

Have a recurring component scrub or triage session?
PingPing The act of sending a very small amount of data to an end point. Ping is used in computer science to illicit a response from a target server to test it’s connection. Ping is also a term used by Slack users to @ someone or send them a direct message (DM). Users might say something along the lines of “Ping me when the meeting starts.” @costdev or @mukesh27 on 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 have it added to this page.

Want to lead a bug scrub?

Did you know that anyone can lead a bug scrub at any time? Yes, you can!

How? Ping @costdev or @mukesh27 on Slack with the day and time you’re considering as well as the report or tickets you want to scrub.

Planning one that’s 6.2-focused? Awesome! It can be added it to the schedule here. You’ll get well deserved props in Dev Chat, as well as in the #props Slack channel!

Where can you find tickets to scrub?

  • Report 5 provides a list of all open 6.2 tickets:
    • Use this list to focus on highest priority tickets first.
    • Use this list to focus on tickets that haven’t received love in a while.
  • Report 6 provides a list of open 6.2 tickets ordered by workflow.

Need a refresher on bug scrubs? Checkout Leading Bug Scrubs in the coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. handbook.

Questions?

Have a question, concern, or suggestion? Want to lead a bug scrub? Please leave a comment or reach out directly to @costdev or @mukesh27 on Slack.

Props to @hellofromtonya for reviewing the post.

#6-2, #bug-scrub, #core

A Week in Core – January 23, 2022

Welcome back to a new issue of Week in CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.. Let’s take a look at what changed on TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. between January 16 and January 23, 2022.

  • 45 commits
  • 70 contributors
  • 66 tickets created
  • 10 tickets reopened
  • 48 tickets closed

Ticketticket Created for both bug reports and feature development on the bug tracker. numbers are based on the Trac timeline for the period above. The following is a summary of commits, organized by component and/or focus.

Code changes

Administration

  • Use a consistent capitalization in Privacy Policy related strings – #57226

Application Passwords

  • Disable spellcheck for password field – #56763

Build/Tests Tools

  • Add unique messages to assertions for attachment filenames in wp_mail()#28407
  • Correct additional_field_get_callback() parameters in some 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/. tests – #56793
  • Use wp_recursive_ksort() in WP_Theme_JSON_Resolver tests – #56793

Bundled Themes

  • Fix Separator 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. “Dots” style variation on various themes – #56114
  • Twenty Twenty-One: Disable spellcheck for post password field – #56763
  • Twenty Twenty-One: Fix obsolete navigation block styles for better Global Styles support – #53220
  • Twenty Twenty-One: Fix obsolete navigation block styles for better Global Styles support – #53220
  • Twenty Twenty-One: Revert [55088]#53220

Code Modernization

  • Rename parameters that use reserved keywords in phpunit/tests/functions/wpListFilter.php#56788
  • Rename parameters that use reserved keywords in phpunit/tests/functions/wpListPluck.php#56788
  • Rename parameters that use reserved keywords in phpunit/tests/functions/wpListSort.php#56788
  • Rename parameters that use reserved keywords in phpunit/tests/hooks/addFilter.php#56788
  • Rename parameters that use reserved keywords in phpunit/tests/kses.php#56788
  • Rename parameters that use reserved keywords in phpunit/tests/option/themeMods.php#56788
  • Rename parameters that use reserved keywords in phpunit/tests/pluggable/signatures.php#56788
  • Rename parameters that use reserved keywords in phpunit/tests/post.php#56788
  • Rename parameters that use reserved keywords in phpunit/tests/rest-api.php#56788
  • Rename parameters that use reserved keywords in phpunit/tests/rest-api/rest-*-controller.php#56788
  • Rename parameters that use reserved keywords in phpunit/tests/shortcode.php#56788
  • Rename parameters that use reserved keywords in phpunit/tests/widgets/wpWidgetMedia.php#56788
  • Rename parameters that use reserved keywords in wp-includes/functions.php#56788
  • Use correct property in IXR_Message::tag_open()#56790

Docs

  • Further clarify the wp_ajax_save_attachment 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. parameters description – #23148
  • Remove unused post_modified and post_modified_gmt params from wp_insert_post() docblockdocblock (phpdoc, xref, inline docs)#57473, #56792

Editor

  • Add inert attribute polyfill – #57492
  • Allow block pattern categories to have descriptions – #57478
  • Update packages to unblock lazy-loading issues – #56930
  • Updated the bundled block pattern categories – #57479

I18Ni18n Internationalization, or the act of writing and preparing code to be fully translatable into other languages. Also see localization. Often written with a lowercase i so it is not confused with a lowercase L or the numeral 1. Often an acquired skill.

  • Allow installing new translations when changing the user localeLocale A locale is a combination of language and regional dialect. Usually locales correspond to countries, as is the case with Portuguese (Portugal) and Portuguese (Brazil). Other examples of locales include Canadian English and U.S. English. on the profile page – #38664

Login and Registration

  • Disable spellcheck for password fields – #56763

Media

  • Add an action hook on wp_ajax_save_attachment()#23148
  • Allow for customization of lazy-loading featured images – #57490
  • Prevent hidden overflow on uploaded image names – #54812

Menus

  • Hide the “Remove selected item” from Menus screen when no item is selected – #56942

Permalinks

  • Remove floating on Permalinks settings screen – #56673, #55498

Plugins

  • Add visible focus on 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 modal close button – #56604

Posts, Post Types

  • Increase the input field’s width in the Slug metaboxMetabox A post metabox is a draggable box shown on the post editing screen. Its purpose is to allow the user to select or enter information in addition to the main post content. This information should be related to the post in some way.#16346
  • Use persistent caching in get_adjacent_post function – #41131

Quick/Bulk Edit

  • Add an action hook on bulk_edit_posts()#28112

TaxonomyTaxonomy A taxonomy is a way to group things together. In WordPress, some common taxonomies are category, link, tag, or post format. https://codex.wordpress.org/Taxonomies#Default_Taxonomies.

  • Remove placeholder from WP_Term_Query cache key – #57298

Themes

  • Introduce wp_theme_has_theme_json() for public consumption – #56975
  • Revert caching from r55086#56975

Upgrade/Install

  • Disable spellcheck for password field on Setup screen – #56763

Props

Thanks to the 70 people who contributed to WordPress Core on Trac last week: @poena (15), @sergeybiryukov (15), @jrf (14), @aristath (14), @justinahinon (13), @audrasjb (10), @costdev (6), @mukesh27 (5), @sabernhardt (4), @desrosj (3), @spacedmonkey (3), @gainesm (2), @fosuahmed (2), @flixos90 (2), @mamaduka (2), @dziudek (2), @Joen (2), @johnbillion (2), @hellofromTonya (2), @ocean90 (2), @helen (2), @kebbet (2), @peterwilsoncc (2), @joedolson (2), @mcsf (1), @swissspidy (1), @dshanske (1), @Spaceshipone (1), @nithi22 (1), @sarathar (1), @aravindajith (1), @ntsekouras (1), @joemcgill (1), @dd32 (1), @boonebgorges (1), @Otto42 (1), @dmsnell (1), @sumitsingh (1), @oandregal (1), @afragen (1), @alexstine (1), @azaozz (1), @sc0ttkclark (1), @barryceelen (1), @mrasharirfan (1), @umesh84 (1), @amin7 (1), @esratpopy (1), @multidots1896 (1), @ABTOP (1), @nacin (1), @abitofmind (1), @tyxla (1), @helgatheviking (1), @Mte90 (1), @afercia (1), @itowhid06 (1), @hellofromtonya (1), @pento (1), @mensmaximus (1), @dperonne (1), @viralsampat (1), @jeawhanlee (1), @griffinjt (1), @bradyvercher (1), @pputzer (1), @antpb (1), @bjorsch (1), @kraftbj (1), and @mehulkaklotar (1).

Congrats and welcome to our 5 new contributors of the week: @fosuahmed, @amin7, @esratpopy, @ABTOP, @abitofmind ♥️

Core committers: @sergeybiryukov (18), @audrasjb (15), @youknowriad (3), @joedolson (2), @flixos90 (2), @hellofromtonya (2), @spacedmonkey (2), and @swissspidy (1).

#6-2, #core, #week-in-core

WordPress 6.2 Planning Schedule Proposal

As we wrap 2022 with three major releases, it’s time to look ahead and start planning for the following year. In preparation, this post includes proposed target dates and a call for the release squad for WordPress 6.2, the first major release of 2023.

The first-ever WordCampWordCamp WordCamps are casual, locally-organized conferences covering everything related to WordPress. They're one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. Learn more. Asia will take place in February 2023. To accommodate it and avoid having major milestones (Beta1, RC1) very close to the event, the proposed schedule consists of a 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. period consisting of four planned Beta releases, as opposed to the three planned Betas in recent major releases.

According to the schedule proposed below and the 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 cadence, WordPress 6.2 would include up to Gutenberg 15.1 for a total of 10 Gutenberg releases.

Proposed WordPress 6.2 Schedule

MilestoneDate
Alpha (trunktrunk A directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running "trunk", then you are on the latest revision. open for 6.2 release)October 18, 2022
Beta 1 & Feature FreezeFebruary 7, 2023
Beta 2February 14, 2023
Beta 3February 21, 2023
Beta 4February 28, 2023
Release Candidaterelease 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). 1March 7, 2023
Release Candidate 2March 14, 2023
Release Candidate 3March 21, 2023
Dry RunMarch 27, 2023
WordPress 6.2 General releaseMarch 28, 2023

Please leave your feedback about the schedule in the comments by January 10.

Proposed WordPress 6.2 Release Leads

Release LeadRelease Lead The community member ultimately responsible for the Release.: Matt Mullenweg
Release Coordinator: TBD
CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Tech Lead: TBD
Editor Tech Lead:  TBD
Core Triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. Lead: TBD
Editor Triage Lead: TBD
Documentation Lead: TBD
Marketing & Communications Lead: TBD
Test Lead: TBD
Design Lead: TBD

All release decisions will ultimately be this release team’s to make and communicate while gathering input from the community.

Join The Squad!

If you are interested in being a part of 6.2’s release squad, please show interest in the comments below. Roles can be shared among more than one person!


Thanks to @cbringmann for the peer review.

#6-2, #planning

Editor Chat Agenda: 18 January 2023

Facilitator and notetaker: @paaljoachim

This is the agenda for the weekly editor chat scheduled for Wednesday, January 18 2023, 03:00 PM GMT+1. This meeting is held in the #core-editor channel in the Making 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/..

Release of Gutenberg plugin 15.0.0 RC1 available for testing.
A project board for WordPress 6.2 Editor tasks is available.

Key project updates:

Task Coordination.

Open Floor – extended edition.

If you are not able to attend the meeting, you are encouraged to share anything relevant for the discussion:

  • If you have an update for the main site editing projects, please feel free to share as a comment or come prepared for the meeting itself.
  • If you have anything to share for the Task Coordination section, please leave it as a comment on this post.
  • If you have anything to propose for the agenda or other specific items related to those listed above, please leave a comment below.

#agenda, #core-editor, #core-editor-agenda, #meeting

Can you help with topics for the WordPress Developer Blog?

The tenth article has just been published on the WordPress Developer Blog! Check out A walk-through of layout classes in WordPress 6.1 and the other posts available on this new venture.  

The blogblog (versus network, site) has a content board on 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/ and you can add directly to the discussions on topic ideas. You can add new ideas, help to flesh out the topics already suggested, or volunteer to be involved in writing a post. Below is the current list of topics ideas:

Before you get started, check out How to contribute and the Tips and Guidelines for Writers pages on the site. There will be more information on these pages as the blog moves out of 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..

You can ask questions and join discussions async in the #core-dev-blog channel of 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/.

Monthly meetings of the editorial group take place every first Thursday of the month in the Slack channel.

The next meeting will take place on February 2, 2023 at 13:00 UTC.

Props to @bph for co-authoring and reviewing this post.

#core-dev-blog

Help us test the SQLite implementation

A few months ago, a proposal was published to make WordPress officially support SQLite. After the proposal received a lot of positive feedback from the community, we started working on an implementation to make that happen.

Instead of releasing a separate feature pluginFeature Plugin A plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins., it was deemed preferable to implement this as a module in the 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. As of version 1.8.0 of the Performance Lab plugin, the module is now available for testing.

EDIT: After feedback received in this post’s comments, the SQLIte database integration was also released as a separate, stand-alone plugin available on w.org/plugins/sqlite-database-integration.

We would like to urge hosts, plugin authors, and theme developers to test the implementation and help us move forward with this project – with the hope of merging an SQLite implementation in WordPress CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. in a future release.

How to test the SQLite implementation

In order to test using an SQLite database instead of MySQLMySQL MySQL is a relational database management system. A database is a structured collection of data where content, configuration and other options are stored. https://www.mysql.com/. for your WordPress site, you will need to follow the steps below:

Option 1 – If you are using the Performance Lab plugin on your site:

  1. Install and activate the Performance Lab plugin on your site.
  2. Navigate from your dashboard to Settings > Performance.
  3. Enable the SQLite module, and click “Save changes”.
  4. As soon as you save your changes, the plugin will automatically copy the db.php file in your wp-content folder, copy the data for the current user and site title, and also log you in for a more streamlined experience.

Option 2 – Using the stand-alone plugin:

  1. Install and activate the SQLite Database Integration plugin on your site.
  2. Follow the on-screen directions.
  3. As soon as you click the button to install the SQLite database, the plugin will automatically copy the db.php file in your wp-content folder, and you will be redirected to the WordPress-installation screen to set-up your new database.

Important note: When activating SQLite, your site will create an entirely separate and fresh database. We have implemented a basic setup so that you don’t have to go through the installation screens, but nothing else is migrated from the original database beyond that.

Frequently asked questions

Will I lose any data?

No. When you activate the SQLite implementation, a new database is created. Your old database remains unaltered, and when you disable the module, your site gets back to using its previous, unaffected MySQL database.

I had data on my old database, and I don’t see my posts, pages, users, etc, on my SQLite site.

The SQLite implementation does not include a way to migrate data from one database to another. Since this is a proposal for an implementation to be merged in WordPress Core, we need to follow the WordPress Core principles. Data migrationMigration Moving the code, database and media files for a website site from one server to another. Most typically done when changing hosting companies. is not something that Core should do; it is clearly plugin territory. Your data remains safely in your previous database, and you can access it again by disabling the SQLite module.

When SQLite gets merged in Core, migration and backup plugins will add support for it.

Will this work if I have another db.php file in my wp-content folder?

Unfortunately not. If your site already includes a db.php file in the wp-content folder, you will not be able to test SQLite on your site.

You can check if your site already includes a db.php file from another plugin by going from your dashboard to the plugins screen and then navigating to the Drop-in tab.

Keep in mind that this limitation only applies because the implementation is in a plugin, and therefore it needs the drop-in file. Once SQLite is part of Core, this will not be the case.

Historical/Implementation details

The code for the SQLite implementation was copied from https://github.com/aaemnnosttv/wp-sqlite-db/blob/master/src/db.php by Evan Mattson, which is a fork of the original work on the sqlite-integration plugin by Kojima Toshiyasu. It was then refactored, coding standards were applied, and an integration with the Performance Lab plugin was built.

The SQLite code used has been in use for many years and has been battle-tested. We opted to start with a tried solution instead of starting from scratch because many of the problems we would have encountered have already been addressed and solved in the pre-existing implementation.

Where to report issues and feedback

If there are issues that should be addressed, please create a new issue in the plugin’s GitHub repository. When you do, please be sure to mention your SQLite version. You can find it by going from your Dashboard to Tools > Site Health > Info > Database, while the SQLite module is active.

Props @flixos90 and @olliejones for reviewing this post.

WordPress 6.2 Planning Roundup

Following up on the WordPress 6.2 planning proposal and based on the feedback and comments received, this post intends to summarize the release schedule and release squad composition for the next major WordPress release.

WordPress 6.2 Schedule

As a reminder, the WordPress 6.2 release cycle introduces a fourth planned 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. to accommodate WordCampWordCamp WordCamps are casual, locally-organized conferences covering everything related to WordPress. They're one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. Learn more. Asia, providing an extra buffer between the event and two of the biggest release milestones (Beta1 and RC1).

MilestoneDate
Alpha (trunktrunk A directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running "trunk", then you are on the latest revision. open for 6.2 release)October 18, 2022
Beta 1 & Feature FreezeFebruary 7, 2023
Beta 2February 14, 2023
Beta 3February 21, 2023
Beta 4February 28, 2023
Release Candidaterelease 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). 1March 7, 2023
Release Candidate 2March 14, 2023
Release Candidate 3March 21, 2023
Dry RunMarch 27, 2023
WordPress 6.2 General releaseMarch 28, 2023

WordPress 6.2 Release Squad

Thanks to everybody that volunteered for the release squad! Considering all applications for the different roles, a release team has been assembled with project leadership to ensure all areas are properly covered.

Based on the positive feedback received by the proposal of this new role in the call for volunteers for the release squad, this release will trial a new role — Performance Lead. In this first iteration, the Performance Lead will run early performance testing in WordPress trunk and act as an advisor, flagging performance regressions before they are shipped, helping solve them, and providing guidance to the rest of the release squad on performance-related discussions.

Release LeadRelease Lead The community member ultimately responsible for the Release.: Matt Mullenweg
Release Coordinators: Francesca Marano, Héctor Prieto
CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Tech Co-Leads: Tonya Mork, Jb Audras
Editor Tech Co-Leads: George Mamadashvili, Nik Tsekouras
Core Triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. Co-Leads: Colin Stewart, Mukesh Panchal
Editor Triage Co-Leads: Anne McCarthy, Nick Diego
Design Lead: Rich Tabor
Documentation Co-Leads: Birgit Pauli-Haack, Femy Praseet, Milana Cap, Abha Thakor
Marketing & Communications Co-Leads: Jonathan Pantani, Lauren Stein, Mary Baum
Test Co-Leads: Robin, Adel Tahri
Performance Lead: Felix Arntz

All release decisions will ultimately be this release team’s to make. However, contributors are more than welcome to follow along with the release process on the #6-2-release-leads Slack channel.


Props to @cbringmann for peer review.

#6-2, #planning