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.
Welcome back to a new issue of Week in CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress.. Let’s take a look at what changed on TracTracAn open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. between August 21 and September 4, 2023.
75 commits
150 contributors (!)
25 new contributors (!)
129 tickets created
13 tickets reopened
117 tickets closed
TicketticketCreated 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
Escape post type output as field attribute – #59190
Build/Test Tools
Avoid doing copy:dynamic when running grunt watch when using --dev option – #59196
Change the version of Node.js in the Codespaces container – #56658
Compare results in performance measurement workflow – #58358, #58359
Enable running the tests on PHPPHPThe web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher 8.3 – #59231
Ensure database containers are prepared for commands – #30462, #58867
Expand database testing to account for all supported versions and types – #30462
Implicitly pass secrets to the called workflow – #30462
Twenty Nineteen: Improve social media icon dimension attributes – #45950
Ensure that pull quotes are able to use the correct font size – #57854
Coding Standards
Remove unused global variables in various /wp-admin/includes/ files – #59254
Use strict comparison in wp-includes/class-wp-hook.php – #58831
Use strict comparison in wp-includes/class-wp-widget.php – #58831
Use strict comparison in wp-includes/ms-files.php – #58831
Use strict comparison in wp-includes/ms-site.php – #58831
CustomizerCustomizerTool built into WordPress core that hooks into most modern themes. You can use it to preview and modify many of your site’s appearance settings.
use the correct X-Robots-TagheaderHeaderThe header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes. – #58865
Database
Improve the documentation for various methods in the wpdb class – #58833
Add missing param description in WP_Comment class – #58890
Clarify post_date_column_timefilterFilterFilters 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. description – #59029
Correct default post type in page_template_dropdown()docblockdocblock(phpdoc, xref, inline docs) – #58972
Docblock improvements in _deprecated_class() function, as per docblocks standards – #58833
Fix typo in a translator comment in _deprecated_class() – #58833
Add relative time strings for the wp-date inline script output – #59219, #47373
Don’t use fluid layout value in typography – #58754
Ensure main query loopLoopThe Loop is PHP code used by WordPress to display posts. Using The Loop, WordPress processes each post to be displayed on the current page, and formats it according to how it matches specified criteria within The Loop tags. Any HTML or PHP code in the Loop will be processed on each post. https://codex.wordpress.org/The_Loop. is entered for singular content in 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 – #58154
Optimize wp_get_block_css_selector to remove array_merge calls for better performance – #59178
Preserve block style variations when securing theme – #59108
Introduce font-face styles generator and printer – #59165
Replace two esc_url_raw() calls in core with sanitize_url() – #59247
Use regular core button styles for page header actions – #41986
HTMLHTMLHyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers.APIAPIAn API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways.
Stop processing HTML when encountering unsupported markup – #59167
Update WP_Http class to avoid PHP deprecation warnings – #58876
Help/About
Match icon and text in Help for bulk edit button – #58785
Login and Registration
Improve test coverage for sign on related functions – #36476
Media
Add a filter to the get_available_post_mime_types() function to allow overriding its database query – #52759
Prevent warning if shortcodeShortcodeA shortcode is a placeholder used within a WordPress post, page, or widget to insert a form or function generated by a plugin in a specific location on your site. is used without attributes – #59206
Remove unused $is_IE and $is_opera globals in media_upload_form() – #59254
Menus
Fix proximity of controls to Save and Delete menus – #56594
Options, MetaMetaMeta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. APIs
Introduce prime_options() to load multiple options with a single database request – #58962
Reinstate missing sort_column options in get_pages() – #59226
Remove redundant function calls in get_body_class() – #43661
REST APIREST APIThe REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/rest-api/.
Remove misleading comment in WP_REST_Blocks_Controller->get_item_schema – #59193
RevisionsRevisionsThe WordPress revisions system stores a record of each saved draft or published update. The revision system allows you to see what changes were made in each revision by dragging a slider (or using the Next/Previous buttons). The display indicates what has changed in each revision.
Add missing escaping function for $post_edit_link in wp-admin/revision.php – #59141
Rewrite Rules
Prevent stampedes when flush_rewrite_rules() is called – #58998
Site Health
Show correct debug value for file uploads – #58737
fix check name used for REST API permission checks – #59236
Upgrade/Install
Add missing escaping function for get_option( 'home' ) in upgrade.php – #59199
Remove unused globals in core_upgrade_preamble() – #59254
Upload
Add a MIME type exception for .docx generated by Google Docs – #57898
Correct duplicate MIME type for .xlsx files generated by Google Docs – #57898
Users
Call add_user_meta() instead of update_user_meta() when adding metadata to a new user – #59212
Properly deprecate both constructors in WP_User_Search – #41125
Remove unused wpdb global in check_password_reset_key() – #59185
Widgets
Improve performance of has_content method in WP_Widget_Media_Gallery class – #58757
XML-RPC
Remove unused wpdb global in wp_xmlrpc_server::mw_newMediaObject() – #59185
Props
Thanks to the 150 (!) people who contributed to WordPress Core on Trac last week:
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 5.6.20 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.
Welcome back to a new issue of Week in CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress.. Let’s take a look at what changed on TracTracAn open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. between August 14 and August 21, 2023.
27 commits
34 contributors
64 tickets created
6 tickets reopened
50 tickets closed
TicketticketCreated 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
Add function to standardize adminadmin(and super admin) notices – #57791
Apply admin notice functions in multisitemultisiteUsed to describe a WordPress installation with a network of multiple blogs, grouped by sites. This installation type has shared users tables, and creates separate database tables for each blog (wp_posts becomes wp_0_posts). See also network, blog, site – #57791
InvalidinvalidA resolution on the bug tracker (and generally common in software development, sometimes also notabug) that indicates the ticket is not a bug, is a support request, or is generally invalid. argument passed in additional_classes – #57791
Send a failure notice in Slack when a run fails to start – #58867
Simplify the required prerequisite jobs for the failed-workflow job – #58867
Update PHPUnit Polyfills to version 1.1.0 – #59150
Use the correct variable for checking the previous conclusion – #58867
Coding Standards
Improve variable names in wp_save_image() – #58831
Use strict comparison in wp-admin/includes/image-edit.php – #58831
Use strict comparison in wp-admin/includes/meta-boxes.php – #58831
Docs
Add missing @ to the return tagtagA directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.) in the wp_get_theme_data_template_parts function – #59003
Correct punctuation in some instances of the $crop parameter description – #58833
Fix typo in duplicate hook references for views_{$this->screen->id} – #59102, #58833
Miscellaneous docblockdocblock(phpdoc, xref, inline docs) corrections and improvements – #58833
Editor
Ensure defer loading strategy is only applied to 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.’s viewScript – #59115
Fix error handling of converting classic to block menus – #58823
Use defer loading strategy for block view scripts – #59115
update npm packages with critical 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. fixes for 6.3.1 – #59151
General
Revert the last use of str_starts_with() in update-core.php – #59145
Media
Standardise documentation of the $crop parameter for various media functions and methods – #58833
Posts, Post Types
Remove redundant function calls in get_body_class() – #43661
REST APIREST APIThe REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/rest-api/.
Correct the docblocks for various permission related methods – #58833
Site Health
Correct the check for disk space available to safely perform updates – #59116
Themes
Add wp_get_theme_data_custom_templates function – #59137
Props
Thanks to the 50 people who contributed to WordPress Core on Trac last week:
The dev blogblog(versus network, site) is going to use the Learn WordPress organization repository 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 be the repository owner. https://github.com/ to host code samples, gists and the like. That will save writers and editors from having to use their personal GH accounts. @greenshady has volunteered to be the first to use it, and the board will develop some processes and guidelines from his experience. If you have thoughts on anything surrounding these repositories, please share on this GitHub issue.
The Marketing team as of August 2, the Marketing team is sharing Developer Blog posts on the official WordPress social profiles.That means a post author has one more step on the post-publish checklist—write some copy for the social-media post and add it to the issue for the post.
And A tutorial about the highlights of the browser and focus modes of the Navigation was on hold pending the publication of the 6.3 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..
The group needs some ways to approve topics outside the monthly meetings. As it stands, potential authors are having to wait more than a month for a green light. See the discussion.
Following sessions are dedicated to move things forward and be ready in time according to 6.4 Release Schedule.
Everyone is welcome to join not only to triagetriageThe act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. tickets but also to look for tickets you can contribute by creating patches, making code review and testing. Keep in mind that all features and enhancements should be in the TrunktrunkA 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. before BetaBetaA pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. 1 and most bugs and all strings need to be there before RC1. If you are working on a patchpatchA 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., plan your contribution to have enough time for other contributors to make suggestions, review and test.
Monday September 25, 2023 at 19:00 UTC for a last scrub before BetaBetaA pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. 1
Monday October 16, 2023 at 17:00 UTC for a last scrub before RCrelease candidateOne 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
Release Candidaterelease candidateOne 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 RC.
TBD
Check this schedule often, as it will change to reflect the latest information.
Regular component scrubs and triage sessions
For your reference, here are some of the recurring sessions:
Have a regular component scrub or triage session? PingPingThe act of sending a very small amount of data to an end point. Ping is used in computer science to illicit a response from a target server to test it’s connection. Ping is also a term used by Slack users to @ someone or send them a direct message (DM). Users might say something along the lines of “Ping me when the meeting starts.”@audrasjb, @oglekler or @marybaum on SlackSlackSlack 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.
You can start your own triage sessions
Decide what you want to work on
6.4 triage session are our priority and moving forward tickets which already are scheduled for the release is most needed task. If you want to lead some of them, they can be added on this schedule.
But if you are interested in particular component or user focus, for example to take care about RTL-tickets, this will be most welcome too.
Especially interested can be the session to scrub old tickets. We are continuously closing new tickets with the same topic in favor of existing ones and because these tickets are looking complicated just because they’re age not, so many contributors are eager to work on them, but there are actual treasures hidden among very difficult or tricky topics.
Ping@oglekler or @marybaum on Slack with the day and time you’re considering as well as the report or tickets you want to scrub.
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.4 tickets ordered by workflow.
Need a refresher on 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. scrubs? Checkout Leading Bug Scrubs in the coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. handbook.
Welcome back to a new issue of Week in CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress.. Let’s take a look at what changed on TracTracAn open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. between July 31 and August 14, 2023.
40 commits
50 contributors
164 tickets created
15 tickets reopened
138 tickets closed
TicketticketCreated 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
Build/Test Tools
Bump the required versions of Node.js and npm – #56658
Correct two @covers annotations to use the recommended pattern – #59069
Update 3rd-party 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 be the repository owner. https://github.com/ Actions – #58867
Update all build tool related dependencies – #58863
Update the README file to reflect new Node.js/npm versions – #59071, #56658
Fix leakage in WP_List_Table tests – #58955, #58896
Code Modernization
Deprecate dynamic properties in WP_List_Table magic methods – #58896, #56034
Deprecate dynamic properties in WP_Text_Diff_Renderer_Table magic methods – #58898, #56034
Deprecate dynamic properties in WP_User_Query magic methods – #58897, #56034
Use “declare” in WP_List_Table magic methods deprecation message – #58896
Coding Standards
Bring more consistency to Last-Modified and ETag checks – #58831
Rewrite loose comparison in wp_list_categories() – #58831
Use instanceof keyword instead of the is_a() function – #58943
Use strict comparison in wp-admin/includes/class-wp-importer.php – #58831
Use strict comparison in wp-includes/class-wp-image-editor.php – #58831
Use strict comparison in wp-includes/class-wp.php – #58831
Use strict comparison in wp-includes/cron.php – #58831
Use strict comparison in wp-includes/kses.php – #58831
Use strict comparison in wp-includes/revision.php – #58831
Docs
Correct duplicate hook reference for wp_min_priority_img_pixels – #59067
Remove @see references for SimplePie classes – #59030
Editor
Only exclude auto-generated 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. files from coding standards checks – #50010
Simplify usage of block_has_support() function by supporting a string – #58532
Embeds
Modernize wp-embed script with removal of obsolete IE10/IE11 code and support for WP 4.4 and below – #58974
Emoji
Suppress console errors from sessionStorage usage in sandboxed post embed iframeiframeiFrame is an acronym for an inline frame. An iFrame is used inside a webpage to load another HTML document and render it. This HTML document may also contain JavaScript and/or CSS which is loaded at the time when iframe tag is parsed by the user’s browser. – #58978, #58472
HTMLHTMLHyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers.APIAPIAn API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways.
Adjust code styling to 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/’s linter’s preferences – #58918
Simplify logic in wp_get_loading_optimization_attributes() – #58891
Options, MetaMetaMeta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. APIs
Use defer loading strategy for wp-embed script and move to head (in block themes) – #58931
Site Health
Use PHP_SAPI constant instead of the php_sapi_name() function – #58942
Themes
Avoid unnecessary check whether parent template file exists when not using a child themeChild themeA Child Theme is a customized theme based upon a Parent Theme. It’s considered best practice to create a child theme if you want to modify the CSS of your theme. https://developer.wordpress.org/themes/advanced-topics/child-themes/. – #58576
add wp_get_theme_data_template_parts function – #59003
Preparation for WordPress 6.3 final release is underway. This post shares the release process, including the timeline and how you can help. The post will be kept up to date as the release process evolves.
The Dry Run is a key event as a final walk-through for the final release. As noted above, the current plan is to start it on 2023-08-07 16:00. You are invited to observe and/or participate. It’ll happen in the #core Slack channel.
What happens during the dry run?
Review 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. reports to determine if any are critical to warrant another RCrelease candidateOne 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). (release candidaterelease candidateOne 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).).
Checks and any necessary updates are made in the src/wp-admin/includes/update-core.php file.
Pre-release scripts are run to ensure test suites, coding standards, and other automated checks pass.
If the results are acceptable, the release goes into a 24-hour code freeze period.
24-Hour Code Freeze ✅
After the dry run and before the release party starts, a mandatory 24-hour code freeze goes into effect.
What does this mean? No source code for 6.3.0 (i.e., in the 6.3 branchbranchA directory in Subversion. WordPress uses branches to store the latest development code for each major release (3.9, 4.0, etc.). Branches are then updated with code for any minor releases of that branch. Sometimes, a major version of WordPress and its minor versions are collectively referred to as a "branch", such as "the 4.0 branch".) can be changed during these 24 hours.
What happens if a critical bug is reported during this period? The release squad will meet with committers and maintainers to determine if the issue is a blockerblockerA bug which is so severe that it blocks a release..
If yes, another RC release happens, and the release process restarts (meaning the dry run is repeated, and then the 24-hour code freeze clock restarts).
The release party on August 8th will start no sooner than 24h after the code freeze starts, with the exact time to be determined accordingly. You are invited to observe and/or participate. It’ll happen in the #core Slack channel.
The release party walks through the steps in the Major Version Release process for anyone who wants to follow along.
Please note releasing a major version requires more time than releasing 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. or release candidate. There are more steps in the process. If any last-minute issues need addressing, more time will be needed.
How You Can Help
A key part of the release process is checking that the ZIP packages work on all the available server configurations. If you have some of the less commonly used servers available for testing (IIS, in particular), that would be super helpful. Servers running older versions of PHPPHPThe web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher and MySQLMySQLMySQL 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/. will also need testing.
You can start this early by running the WordPress 6.3 RC3 packages, which are built using the same method as the final packages.
During the release party, options will be provided on how to help test the release package.
Tips on What to Test
In particular, testing the following types of installs and updates would be much appreciated:
Does a new WordPress install work correctly? This includes running through the manual install process, as well as WP-CLIWP-CLIWP-CLI is the Command Line Interface for WordPress, used to do administrative and development tasks in a programmatic way. The project page is http://wp-cli.org/https://make.wordpress.org/cli/ or one-click installers.
Test upgrading from 4.0.38, 4.9.22, 5.8.6, 5.9.5, 6.0.3, 6.1.3, 6.2.2, and 6.3 RC3, as well as any other versions possible.
Remove the wp-config.php file and test a fresh install.
Test single site and multisitemultisiteUsed to describe a WordPress installation with a network of multiple blogs, grouped by sites. This installation type has shared users tables, and creates separate database tables for each blog (wp_posts becomes wp_0_posts). See also network, blog, site/networknetwork(versus site, blog) (both subdirectory and subdomain) installations.
Testing the following user flows on both desktop and mobile would be great to validate each function as expected:
Publish a post, including a variety of different blocks.
Comment on the post.
Install a new 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/theme, or upgrade an existing one.
Change the site language.
If you’re a plugin developer, or if there are complex plugins you depend upon, test that they’re working correctly.
Welcome back to a new issue of Week in CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress.. Let’s take a look at what changed on TracTracAn open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. between July 24 and July 31, 2023.
21 commits
40 contributors
64 tickets created
12 tickets reopened
39 tickets closed
TicketticketCreated 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.
Twenty Twenty-One: Enable Dark Mode in the blockBlockBlock is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. editor iframeiframeiFrame is an acronym for an inline frame. An iFrame is used inside a webpage to load another HTML document and render it. This HTML document may also contain JavaScript and/or CSS which is loaded at the time when iframe tag is parsed by the user’s browser. – #58835
Editor
Fix abbreviations of “Example” in block-template-utils.php – #58879
Fix conditionals in Template Editing Mode – #58889
second update of npm packages for 6.3 RC3 – #58926
update npm packages with 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. fixes for 6.3 RC2 – #58804
Help/About
Add illustrations to the Get Involved tab – #23348
Escape “Contribute” links, for better consistency – #23348
Fix the Get Involved tab on Networknetwork(versus site, blog)Adminadmin(and super admin) – #23348
Welcome back to a new issue of Week in CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress.. Let’s take a look at what changed on TracTracAn open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. between July 17 and July 24, 2023.
44 commits
83 contributors
83 tickets created
13 tickets reopened
56 tickets closed
TicketticketCreated 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
Add a missing closing spantagtagA 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 column sorting indicators – #32170, #57839
Remove outmoded jsvalidate task from Gruntfile – #58645, #26615
Bundled Themes
Twenty Twenty-One: Enable Dark Mode in the blockBlockBlock is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. editor iframeiframeiFrame is an acronym for an inline frame. An iFrame is used inside a webpage to load another HTML document and render it. This HTML document may also contain JavaScript and/or CSS which is loaded at the time when iframe tag is parsed by the user’s browser. – #58835
Twenty Twenty-Three: Remove the perPage attribute where the query inherits from the global query. The global attribute should be used instead – #58581
Add test for context setting in Comment Template block – #58839
Fix a PHPPHPThe web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher notice appearing when adding a new template part – #57851
Fix abbreviations of “Example” in block-template-utils.php – #58879
Fix 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. where it was not possible to style custom block elements in theme.json – #57868
update npm packages with bug fixes for 6.3 RC2 – #58804
External Libraries
Update deprecated jQuery code in Farbtastic lib – #57946
General
Commit changes after running precommit:css – #57856, #58869
Rename wp_in_development_mode() to wp_is_development_mode() – #57487
HTMLHTMLHyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers.APIAPIAn API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways.
I18Ni18nInternationalization, or the act of writing and preparing code to be fully translatable into other languages. Also see localization. Often written with a lowercase i so it is not confused with a lowercase L or the numeral 1. Often an acquired skill.
Add missing translator comment in WP_Upgrader::generic_strings() – #58831
Media
Adjust PDF upload handling to remove non-opaque alpha channels from previews – #39216
Fix Image rotation button overflow in translations – #58877
Stop using and deprecate set_imagick_time_limit(). Seems it causes more problems than it solves – #58202
REST APIREST APIThe REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/rest-api/.
Update Global styles revisionsRevisionsThe WordPress revisions system stores a record of each saved draft or published update. The revision system allows you to see what changes were made in each revision by dragging a slider (or using the Next/Previous buttons). The display indicates what has changed in each revision. private methods to protected – #58846
Script Loader
Improve test coverage for wp_print_scripts() – #58648
Upgrade/Install
Add correct parameters to add_option in upgrade_630 – #58821
Props
Thanks to the 83 (!) people who contributed to WordPress Core on Trac last week:
A recent in-depth performance analysis of WordPress core showed that loading translations had a significant hit on a site’s server response time. Given that more than half of all WordPress sites use a language other than English (US), the performance team identified this as an area worth looking into more closely. The team spent the last couple of months exploring this in more detail and the results are now shared in this blogblog(versus network, site) post.
This is merely an analysis of the current i18ni18nInternationalization, or the act of writing and preparing code to be fully translatable into other languages. Also see localization. Often written with a lowercase i so it is not confused with a lowercase L or the numeral 1. Often an acquired skill. system in WordPress with some proposed under-the-hood performance improvements. No decisions have been made on any of these proposals.
Context
Initial benchmarks showed that the median loading time for a localized site can be up to 50% slower than for non-localized sites, depending on which themes and plugins are being used. This was measured using both the wpp-research CLI tool and also a dedicated benchmark environment (as elaborated in the Comparison section towards the end).
The WordPress i18n system is based on gettext, which uses source .po (Portable Object) files and binary .mo (Machine Object) files for storing and loading translations. It is not using the C gettext APIAPIAn API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. itself but a custom userland implementation that works without any external dependencies.
In addition to coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. itself, each 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 has its own translationtranslationThe process (or result) of changing text, words, and display formatting to support another language. Also see localization, internationalization. file, which has to be loaded and parsed on every request. Loading and parsing all these translation files is an expensive task.
In the past, various solutions have been discussed and explored to improve the i18n performance of WordPress. A non-exhaustive list:
Use a more lightweight MO parser
Improve translation lookups by using the hash map in MO files (e.g. with DynaMo)
Caching translations in the object cache
Caching translations in APCu (an in-memory key-value store for PHPPHPThe web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher)
Other more elaborated forms of caching (e.g. per request)
Using the native PHP gettext extension
Use a custom PHP extension to handle the MO file parsing)
Using lazily evaluated translation calls (see #41305 for details)
Using a different file format than .mo files, e.g. plain .php files
For this analysis, many of these solutions were looked at, focusing on their advantages and disadvantages. At the end of this post there is a comparison table with some much needed numbers as well, based on custom-built benchmarks.
Solutions
Solution A: Use different file format
Use a different file format for translations instead of .mo files to avoid the overhead of loading and parsing binary files.
Design considerations
With this solution, translations will be stored in plain .php files returning an associative array of translation strings. Whenever a .php file is available, it will be preferred over the .mo file, which is still used as a fallback. The rest of the architecture remains the same.
When a localized WordPress site downloads language packs from the translate.wordpress.org translation platform, it downloads .po and .mo files containing all the translations. This will be modified to include .php files. GlotPress, which the platform is built on, will be updated to support this new output format. Additionally, WordPress core itself could be modified to generate PHP files whenever they are missing.
In theory, nothing is faster in PHP than loading and executing another PHP file. .json, .ini, or .xml would all be much slower.
Initial benchmarks show consistent significant performance improvements
Relatively trivial to implement
Maintains backward compatibility thanks to graceful fallback
Makes it easier for users to inspect and change translations (no need to compile .po to .mo)
Avoids loading and parsing binary .mo files, which is the main bottleneck
Lets PHP store translations in OPcache for an additional performance benefit
Battle-tested approach in the PHP ecosystem (for example in Laravel)
Caveats and risks
Requires not only changes to WordPress core, but also tools like GlotPress and WP-CLIWP-CLIWP-CLI is the Command Line Interface for WordPress, used to do administrative and development tasks in a programmatic way. The project page is http://wp-cli.org/https://make.wordpress.org/cli/
Adds maintenance overhead by introducing a new file format on top of the existing one
As shown by the proof of concept, the overhead is minimal
In the long term, .mo support could be deprecated
Security considerations due to essentially executing remotely fetched PHP files
Not really different from downloading plugins/themes from WordPress.org
WordPress considers translations to be trusted
Hosting providers could be blocking PHP execution in wp-content/languages
Could potentially use checksum verifications or static analysis at install time to detect anomalies
Effort and timeline
The proof of concept using PHP files is in a very solid state already. There are also examples for changes to WP-CLI (PR) and GlotPress (PR). This makes it suitable for a feature project to expand testing with very little effort required. Even a core merge would be very straightforward in a relatively short time, potentially already in Q4 2023. The security aspect when using PHP files could be a potential blockerblockerA bug which is so severe that it blocks a release., so it’s important to loopLoopThe Loop is PHP code used by WordPress to display posts. Using The Loop, WordPress processes each post to be displayed on the current page, and formats it according to how it matches specified criteria within The Loop tags. Any HTML or PHP code in the Loop will be processed on each post. https://codex.wordpress.org/The_Loop. in the WordPress security team and hosting providers early on.
More time is required to test other file formats and compare results.
Solution B: Native gettext extension
Use the native gettext PHP extension written in C when available, instead of the custom built-in parser in WordPress.
Design considerations
WordPress has always used a custom MO file parser, because the native gettext extension is not necessarily available on the server. With this solution, the existing system is adapted to use the extension whenever available and falling back to the custom implementation if not.
This has been previously explored in #17268 and implemented in WP Performance Pack and Native Gettext. These implementations can serve as inspiration for the initial design. They all work similarly in that they symlink or copy the translation files to a new directory structure that is compatible with the gettext extension.
As of July 2023, around 66% of all localized WordPress sites have the gettext extension installed, according to information from the WordPress update requests.
Benefits
Significant performance improvements for eligible sites
Initial benchmarks show that loading time and memory usage basically do not differ from non-localized sites
Caveats and risks
The gettext extension is not commonly available
Smaller incentive to implement and lower impact overall
Requires locales to be installed on the server
Servers rarely have many installed locales
Locales often need to be compiled first and take up a lot of space
WordPress on the other hand supports over 200 locales
Potential clashes with the custom locales WordPress supports
For example, locales like pt_PT_ao90, de_DE_formal or roh might not even be supported
Outreach to hosting providers would be necessary
Adds maintenance overhead by essentially adding a second gettext implementation
Poor API
Requires setting environment variables (such as LC_MESSAGES and LANGUAGE), which might not be possible or cause conflicts on certain servers/sites
Requires symlinks or hard file copies
Symlinks might not be possible on the server; copying all translation files means doubling disk usage
Translation files are cached by PHP, thus any translation change requires restarting the web server
There are workarounds such as cache busting using random file names or fstat, however they might not work on all environments
Has not been tested on a wider scale, despite being discussed for years
While there are existing implementations that could be leveraged for this solution, further field testing is required to assess whether the extension actually works under all circumstances. Given the limitations around the poor API and requirements for installing locales, it does not seem like a viable solution at all.
Solution C: Cache translations
Cache translations somehow to avoid expensive .mo parsing.
Design considerations
Cache translations either on disk, in the database, or the object cache to avoid expensive .mo file parsing on subsequent requests. This can be done in a generalized manner or also on a per-request basis to only load translations required for the current URLURLA specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org.
Many different caching strategies have been explored in various forms in the past, each with their own pros and cons. Some could even be combined. Defining the exact implementation requires further exploration and testing, which warrants its own exploration post.
Benefits
Caching translations after one time .mo parsing potentially improves performance for future requests
Caveats and risks
Caching using persistent object cache (e.g. Memcached, Redis) or APCu:
Not available on most sites, making this not an ideal solution
Availability according to data from WordPress update requests:
Memcached: ~25%
Redis: ~25%
APCu: ~6%
Can potentially significantly increase cache size or exceed cache key limits
Database caching:
Moves the problem from disk reads to database reads
Can potentially significantly increase database size
Alternatively, use sqlite as a cache backend
Untested approach
Available on around 90% of sites
Disk caching:
Not always possible, depending on server environment
Still causes file reads, only with fewer or other files
Multiple cache groups (e.g. per-request or frontend/adminadmin(and super admin) split)
Smarter cache logic to only load translations that are needed for the majority of requests
Can potentially significantly increase cache size
Unlikely that different requests use very different translations
Cache retrieval adds overhead
Exact performance gains depend on implementation method and need to be measured first
No performance gains with cold cache
Cache invalidation logic TBD
Effort and timeline
Given the existing solutions in the ecosystem, the engineering effort itself would not be too big, but the right caching implementation (e.g. disk cache or object cache) needs to be evaluated first.
However, the right caching strategy probably does not exist because of all the different hosting environments. Since it’s unrealistic for core to support multiple types of caching, this solution seems better suited for plugins rather than core.
Solution D: Lazily evaluated translation calls
Use lazily evaluated translation calls to reduce the number of function calls in certain cases, leading to improved performance.
Design considerations
The idea of lazily evaluated translation calls has been first discussed in #41305. It enables avoiding string-specific expensive translation lookups until the translations are actually needed, by passing around proxy objects.
In other words: beyond just-in-time loading of translation files (which WordPress already does), this would add just-in-time lookup of individual strings in the translations. Check out this proof of concept to get a better picture.
It can be integrated essentially in two ways, both of which are explained on the core ticketticketCreated for both bug reports and feature development on the bug tracker.:
Change all translation calls to be lazily evaluated by default
Make this opt-in, either with new function arguments or new functions altogether
Benefits
Reduces the number of translation lookups, in some scenarios drastically
On a regular home page request there are ~60% less translation calls, saving around ~10ms (as measured by XHProf)
As a side effect, solves UXUXUser experience issues such as #38643
Caveats and risks
Depending on implementation this either breaks backward compatibility or risks not gaining enough adoption
Documentation, tooling, and developer education can help mitigate this to a certain extent
Adoption could be done gradually, e.g. starting with an opt-in approach and eventually making it the default
Likely will not have a significant impact on typical frontend page loads, as it’s mostly useful for areas like the REST APIREST APIThe REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/rest-api/. schema output, where a lot of translation calls are made without actually using the translations
Needs analysis in more scenarios to measure impact
The REST API schema already has a workaround by using a cache in a static variable
Does not improve situation for actually loading translation files
Initial testing shows that this actually hurts performance due to the additional thousands of proxy objects being created
Effort and timeline
Gradual adoption would mean a multi-year effort to establish lazily evaluated translation calls, while enabling this by default is a significant backward compatibility break that could affect thousands of plugins and themes in the ecosystem. And since it does actually slow down performance in some cases, this solution is not a great candidate for implementation.
Solution E: Optimize/Rewrite existing MO parser
Refactor the existing MO parser in WordPress to be more performant.
Design considerations
Completely overhaul the existing MO translation file parser in WordPress with performance in mind. For example by using Ginger MO, WP Performance Pack, or other existing solutions as a base.
While for instance Altis DXP (Human Made) have actually replaced the existing MO parser with a custom-made PHP extension written in Rust, such an approach is obviously not feasible for core. The new solution needs to be written in userland PHP.
Initial testings with an updated fork of Ginger MO show some noticeable speedups and lower memory usage. It also supports multiple translation files per text domain and multiple locales loaded at once, which could prove beneficial for improving the localeLocaleA 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. switching functionality in WordPress core.
Besides that, plugins like WP Performance Pack and DynaMo have implemented partial lookups using the MO hash table or binary search, avoiding reading the whole file and storing it in memory. That slightly reduces memory usage and performance.
Benefits
Can be used without necessarily introducing another file format
Opens up potential performance enhancements in other areas, i.e. locale switching
Mostly maintains backward compatibility
Caveats and risks
Still a risk of breaking backward compatibility
Effort and timeline
There already is a working proof of concept for this solution, but more testing is required to further refine it and improve its backward compatibility layer. With such an effort being an ideal candidate for a feature pluginFeature PluginA plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins., this could be achieved relatively quickly in a few months.
Solution F: Splitting up translation files
Split translation files from plugins and themes into smaller chunks to make loading them more efficient.
Design considerations
Depending on the project’s size, translation files can be quite big. That’s why WordPress itself uses separate translation files for the admin and everything else, so that not too many strings are unnecessarily loaded.
This strategy could be applied to plugins and themes as well. Either by allowing them to use multiple text domains (which would require developer education and changes to tooling), or by somehow doing this automatically (exact method TBD)
Benefits
Faster loading times due to loading smaller files
Caveats and risks
Risk of breaking backward compatibility
Opt-in approach requires tooling and distribution changes and risks slow adoption
Effort and timeline
Further research is required to evaluate this properly.
Comparison
At first glance, solution A (PHP translation files) is a relatively straightforward enhancementenhancementEnhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature. that maintains backward compatibility and shows promising improvements. However, it does not only require changes to core itself, but also to the translation platform. The security aspect remains a risk, although discussing it early on with stakeholders and gathering more testers would help mitigate it.
Leveraging the native gettext extension as in solution B shows stunning results, but the lack of availability and the non-ideal API are a concern. Still, it’s a progressive enhancement that cannot be ignored. Especially since it could pretty much eliminate the need for additional caching as in solution C.
Caching already loaded translations as in solution C does not eliminate the root cause of the i18n slowness, but can speed up subsequent requests. Unfortunately, persistent object caches or APCu are rather uncommon (though we do not have exact data on the former yet, see #58808), and implementing more complex types of caching (e.g. per-request caching) would require significant exploration effort before becoming a viable option.
Lazily evaluated translation calls (solution D) can shave time off translation calls in some situations, but overall actually decrease performance. While it could help solve some actual UX issues in core, the backward compatibility and adoption concerns make it even less of a suitable solution.
Existing plugins like Ginger MO and WP Performance Pack show that the existing MO parser in WordPress can be further improved (solution E).
Benchmarks
Now to the most interesting part: the hard numbers!
These benchmarks are powered by a custom-built performance testing environment using @wordpress/env and Playwright. The environment has been configured with some additional plugins and the PHP extensions required for some of the solutions. Tests have been performed against the 6.3 RCrelease candidateOne 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). by visiting the home page and the dashboard 30 times each and then using the median values.
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. Theme
Locale
Scenario
Object Cache
Memory Usage
Total Load Time
en_US
Default
15.60 MB
133.58 ms
de_DE
Default
29.14 MB
181.95 ms
de_DE
Ginger MO (MO)
19.24 MB
159.18 ms
de_DE
Ginger MO (PHP)
16.98 MB
138.14 ms
de_DE
Ginger MO (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.)
19.24 MB
153.39 ms
de_DE
Native Gettext
15.99 MB
142.12 ms
de_DE
DynaMo
19.62 MB
157.93 ms
de_DE
Cache in APCu
50.37 MB
181.51 ms
en_US
Default
✅
15.67 MB
121.53 ms
de_DE
Default
✅
29.01 MB
167.67 ms
de_DE
Ginger MO (MO)
✅
19.11 MB
147.19 ms
de_DE
Ginger MO (PHP)
✅
16.85 MB
127.97 ms
de_DE
Ginger MO (JSON)
✅
19.11 MB
144.43 ms
de_DE
Native Gettext
✅
15.86 MB
129.19 ms
de_DE
DynaMo
✅
18.57 MB
133.46 ms
de_DE
Cache in APCu
✅
50.30 MB
170.19 ms
de_DE
Cache in object cache
✅
29.07 MB
173.19 ms
Benchmarks using the Twenty Twenty-Three block theme
Classic Theme
Locale
Scenario
Object Cache
Memory Usage
Total Load Time
en_US
Default
15.35 MB
120.79 ms
de_DE
Default
28.79 MB
172.10 ms
de_DE
Ginger MO (MO)
18.85 MB
145.68 ms
de_DE
Ginger MO (PHP)
16.56 MB
124.73 ms
de_DE
Ginger MO (JSON)
18.84 MB
140.78 ms
de_DE
Native Gettext
15.58 MB
128.26 ms
de_DE
DynaMo
19.24 MB
146.09 ms
de_DE
Cache in APCu
50.13 MB
167.28 ms
en_US
Default
✅
15.19 MB
107.26 ms
de_DE
Default
✅
28.59 MB
154.30 ms
de_DE
Ginger MO (MO)
✅
18.64 MB
133.21 ms
de_DE
Ginger MO (PHP)
✅
16.37 MB
112.94 ms
de_DE
Ginger MO (JSON)
✅
18.64 MB
128.94 ms
de_DE
Native Gettext
✅
15.38 MB
115.11 ms
de_DE
DynaMo
✅
18.10 MB
120.72 ms
de_DE
Cache in APCu
✅
49.99 MB
151.82 ms
de_DE
Cache in object cache
✅
28.65 MB
156.36 ms
Benchmarks using the Twenty Twenty-One classic theme
Admin
Locale
Scenario
Object Cache
Memory Usage
Total Load Time
en_US
Default
15.42 MB
139.83 ms
de_DE
Default
31.92 MB
187.76 ms
de_DE
Ginger MO (MO)
20.07 MB
164.94 ms
de_DE
Ginger MO (PHP)
17.09 MB
139.66 ms
de_DE
Ginger MO (JSON)
20.06 MB
160.87 ms
de_DE
Native Gettext
15.95 MB
143.43 ms
de_DE
DynaMo
20.58 MB
166.79 ms
de_DE
Cache in APCu
58.13 MB
190.38 ms
en_US
Default
✅
15.66 MB
112.69 ms
de_DE
Default
✅
31.84 MB
164.26 ms
de_DE
Ginger MO (MO)
✅
19.99 MB
140.70 ms
de_DE
Ginger MO (PHP)
✅
17.01 MB
118.52 ms
de_DE
Ginger MO (JSON)
✅
19.98 MB
138.49 ms
de_DE
Native Gettext
✅
15.87 MB
120.01 ms
de_DE
DynaMo
✅
19.73 MB
120.26 ms
de_DE
Cache in APCu
✅
58.07 MB
162.41 ms
de_DE
Cache in object cache
✅
31.86 MB
164.28 ms
Benchmarks visiting the WordPress admin
Conclusion
Finding the right path forward means weighing all the pros and cons of each solution and looking at both horizontal and vertical impact, i.e. how much faster can i18n be made for how many sites.
When looking at all these factors, it appears that a revamped translations parser (solution E) could bring the most significant improvements to all localized WordPress sites. Especially when combined with a new PHP translation file format (solution A), which Ginger MO supports, the i18n overhead becomes negligible. Of course the same risks associated with introducing a new format apply.
On top of that, a revamped i18n library like Ginger MO could also be combined with other solutions such as caching or dynamic MO loading to potentially gain further improvements. However, those routes have yet to be explored.
Next steps
The WordPress performance team wants to further dive into this topic and test some of the above solutions (and combinations thereof) on a wider scale through efforts like the Performance Lab feature project. We are looking forward to hearing your feedback on this analysis and welcome any additional comments, insights, and tinkering.
Deadline August 6, 2023
After the deadline passes, the performance team will discuss the received feedback and determine next steps.
You must be logged in to post a comment.