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 ( ) ：)