PHP Blueprints would unite all the Blueprint runtime environments, use-cases, and developers. Single library and documentation unlocking multiple ecosystems.
PHP would run the logic in a write once–run everywhere fashion.
Playground would be a thin, interchangeable glue layer using WASM to run WordPress and PHP in the browser, Node.js, VS Code, iOS, Android, desktop, etc.
PHP-powered Blueprints would:
Force us to write universal and interoperable code
Empower WordPress developers who are familiar with PHP
Push Playground and PHP.wasm to feature parity with native PHP
Remove Playground internals and asynchronous code from the equation
Remove the PHP/TypeScript dualism. We’ll achieve more with less code
Remove the temptation to duplicate implementations in different JS tools, PHP, and WordPress plugins
Blueprints would become the lingua franca of WordPress. All the runtimes would rely on the same orchestration library:
“Quick development setup”, e.g. I have some local files and I run wp start
Technical steps to get there
Here's the big picture of what we'll need to do:
Disregard WASM and prototype a PHP library that only works well in native PHP. Don't overuse third party libraries, but rely on small components like Symfony EventDispatcher when applicable.
Run that library in PHP.WASM, identify all the ways it fails.
Bundle the library as phar, explore using it in WordPress, WordPress Playground plugin, wp-now, wp-cli etc.
Outline a plan to make it work with the least amount of work. Use workarounds, adjust the PHP library, adjust PHP.wasm implementation, and build polyfills as needed.
Outline a plan to replace all the workarounds with stable, long-term, easy-to-maintain solutions.
Bring the phar library into WordPress Playground core, make the @wp-playground/blueprints library a thin wrapper that delegates all the tasks to the PHP implementation
WordPress Playground plugin ships a PHP implements of site export and import. This code could be moved to the PHP Blueprint library and replace the TypeScript export/import implementation.
The PHP library should be extensible.
We could generate the Blueprint JSON schema from PHP types and interfaces in the same way as we do that today using the TypeScript types.
A future version of the Blueprint library should know how to extract only a part of a remote ZIP file without downloading all of it.
wp-cli could handle complex steps like setWpConfigConstant (wp config set), enableMultisite (wp core multisite-convert), runWpInstallationWizard (wp core install). Same for wp-now features like downloading and installing WordPress core or the SQLite integration plugin.
cc @bgrgicak @dmsnell @mtias @youknowriad @eliot-akira @sejas @danielbachhuber
Let’s pivot Blueprints from a TypeScript library to a PHP library. I started the explorations in this repo:
https://github.com/WordPress/blueprints/
Motivation
PHP Blueprints would unite all the Blueprint runtime environments, use-cases, and developers. Single library and documentation unlocking multiple ecosystems.
PHP-powered Blueprints would:
Blueprints would become the lingua franca of WordPress. All the runtimes would rely on the same orchestration library:
Here's a few specific use-cases I have in mind
Technical steps to get there
Here's the big picture of what we'll need to do:
@wp-playground/blueprints
library a thin wrapper that delegates all the tasks to the PHP implementationRelated and known PHP.wasm limitations
Other notes
wp-cli
could handle complex steps likesetWpConfigConstant
(wp config set
),enableMultisite
(wp core multisite-convert
),runWpInstallationWizard
(wp core install
). Same forwp-now
features like downloading and installing WordPress core or the SQLite integration plugin.cc @bgrgicak @dmsnell @mtias @youknowriad @eliot-akira @sejas @danielbachhuber