What if WordPress could be launched as a stateful application?

[EdmondDantes]

Experiments with WordPress

After implementing memory model 2, which provides isolation for GLOBALS and SUPERGLOBALS, it became interesting to see whether this level of isolation would be sufficient for WordPress to function correctly.

A quick analysis of the WordPress code confirmed that this isolation is indeed enough for it to run safely inside coroutines.

But simply running WordPress with coroutines would be too plain and unexciting.

A more ambitious idea
What if WordPress could be launched as a stateful application, where:

• each request is handled by its own coroutine
• all execution happens inside a single process

To achieve this, several steps were required:

1. Modify NGINX Unit so it correctly populates the SUPERGLOBALS for each isolated scope.
2. Configure Xdebug to work within the coroutine-based request model.
3. Create a custom entrypoint responsible for loading WordPress modules in the proper order.

Of course, launching WordPress as a fully stateful application requires additional work.
For example:

• many WordPress modules call exit(), which effectively terminates the entire server;
• some parts of WordPress use define() without considering that the code may be executed multiple times in a long-lived runtime.

These behaviors are natural for classic stateless PHP, but they become problematic in a coroutine-driven, stateful architecture.

For demonstration purposes, I decided to focus only on the main page.
To avoid modifying WordPress itself, I prepared a ready-made database, did not install any additional plugins, and simply used the code from the repository as is.

As result: https://github.com/true-async/wordpress-test/blob/main/app/entrypoint.php

3–4 hours of work and you have the WordPress front page running inside a single process, over and over again.
The WordPress code itself remains essentially unchanged.

Do not assume this is a production-ready application.
The issues with exit and redirect have not been addressed. Therefore, whenever something triggers exit, the process returns a 503 error and this is expected behavior at this stage.

[xingye00186]

How about enhance the functions to terminate the current coroutine instead of the whole process, except when it's the root coroutine.

[EdmondDantes]

There are no major issues with the technical implementation.
The real problem is that people will start complaining about the unexpected behavior of exit :)

[xingye00186]

YES ,,, maybe some new trueExit ( ) ：)

[EdmondDantes]

I tried to go a bit further and make the WordPress state shared between coroutines.
This reduces the amount of initialization code. But of course, this approach is extremely dangerous :)

What has been done?

1. We start WordPress in the main coroutine once.
2. We copy the GLOBALS.
3. In each request coroutine, we partially clone the GLOBALS from the main coroutine.

class WPShared
{
    public static array $globals = [];

    public static array $superglobals = ['_GET', '_POST', '_COOKIE', '_SERVER', '_FILES'];

    public static function cloneGlobals(): void
    {
        foreach (WPShared::$globals as $name => $value) {
            // $GLOBALS['wp_query'] = $GLOBALS['wp_the_query'];
            if($name == 'wp_query') {
                continue;
            }
            else if($name == 'wp_the_query') {
                $GLOBALS[$name] = clone $value;
                // alias for wp_the_query
                $GLOBALS['wp_query'] = $GLOBALS[$name];
            } else if(is_object($value)) {
                $GLOBALS[$name] = clone $value;
            } else {
                $GLOBALS[$name] = $value;
            }
        }

        $wpdbShared = WPShared::$globals['wpdb'];
        unset($GLOBALS['wpdb']);
        require_wp_db();
        $wpdb = $GLOBALS['wpdb'];

        // Copy all public properties from $wpdbShared to $wpdb
        foreach ($wpdbShared as $name => $value) {
            $wpdb->$name = $value;
        }
    }
}

foreach ($GLOBALS as $key => $value) {

    // Without superglobals
    if (in_array($key, WPShared::$superglobals)) continue;
    WPShared::$globals[$key] = $GLOBALS[$key];
}

The database is created over and over each time, and this is not quite correct code because it leads to connection exhaustion.

The key benefit of this code is minimal changes to WordPress itself. Essentially, I changed just one line in one file and that’s it.
In fact, the code could be made even better by deciding which objects should be cloned and which should not. This would improve memory usage. I did not do this because it requires a deep, detailed analysis.

[xingye00186]

Here's my understanding:
1.WordPress Initialization‌: Initialize WordPress once in the main coroutine.
2.Global Variables Caching‌ For Data sharing: In the main coroutine before handling requests , we cache the GLOBALS that are used throughout the entire application lifetime and are not specific to individual requests or unique request types. Meanwhile, other request-related super globals are received at the request entry point.
3.Coroutine Isolation And Data sharing : Since global variables are isolated within each coroutine, every request coroutine clones the cached GLOBALS from the main coroutine for shared usage. This approach ensures backward compatibility with existing code while maintaining isolation. However, directly using the cached GLOBALS via "WPShared::$globals[$key]“ in new codes is not recommended.

[EdmondDantes]

Yes. That is exactly how it works.