The WordPress coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. development team builds WordPress! Follow this site for general updates, status reports, and the occasional code debate. There’s lots of ways to contribute:
Found a bugbugA bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority.?Create a ticket in the bug tracker.
Call for Testing post to request folks to test the new Performant TranslationspluginPluginA 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.
@mukesh27 I’ve worked on ticketticketCreated for both bug reports and feature development on the bug tracker.#22192, and I’ve raised PR 5139, which is now ready for review.
@joemcgill The primary opportunities for addressing server timing improvements we identified during the 6.3 cycle were either addressed during that release, or are already in progress in this release milestone. We have a lot in progress right now, so I’m keen to see how we can work together to get a lot of the open tickets wrapped up so we’re not crunched later in the cycle.
I’ve been looking into opportunities to improve template loading/rendering and plan to identify a few tickets to pull in related to that work later this week.
One of the biggest issues that I’ve run into relates to resolving/caching Theme.jsonJSONJSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML. data (related ticket)—which can affect any theme that supports some aspect of theme.json (not just blockBlockBlock is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. themes). We’ve tried working around this issue over the past few releases through various caching strategies, but trying to resolve the underlying issue would likely make the most impact.
JavaScriptJavaScriptJavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser.
https://www.javascript.com & CSSCSSCascading Style Sheets.
@westonruter In continuation of the work on script loading strategies, I picked up #58664 to eliminate manual construction of script tags. This doesn’t strictly relate to performance now, but it does to security.
@westonruter Anyway, I left a comment in #core-js asking for feedback on an approach to migrate existing inline tags (primarily in the adminadmin(and super admin)). The scope of the ticket may need to be pulled back to omit wp-admin. But the big security win with this is to be able to apply Strict CSP to WordPress sites, making persistent XSS much less of a possibility. Feedback on PR and ticket welcome
In agreement with @flixos90 on next steps, which is to port as much as possible form updates.js and use as much DOM structure as possible from existing Plugins > Add UIUIUser interface screen in a bid to make the implementation as simple as possible. I’ll move req and comments over to the correct issue (651)
Open Floor
@spacedmonkey What is the major performance focus of WP 6.4?
@joemcgill I don’t see us having any particular high-level goal for this release, in terms of new features, but more a continuation of working through our roadmap, so all of the things people just mentioned during this meeting
I do think it would be useful to make sure we’re involved earlier in testing out and giving performance feedback to any new functionality being developed in the GutenbergGutenbergThe Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc.
https://wordpress.org/gutenberg/ plugin that is intended to land in 6.4
@spacedmonkey I would like to work on limiting file i/o. There is lots of low hanging fruit there.
@10upsimon curious to know if you have any analysis on this, in terms of where you see opportunity? I’d love to see it (even at a later stage) as this has bene something I’ve simply passed in thought a few times in the years. I’m also curious of things like the effects said savings will have in different FS type environments (if at all) etc. Will keep eye’s open on this topic.
@spacedmonkey If you look at xhprof, there are the most expensive functions. glob, realpath, file_exists and file_get_contents are all file I/O
@joemcgill One of the conflicting questions that is still unresolved here is whether individual calls to those functions have a consistent performance impact over time, or if PHPs internal caching of these function end up making them less expensive than it seems when doing an individual profile run. Some testing about that would be instructive
@spacedmonkey I have performance data on – https://core.trac.wordpress.org/ticket/59279 I understand there are caches, so calling the same file i/o twice isnt that bad, I am trying to avoid completely unnessarly calls all together.
@joemcgill Agreed. That’s been a big part of what I’ve been looking into for loading templates as well.
@10upsimon I’d be curious to know which of these have caching (natively) as I was under the impression most IO functions did not, so even if the function itself got cached, there is still the physical i/o process. So an unnecessary i/o process seems to indeed be a good starting point here
Here is the agenda for this week’s performance team meeting scheduled for Sep 5, 2023 at 15:00 UTC. If you have any topics you’d like to add to this agenda, please add them in the comments below.
Call for Testing post to request folks to test the new Performant TranslationspluginPluginA 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.
The coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. performance team recently conducted an in-depth i18n performance analysis. It showed that localized WordPress sites load significantly slower than a site without translations. The blogblog(versus network, site) post presented and compared multiple solutions to this problem, and now the team would like to test the most promising approach at a wider scale using a dedicated pluginPluginA plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party..
Introducing the Performant Translations plugin
What it does
The Performant Translations plugin uses a new approach to handle translationtranslationThe process (or result) of changing text, words, and display formatting to support another language. Also see localization, internationalization. files in WordPress, making localization blazing fast. The primary purpose of this plugin is to allow broader testing of these enhancements, for which the goal is to eventually land in WordPress core.
This plugin helps to make localized WordPress sites faster by replacing the traditional MO translation files with PHPPHPThe web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher files, which are much faster to parse. Plus, PHP files can be stored in the so-called OPcache, which provides an additional speed boost.
If your site is using a language other than English (US), you should see immediate speed improvements simply by activating this plugin. No further action is required.
The Performant Translations plugin is available for download on WordPress.orgWordPress.orgThe community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ or directly from your WordPress adminadmin(and super admin).
Since the Performant Translations plugin requires no configuration, all that’s needed to benefit from its speed improvements is to activate the plugin.
To verify that something has changed, you could use a tool like Query Monitor or an external tool for testing server response times. In Query Monitor, the page load time and memory usage should drop quite a bit after plugin activation:
Page load time and memory usage beforePage load time and memory usage after
In Query Monitor you will also see how translations are loaded from PHP files from now on:
While the plugin is mostly considered to be a betaBetaA pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. testing plugin, it has been tested and established to a degree where it should be okay to use in production. Still, as with every plugin, you are doing so at your own risk.
It’s also worth noting that the plugin has been successfully tested with common multilingual plugins, such as WPML, Weglot, TranslatePress, MultilingualPress, and Polylang. It also works fine with Loco Translate and the Preferred Languagesfeature pluginFeature PluginA plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins.
Should you choose to stop testing the Performant Translation plugins, uninstalling it will remove all of its traces.
The performance team’s goal is to get as much feedback as possible and further refine the approach so that it can ultimately be proposed to be merged into WordPress core 6.5. That means testing will last for a few months at least.
This proposal comes out of an ad-hoc session at the WordPress Community Summit. This session grew out of discussions during the session on backward compatibility in GutenbergGutenbergThe Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc.
https://wordpress.org/gutenberg/ where it was noticed that some WordPress changes are easily missed by the extendors of WordPress and WordPress site builders.
Background
The Field Guides in WordPress started in 3.4 and have been consistently published since WordPress 4.1. In this time, they have grown in length due to an increase in both the number of dev notesdev noteEach important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include a description of the change, the decision that led to this change, and a description of how developers are supposed to work with that change. Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase. and the number of changes in each version.
Longer posts can be more difficult to read to completion and this can cause important information to be missed. Additionally, as much of the information is linked to rather than included in the post it takes effort to truly understand the breadth of changes in a WordPress release. All of the information that is published is valuable to the WordPress community, so discouraging the publishing of content would be antithetical to the goal of informing and helping the WordPress community and is not something that is desired.
Proposal
The first part of this proposal is to continue publishing the existing Field GuideField guideThe field guide is a type of blogpost published on Make/Core during the release candidate phase of the WordPress release cycle. The field guide generally lists all the dev notes published during the beta cycle. This guide is linked in the about page of the corresponding version of WordPress, in the release post and in the HelpHub version page. on this site (make/coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress.) but adjust the target for publishing it to the final scheduled betaBetaA pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process.. Currently, the target is to publish the Field Guide at the same time as RC1. This doesn’t change the amount of work for the release team, but it does move the target up by approximately one week. Publishing this earlier will give some additional time to update documentation, encourage testing from the community, and also allow for time to prepare for part two of this proposal.
The second part is to start publishing a simplified Field Guide to the WordPress Developer Blog. The audience for this guide is primarily two groups: Extenders of WordPress such as pluginPluginA plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party. and theme authors and Developers building custom sites. This simplified guide will focus on the following things:
Large features that developers would want to tie into
Changes with a high potential of causing breakage
Features the core team wants developers to start using right away as the use of them will benefit WordPress end users.
As an example, a hyper-focused Field Guide for WordPress 6.3 could have highlighted the new command palate (a large feature that developers would want to tie into), Async/Defer in the script loader (a new feature that when developers start using, WordPress end users will benefit), and the post editor being iframed (a change with a higher potential of causing breakage).
The target length of this Field Guide should be 800-1000 words and it should link to but not embed any other documentation such as dev notes. The target will be to publish this post within one week of RC1. The same process for all content published on the developer blogblog(versus network, site) will be followed and the release documentation lead(s) or their designee will be expected to work with the WordPress Developer Blog team in the #core-dev-blog channel and the developer blog content GitHub repository to coordinate the content and publish date.
Provide feedback by 15 September 2023
This proposal is one step, but not necessarily the only step, at improving communication around WordPress releases and making it easier for WordPress updates to instill confidence. Feedback will be accepted until 15 September 2023
This meeting is aimed at the work around the next default theme Twenty Twenty-Four, which will be released with WordPress 6.4 in November. Please keep the topic on the theme!
We set the meeting time to Wednesday, 3pm UTC. In the agenda, the meeting time will be noted with the automatic timezone conversion. The meetings happen weekly and may be switched to bi-weekly if we’re closer to the release.
The work on TT4 will happen in this GithubGitHubGitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged by the repository owner. https://github.com/ repository: https://github.com/WordPress/twentytwentyfour
Please read through the readme file carefully, as it contains important information on how to get started.
If you want to contribute, check out the open issues and Pull Requests first, to see if your topic has been addressed already. If not, feel free to open an issue!
It would be fantastic if you can link a created PR to an issue, so it’s easier to keep track of things.
Open Floor
@maneshtimilsina mentioned contributers get confused about using esc_html__ or esc_html_x_ functions in patterns for translations.
Resource to translation documentation: https://developer.wordpress.org/apis/internationalization/internationalization-functions/
Resource to esc_html__ documentation: https://developer.wordpress.org/reference/functions/esc_html__/
Resource to esc_html_x documentation: https://developer.wordpress.org/reference/functions/esc_html_x/
Discussion summary:
Patterns should be checked if they use the correct functions
Any sample text should be commented that this is sample text, using the esc_html_x function
Any strings that may need further explanation to be correctly translated also need comments
Check on previous default themes for similar strings to see how it was handled there
@maneshtimilsina mentioned that there’s confusion about the home.php file, which contains multiple patterns
The patterns should be extracted into smaller components, which then possibly make home.php not needed anymore.
@kafleg mentioned the backlog of open PRs regarding patterns in the repository.
These will be taken care of this week.
@poena asked about the status of pattern categories and pattern switching for 6.4, and if this will work with non synced patterns
It seems this has not yet been discussed, an issue needs to be created to start a discussion around this topic
GutenbergGutenbergThe Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc.
https://wordpress.org/gutenberg/ 16.6.0 RC1 will be released during the next hours.
It’s a hard to maintain PR due to the large number of modified files so faster reviews would be useful. The PR will add a new CSSCSSCascading Style Sheets. class to all rendered paragraphs.
Do not be scared about the many changes the essence of the PR is detailed here.
it appears the best way to redo this is a code exploration that would add a blockBlockBlock is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. attribute to skip the current post when the post is set to not inherit.
Reminder: WordPress 6.3 developer notes. The Field GuideField guideThe field guide is a type of blogpost published on Make/Core during the release candidate phase of the WordPress release cycle. The field guide generally lists all the dev notes published during the beta cycle. This guide is linked in the about page of the corresponding version of WordPress, in the release post and in the HelpHub version page. has had 6,500 views since it was published on July 18!S
Roadmap to 6.4 – this next major releasemajor releaseA release, identified by the first two numbers (3.6), which is the focus of a full release cycle and feature development. WordPress uses decimaling count for major release versions, so 2.8, 2.9, 3.0, and 3.1 are sequential and comparable in scope. is scheduled for November 7, 2023.
6.4 Editor Taskboard on GitHubGitHubGitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged by the repository owner. https://github.com/
Tickets or Components help requests
Please add any items for this part of the agenda to the comments. If you can not attend dev chat live, don’t worry, include a note and the facilitator can highlight a ticketticketCreated for both bug reports and feature development on the bug tracker. if needed.
Open floor
If you have any additional items to add to the agenda, please respond in the comments below to help the facilitator highlight them during the meeting.
You must be logged in to post a comment.