Define a PHP constant so PHP code can detect it is running in Playground

[eliot-akira]

Recently, there was an issue where the Create Block Theme plugin was throwing an error due to limited networking support in Playground.

• Support wp_mail() #276

Maybe we could disable Google fonts if the plugin is on a Playground instance for now.

If the Playground could define a PHP constant, like WORDPRESS_PLAYGROUND, then plugins/themes could detect it and modify their behavior accordingly.

---

Another possible use case: when running wp-now on the server, a locally installed wp-cli could detect and interact with it somehow.

• wp-now: Make it possible to use WP-CLI playground-tools#25

we may just need to tell WP-CLI where to find the WordPress files, SQLite database, and project files. At the moment however, the knowledge of this only exists in the virtualized filesystem.

If wp-now could define a PHP constant, like WP_NOW, it could help wp-cli (and maybe other tools) to implement a deeper integration. How exactly the communication between them would work is a bigger question. 🙃

---

@adamziel's recommendation:

I recommend not detecting Playground because it will break your plugin in many contexts.

You could, however, explicitly create a constant via a Blueprint and then check for that:

https://playground.wordpress.net/#{%22constants%22:{%20%22MYPLUGIN_SETUP_DEMO_CONTENT%22:%22true%22}}

This way your plugin will only load the demo data when that's expected.

I understand why blanket Playground detection is tempting for setting up demo content. Playground, however, is more than just the app on https://playground.wordpress.net/. Here's a few contexts where loading the demo content would be harmful instead of useful:

• The WordPress Playground plugin adds a "Preview now" button to the plugin directory. It imports the entire sites and installs the plugin on top of that.
• wp-now is a local development environment for WordPress. Your plugin may be installed there.
• Ditto for WordPress Playground for VS Code.

If installing the plugin does something unexpected to the site content in either of these tools, the user will likely be surprised and assume the plugin is broken.

[adamziel]

Good idea @eliot-akira! A few thoughts:

• This could also be baked into php_wasm.c
• It could be a $_SERVER or $_ENV entry like the rest of PHP environmental information

[eliot-akira]

Some related ideas:

• WORDPRESS_PLAYGROUND_VERSION
• A constant or env variable when running in browser or server side
• JavaScript global "constant" for scripts to detect when running in Playground iframe

[adamziel]

@danielbachhuber I'll add a constant/something global in php_wasm.c so that it's universally available for all Playground apps

[danielbachhuber]

@adamziel Sounds good.

[dmsnell]

could this unintentionally push people to write code that behaves differently on the playground and then gets shipped to production and fails because it's only ever tested in this environment?

can we find a way to fix those errors in the Playground without making the PHP code aware that it's running inside of it?

[eliot-akira]

code that behaves differently on the playground

A possible use case is for a plugin to detect the Playground and adjust its behavior to be compatible with it, such as disabling Google Fonts. This kind of compatibility issue is probably better solved on Playground side, instead of per plugin.

Another use case is for a plugin or CLI tool to integrate with the Playground environment by design.

For example, theoretically WP-CLI could interact with a locally running Playground's files and SQLite database. Or, a plugin could provide a settings screen or custom post type edit screen, which optionally communicates with the Playground client and parent context, if any.

An idea in particular I'm exploring is to have two iframes connected to a Playground client: an admin edit screen and the site frontend as preview. When something changes on one side, I'd like for the plugin to send a message to the "host" so the preview pane can be refreshed. And this feature can be conditionally loaded when running inside the Playground.

There can be other ideas involving multiple iframes - maybe a responsive design tool - which could benefit from having environment-specific code to support bi-directional exchange between the host running the Playground client and the embedded website.

But then again, the host can always set such env variables for a specific project or plugin.

Maybe there's no need for Playground itself to provide them as part of the public API. I noticed PHP WASM sets a server constant SERVER_SOFTWARE as PHP.wasm. I suppose this is undocumented, but someone's code could start to depend on that particular value, just because it's there. It reminds me of browser user agent strings and why we'd want to avoid environment-specific code.

[adamziel]

Another way to resolve this would be to document how to do feature detection (network, message passing, pthreads, ...) instead of blanket Playground detection – this could make Playground-based applications portable by default. As for wp-cli, the SQLite integration was primarily meant for non-Playground WordPress so that would have to rely on feature detection anyway.

[adamziel]

@eliot-akira also, I can't find the original issue where you posted a dual-pane screenshots of Loops and Logic but just wanted to say it was super cool! ❤️