-
Notifications
You must be signed in to change notification settings - Fork 212
Docs – loose notes to turn into proper documentation pages later on
- Existing docs
- https://github.com/vshymanskyy/awesome-wasm-tools/blob/main/README.md
- https://github.com/WordPress/wordpress-playground/issues/1128
- https://github.com/WordPress/wordpress-playground/issues/1078
- https://github.com/WordPress/wordpress-playground/issues/134
- Check these WASM PRs and the related discussions:
From https://github.com/WordPress/wordpress-playground/issues/483:
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 test for that:
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.
Any Playground-specific variable or constant is a private API and may get renamed or disappear without a warning. A long-term goal for Playground is to have 1:1 feature parity with native PHP and be indistinguishable from it.
More content: