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.
Currently there is no easy way to identify TracTracAn open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. tickets specifically for adding unit tests. Some are added to the Build/Test Tools component, however the tests are not really “tools”. The reason for this is that unit tests, just like build and test tools, are “non-production code”. That means they can be committed at any time during the WordPress development cycle and do not follow the general milestones-based workflow.
Additionally, many tickets for adding unit tests are marked as “enhancements”. Following the release cycle workflow, enhancements cannot be committed during 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. and 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).. However, in practice unit tests can be committed at any time. It can be difficult to isolate these today, as the Trac search form lacks a filterFilterFilters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. for such tickets, which makes triaging a bit harder.
Some suggestions
During the discussion in #core, several ideas were proposed about how this can be made to work better. And while there isn’t currently much traction on adding E2E tests to CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress., any option explored should take this test type into account. In no particular order:
Component: A new Tests component, which would be exempt from the general workflow, similar to Build/Test Tools. Example component filter.
Keyword: A tests-only keyword to identify that it’s for unit/E2E tests only, and serve to filter tickets for triagetriageThe act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. reports. Example keyword filter.
Milestone: An Any Time milestone could indicate when this type of ticketticketCreated for both bug reports and feature development on the bug tracker. could be committed, being primarily reserved for tests- and docs-only tickets. Example milestone filter.
Type: A test ticket type, to clearly differentiate from the current defect (bug), enhancement, and task (blessed) types. Example type filter.
Type (alternative): A new non-production type could be introduced to broadly cover any ticket that does not affect build/production code. Example type filter.
I think that any of the proposed solutions would make searching and triaging test-oriented tickets a bit easier. Some are more flexible in that it’s easier to combine terms (focuses and keywords).
What are your thoughts on these ideas to make test-only tickets easier to distinguish? Please help continue the discussion in the comments below!
The weekly WordPress Dev Chat meeting is a tradition that dates back to the days when WordPress contributors primarily communicated via IRC. Since that time, these meetings have continued to serve as a regular time each week where contributors working on CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. releases could gather to have synchronous conversations about important matters related to the upcoming releases or to discuss general team processes.
Given the global nature of the WordPress community, the current time for these Dev Chats are not inclusive to everyone to attend. We experimented with a second APAC Dev Chat starting in 2020 as a way of creating opportunities for folks who could not attend the current time to still participate in a weekly Dev Chat. However, those were not well attended and were eventually abandoned.
Scheduling Dev Chats for WordPress 6.7
Given that the primary purpose of Dev Chats is to have a time for synchronous conversations about the upcoming release, holding them at a time where the majority of named the release squad members for 6.7 are unable to attend isn’t ideal. Let’s consider moving them to a more APAC friendly time during this release.
If we’re trying to find a time that is inclusive to folks from India Standard Time (UTC +5:30) to Australian Eastern Standard Time (UTC +10) then the best times for rescheduling seem to be between 3–10 UTC. The early part of that range could cover some folks in the Americas but not folks in EMEA. Likewise, the latter part of this range could work for a majority of folks from EMEA, but is not ideal for folks in the Americas. Moving the time range earlier, to 0:00 UTC would allow participation from more folks in the Americas, but would exclude folks from EMEA and folks around IST as well. With that in mind, I’m proposing a few options for consideration to gather feedback.
Proposed time options
Wednesdays at 3:00 UTC (Ex: Wednesday, August 7, 3:00 UTC): India, Japan, Australia with some late Americas overlap (no EMEA)
Feedback Deadline: July 31, 2024 Please provide feedback to this proposal before Wed., July 31. In your feedback, let us know if you regularly attend Dev Chats and if you have a role for 6.7 that would be impacted (positively or negatively) by your preferred time. We’ll collect responses and plan to announce an updated schedule before Aug. 7, 2024.
Changing the time following the 6.7 release
Currently, WordPress 6.7 is scheduled for release on Nov 12, 2024. Following this release, we will maintain the updated Dev Chat time to address any post-release wrap up, including confirming another time change for the 6.8 release based on the success of this experiment and the needs of the release squad for that release.
Proposal: cancel coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. editor chat
The core editor chat is a SlackSlackSlack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. meeting that takes place every week on Wednesdays in the core-editor channel of the WordPress Slack instance, focused on discussing topics related to 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/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 development.
This meeting has served in time as a place for the following types of communication:
general announcements about Gutenberg or WordPress
Gutenberg project updates, on various features in development
task coordination between the various people contributing
community introductions and help during open floor
issue escalation – bringing attention to specific issues
requests for help or reviews, a place to ask for an extra pair of hands or eyes
The meeting has served us well over the years, but in the past two years several developments occurred:
the post pandemic speed of people picking up these meetings was suboptimal
the 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/ project management has been considerably better
there are people managing tracking and overview issues, updating them with project status
the project features of GitHub itself have been significantly upgraded
several other efforts picked up steam:
there is a new learn section 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/
there is a revamped developer blogblog(versus network, site) on wordpress.org
developer experience and outreach programs improved
we have a constant stream of events like hallway hangouts on varied topics
Considering the above, I suggest that the meeting has now become an inefficient use of the time for those organizing it.
It’s not only that the attendance is low, but the topics discussed and the lack of interest in the meeting itself point to the fact that the other avenues are doing a better job at keeping people engaged and updated with the progress of Gutenberg in WordPress, as well as providing much better avenues for getting support to contribute to or implement the core editor.
Therefore we propose discontinuing the meeting.
What do you think? You’re all invited to chime in with pros and cons, ideas and anything related for the duration of a three week comment time for this proposal to cancel the core editor chat for an indeterminate duration of time.
Thank you
Many thanks to the following list of people who have been helping across the years with running, summarizing and managing the agenda of the core editor chat:
To recap: Due to 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/. technical limitations, the recurring merge of 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/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 to WordPress coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. led to a premature release of many experimental APIs.
After a long discussion and discovery process, Gutenberg introduced a distinction between Plugin-only APIs and Private APIs.
Plugin-only APIs
Plugin-only APIs are like early access feature previews that require community feedback to mature. They are only released as a part of the Gutenberg plugin and not merged into WordPress core. It’s implemented as follows:
// Using IS_GUTENBERG_PLUGIN allows Webpack to exclude this
// export from WordPress core:
if ( process.env.IS_GUTENBERG_PLUGIN ) {
export { pluginOnlyAPI } from './api';
}
Private APIs
Private APIs are internal. They are merged into WordPress core, but cannot be accessed by extenders in plugins or themes. Only the code inside 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 can access the private APIs using the dedicated utilities – please review the coding guidelines to find out more.
Aftermath
The goal of taming new experimental APIs has largely been achieved. Thanks to the recent coordinated effort to use the private APIs, only two new ones made it into WordPress 6.2. In contrast, previous WordPress releases introduced 14, 20, and even 40 new experimental APIs. Two is phenomenal 🎉 The remaining follow-up work is being tracked separately in GitHub issue #47786
Regarding the stabilization of the existing experimental APIs, a case-by-case assessment of the several hundred experimental APIs in WordPress core will be necessary. WordPress 6.2 addressed a few such exports, and the rest will likely be gradually addressed in future releases. Some may get stabilized, others may get deprecated, and others may stay indefinitely. The upcoming WordPress Community Summit may provide some answers, as the issue of deprecating JavaScript APIs has been proposed as a discussion topic.
Many thanks to everyone for the productive discussions and efforts. The outcome of this effort is a testament to the commitment of the WordPress community to maintain high-quality software.
In the WordPress release cycle, feature freeze happens when the first 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. version is released. “Feature freeze” means that development of new features and enhancements ends, and work continues on testing them and fixing bugs. They have to be ready for testing and committed to coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. before the freeze, before Beta 1 is released.
Exceptions to Feature Freeze
Changing tickets from “enhancementenhancementEnhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature.” to “task” right before Beta 1 is an exception that has been used for many years. It was strictly for new features and substantial enhancements that weren’t ready in time for beta, and needed a few more days to get completed and committed (thus delaying their testing to Beta 2). The intent was to allow another two or three days, not a week or two. This exception used to happen quite rarely, perhaps a few times per year.
However lately this exception has become part of the standard release workflow. In recent years, it’s become common for 15 to 20 tickets for code coming from 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/ to be changed to tasks each release. The reason they are changed is not to give the developers a few more days to complete them. It is mostly to signify that they are going to be committed later.
Why Gutenberg Merges Are Different
The new features and enhancements coming from Gutenberg have already been tested. I think everybody would agree that testing in Gutenberg releases is quite better and more efficient than testing in core 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. beta releases:
According to recent stats at least 60% of these sites are rapidly updated to the newest version of the 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.
So the new features and enhancements that are in a Gutenberg release are being tested on at least 180,000 sites, and by well over 180,000 users, mostly in a production environment. For comparison, there are usually only a few thousand installs for beta releases.
It seems the WordPress release workflow should adapt to these changes in the development process: synchronizing code between two repositories, new Gutenberg releases every two weeks, etc. Using the old “change enhancements to tasks” exception shouldn’t be necessary for code that has already been released and tested in Gutenberg. However, it still makes sense for feature development that happens on TracTracAn open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress..
New TicketticketCreated for both bug reports and feature development on the bug tracker. Type: Gutenberg merge
I’d like to propose to stop changing tickets from “enhancement” to “task” before beta when the code has been sufficiently tested in Gutenberg.
Based on the above plugin installation stats it seems that a sufficient time for testing in a Gutenberg release would be one week. Ideally, all code coming from Gutenberg would meet this criteria, regardless of the WordPress release cycle stage (alpha, beta, or 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).). An exception would be when committing 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 that can be tested simultaneously in Gutenberg and core beta/RC releases.
To easily distinguish these tickets maybe a new ticket type can be introduced. Perhaps “Gutenberg merge” or “Gutenberg sync”? Alternatively, the existing gutenberg-merge keyword could be used, although it would be somewhat less noticeable.
For example:
Feedback
I realize that this proposal affects only a small part of the community, primarily frequent core contributorsCore ContributorsCore contributors are those who have worked on a release of WordPress, by creating the functions or finding and patching bugs. These contributions are done through Trac. https://core.trac.wordpress.org., committers, and release leads. But I still think it is best to propose it here in the interest of openness, and for documentation purposes.
If you have thoughts about how new Gutenberg features are handled with regard to “feature freeze” during the beta stage of the release cycle, please share them in the comments below.
This post outlines a proposal to add a script loading strategy enhancementenhancementEnhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature. to coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress.’s existing Scripts 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..
The underlying goal of this effort is to make it easier for WordPress 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 developers and core to use “modern” loading approaches for 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/. (like defer and async), which will help WordPress sites load faster and operate more smoothly, giving users a better experience.
Why add a loading strategy?
Data from the Web Almanac project (query) indicates that render blocking JavaScript is a significant problem on the web, with 77% of mobile pages having render-blocking scripts in the document <head> . This query shows that approximately 40% of WordPress sites stand to benefit from deferring additional scripts. Adding defer or async to script tags enables script loading without “blocking” the rest of the page load, resulting in more responsive sites overall better user experience.
Currently WordPress core as well as plugins and themes register scripts with the wp_enqueue_script and/or wp_register_script functions. Although these functions include the ability to control the placement of the script (with the in_footer parameter), they don’t include support for adding modern attributes such as defer or async to script tags.
To add async or defer today, developers must resort to less flexible and more fragile approaches, such as directly filtering the tags at the point of output (using the script_loader_tagfilterFilterFilters 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.), or handling the 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.) output directly using wp_print_script_tag and the wp_script_attributes filter.
Using the first approach and directly filtering the tag can easily break: for example if two plugins both try to filter a tag, or if a tag has unexpected attributes already (eg. adding defer to a tag that already has async). Using the the second approach developers must carefully handle dependencies and output manually – things that that the Scripts API usually helps take care of.
How the loading strategy works
Developers specify a loading strategy when registering or enqueueing a script. For example, a defer strategy can be specified when the script isn’t required immediately during the page load cycle. WordPress will then determine which scripts can actually use a strategy based on logic for each strategy. For example, to ensure that scripts are executed in the order they are enqueued, defer can only be used on a script if every script that depends on that script can also be deferred. Inline script tags added with wp_add_inline_script would also be considered to ensure proper execution order.
The implementation would come with several initial built-in loading strategies: defer, async, and the default blocking behavior.
Out of scope for this feature
The loading strategy does not enable direct control of script tag attributes. This idea was originally proposed 10 years ago in #22249 and several approaches were considered on that ticketticketCreated for both bug reports and feature development on the bug tracker. including a script attribute filter. This proposal takes a step back and aims to solve the script loading strategy aspect more comprehensively and directly while avoiding exposing the potential complications of direct attribute control.
It is worth noting that it is already possible to control attributes on wp_enqueue_script tags directly using the script_loader_tag filter. However, this is a bit of a “brute force” approach which is limited and fragile because it doesn’t consider dependencies and multiple plugins can take conflicting actions on the same tag.
What are potential concerns with this feature?
One big concern with adding this feature to the WordPress Script API is potentially introducing a breaking change. wp_enqueue_script is a fundamental API in WordPress core, and any breaking changes could have widespread implications. Possible breakage is a possible reason that adding custom attributes as proposed in #22249 was never added to core.
This new proposal aims to ensure that there is 100% backwards compatibility, resulting in zero risk of breakage. The loading strategy will ensure that all existing uses continue to function as expected; for example, passing the boolean in_footer attribute will still control script placement. In addition, it will ensure that scripts continue to be executed in the order they are enqueued – as described above in the “How the loading strategy works” section.
Conclusion and Next Steps
Giving developers the ability to specify a loading strategy will enable them to use more advanced JavaScript loading methods while still ensuring that enqueued scripts are executed in the correct order. A “strategy” approach is also forward thinking: as the web evolves, new strategies can be developed and made available to WordPress developers. After gathering feedback, we will proceed to discussing the implementation approach and, ultimately, proposing 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..
Have you tried using defer or async with WordPress (or do you already)? How do you think this enhancement would change that? Please leave your feedback about this proposal in the comments below and if you can, join us at our weekly performance team chats, where we are likely to discuss this proposal in the future.
Thanks to @flixos90, @tweetythierry and @mxbclang for help writing and reviewing this post and for the many contributors who have added to the discussion around this enhancement already.
This is a small proposal to amend the standards for multi-line comments. The current standards seem to require that multi-line comments have to be done like this:
/*
* This is a comment that is long enough to warrant being stretched over
* the span of multiple lines. You'll notice this follows basically
* the same format as the PHPDoc wrapping and comment block style.
*/
There is also a warning that they must not begin with /** as that is the DocBlockdocblock(phpdoc, xref, inline docs) syntax, and may result in parsing errors.
The proposal is to remove this requirement and to encourage multi-line comments to be done with slashes, same as single-line comments.
// This is a comment that is long enough to warrant being stretched over
// the span of multiple lines. You'll notice this follows basically
// the same format as the single-line comment style.
Reasons:
Reduce possibility of typos and eventual parsing errors. This is not just from typing, seems many modern IDEs can auto-complete or auto-correct /* to /** which may lead to more typos.
The de-facto 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/. coding standard Prettier, and the PHPPHPThe web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher’s PSR-12 do not enforce specific comment styles.
In addition to encouraging typos, the current standard is visually very close to the DocBlock standard which may lead to a moment of confusion when reading the code (uh, is this an incomplete DocBlock that doesn’t have @since and @param?).
This early demo runs a full WordPress directly in the browser without a PHPPHPThe web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher server! While it isn’t fully stable yet, it is a major breakthrough that could transform learning, contributing, and using WordPress. This post explores the opportunities and explains in detail how it works.
Your help is needed to realize the vision laid out below. None of the presented mockups and early explorations are currently reliably implemented. This project needs volunteers to stabilize the code and build revolutionary tools on top of it. If you’d like to be a part of it, please say so in the comments!
Learning WordPress in the browser
The code examples in the WordPress handbook could become runeditable, like in this early preview:
Furthermore, an in-browser IDEIDEIntegrated Development Environment. A software package that provides a full suite of functionality to software developers/programmers. Normally an IDE includes a source code editor, code-build tools and debugging functionality. could lead new contributors through solving their first “Good first issue” without setting up a local development environment. Just like this early preview:
Finally, a guided code editor could become a primary teaching tool for new developers. They would click a “Build your first 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.” button 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/ and immediately start coding. This is what it could look like:
WordPress Developer tools
Testing code on different WordPress, PHP, and 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/ versions currently require a tedious setup. With an in-browser WordPress IDE, it wouldn’t require any setup at all. As a developer, you would switch between the different versions by selecting different entries in a box:
Taking it further, the continuous integration pipeline could replay the failed tests right in the browser and provide a code editor to debug and fix the problem on the spot:
On a different note, the desktop and mobile apps could reuse WordPress code by running an actual WordPress instance – even when offline.
Finally, WordPress could potentially be scaled up by spinning up many tiny self-contained WASM instances directly on the edge servers.
Showcasing
Embedding a demo of your 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, pattern, or theme directly on the website makes another great use case. One such demo lives on wpreadme.com, an in-browser WordPress readme.txt editor. Here’s what the plugin directory could look like:
Today, a WordPress server is required, and ideally, one WordPress per user to always present the same initial state.
The in-browser WordPress enables one private WordPress per user with no marginal server cost. Everyone can start logged-in as an adminadmin(and super admin) with no security risks.
Furthermore, importing an existing WordPress website into WASM runtime would create a staging website. Users could try themes and plugins on a copy of their site without affecting the live sites. Then, once the staging website looks good, they’d click a button and publish the changes.
How else would you use the in-browser WordPress? Please share your ideas in the comments so more use cases can be considered in the future.
A service worker traps HTTPHTTPHTTP is an acronym for Hyper Text Transfer Protocol. HTTP is the underlying protocol used by the World Wide Web and this protocol defines how messages are formatted and transmitted, and what actions Web servers and browsers should take in response to various commands. requests and re-routes them to WordPress.
Firstly, PHP is compiled using an adjusted recipe from the php-wasm repo. It’s powered by Emscripten, a drop-in replacement for the C compiler. Unfortunately, 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/. currently cannot run as WASM. However, SQLite can, and WordPress supports SQLite via the wp-db-sqlite plugin.
Emscripten compilation yields two files: webworker-php.wasm, which is the assembly, and webworker-php.js, which downloads the assembly file, creates a virtual heap, and exposes named native functions conveniently wrapped to accept and return 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/. data types.
You need to load the webworker-php.js in a webworker and add a tiny wrapper class:
WebAssembly PHP runtime has its own filesystem and WordPress is shoehorned into it as a data bundle.
First, a fresh WordPress distribution is downloaded and patched with the wp-db-sqlite plugin. It’s about 66MB large, but an optimization pipeline makes that 46MB by minifying the PHP files and removing non-essential static assets. Getting down to just 12MB is possible, but it’s not easy.
Second, the WordPress installation process kicks in. A script serves our WordPress via the built-in PHP server and sends a special curl request to /wp-admin/install.php?step=2. Unfortunately, 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/ is hard-wired to MySQL and not a good match here.
Lastly, Emscripten’s file_packager turns our WordPress copy into a data file named wp.data and a JavaScript loader named wp.js. Loading both the PHP runtime from webworker-php.js and the WordPress data bundle from wp.js allows you to run <?php require “wordpress/index.php”; right in the browser!
A service worker reroutes the HTTP to WordPress
WordPress reads request information from $_SERVER, $_GET, $_COOKIE and so on. Normally these variables are populated by ApacheApacheApache is the most widely used web server software. Developed and maintained by Apache Software Foundation. Apache is an Open Source software available for free., NginxNGINXNGINX is open source software for web serving, reverse proxying, caching, load balancing, media streaming, and more. It started out as a web server designed for maximum performance and stability. In addition to its HTTP server capabilities, NGINX can also function as a proxy server for email (IMAP, POP3, and SMTP) and a reverse proxy and load balancer for HTTP, TCP, and UDP servers. https://www.nginx.com/., or another web server. However, in this case, there isn’t one.
That takes care of the request, but capturing the complete HTTP response is still necessary. The PHP outputs information in only two ways: stdout and stderr. The response body comes out via stdout, but the HTTP status code and headers don’t. They need to be manually streamed to stderr where the JavaScript app can capture them:
The actual code is much more involved, but it’s based on the same idea.
Node.js is supported, too
Running WordPress in different JSJSJavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors. runtimes is a matter of connecting these major building blocks with runtime-specific plumbing. Today there is an in-browser version and a node.js version. Here’s how they differ:
A web worker loads PHP WebAssembly, downloads WordPress, mounts it in PHP’s in-memory filesystem, and registers. Webworker is needed to avoid freezing the UIUIUser interface while handling requests.
A service worker traps the browser’s HTTP requests and re-routes the .php ones to the web worker.
WordPress is rendered in an 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. by a minimal index.htmlHTMLHyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. once both workers are loaded.
It could do the same for WordPress docs; see this early preview.
Stackblitz doesn’t need a specialized backend. It runs Node.js, npm, and webpack right in the browser via WebAssembly. Other than hosting and delivering a few megabytes of data, Stackblitz has no marginal costs. This idea is called Web Containers.
Learning WordPress and writing code used to be separated. Now they can be one and the same. From runnable code snippets to new, svelte-like docs formats, WebContainers + WebAssembly WordPress is an educational game-changer.
However, a Node.js WordPress server on Stackblitz is sluggish
Rendering a single wp-admin page takes a second locally but up to 40 seconds on Stackblitz. That’s much longer than most developers are willing to wait. Here’s why that happens:
A local Node.js WordPress server works like this:
WordPress runs on WebAssembly PHP
WebAssembly PHP runs on a native Node.js
However, a Stackblitz Node.js WordPress server has an extra layer:
WordPress runs on WebAssembly PHP
WebAssembly PHP runs on WebAssembly Node.js
WebAssembly Node.js runs on a native Chrome
It’s like a box in a box: A WebAssembly runtime in Chrome runs Node.js that has its own WebAssembly runtime. WordPress runs on the latter, not on the former, and that indirection causes a massive slowdown.
Luckily, the browser can run WebAssembly natively without an intermediate Node.js layer.
It is much faster! Unfortunately, the speed comes at the expense of simplicity.
Stackblitz requires a service worker just like the in-browser WASM WordPress. However, you can only have one per domain. Therefore, the WordPress files in this example are hosted on a Netlify domain.
Then, the Stackblitz files can’t be directly mounted into the in-browser PHP filesystem. The changes need to be synchronized manually. In this example, a node.js file watcher notifies the PHP webworker about the updates via WebSockets and onmessage/postMessage. There are bugs, but all are fixable.
Known issues
WASM WordPress issues:
The in-browser WordPress builds sometimes crash the Chrome tab, see the GitHub issue. Firefox, Safari, and node.js are much more stable.
Stackblitz integration issues:
The in-browser Stackblitz setup doesn’t watch subdirectories.
WordPress exceeds Stackblitz size limits unless imported as a node_module.
Stackblitz corrupts a predefined binary .sqlite database file. A base64-encoded version is shipped instead.
Stackblitz doesn’t pass a server-side set-cookie headerHeaderThe 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. to the browser. That’s 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.. Workaround: the express.js server handles the cookies internally.
Next steps
Your help is needed to fully realize the vision laid above. None of the presented mockups and early explorations is currently reliably implemented. This project needs contributors to stabilize the code and build revolutionary tools on top of it – see the issues list on GitHub. If you’d like to be a part of it, please say so in the comments!