Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Gutenberg Block #57

Open
artemiomorales opened this issue Feb 5, 2023 · 1 comment
Open

Gutenberg Block #57

artemiomorales opened this issue Feb 5, 2023 · 1 comment

Comments

@artemiomorales
Copy link
Contributor

artemiomorales commented Feb 5, 2023 •
edited
Loading

Users should be able to easily embed an instance of Playground and configure its options without needing to code. An open-source Gutenberg block, released as an NPM package, would allow them to do this.

Prior Art

Currently, a closed source block exists as part of the wp.org theme repo and is used to render the settings button in the browser window on https://developer.wordpress.org/playground/. This block makes use of the install themes and plugins functionality and has an opinionated list of them, but exposes no other features. A generalized block could be composable and enable extending.

Implementation Ideas

The generalized block MVP could be just a queryString attribute and an iframe.
A more advanced version could expose each Playground query string flag as a Gutenberg control.

List of Features to Enable

Related

  • There's overlap here with Feature Gallery wordpress-playground#128. Essentially a Gutenberg block would be similar to the feature gallery but would allow users to enable those features from within the Gutenberg editor. Perhaps there are considerations to take into account when implementing both.

  • This would enable live code snippets in learn.wp.org courses.
@artemiomorales artemiomorales mentioned this issue Feb 7, 2023
Closed
@adamziel
Copy link
Collaborator

First step: WordPress/wordpress-playground#168

@adamziel adamziel transferred this issue from WordPress/wordpress-playground Jun 2, 2023
johnhooks pushed a commit to johnhooks/playground-tools that referenced this issue Oct 11, 2024
@adamziel
Monorepo (WordPress#57)
e45cbf1 
Restructures the repository as monorepo and separates the PHP implementation from the WordPress-specific bits. The new packages:

* **php-wasm** – low-level WASM PHP primitives
    * A configurable PHP build pipeline for different targets (web, node.js, standalone)
    * A low-level `PHP` JavaScript class with `eval` for executing PHP code and FS utils like `writeFile` for runtime managing the
    * A `PHPServer` JavaScript class for dispatching HTTP requests – both to run the PHP files AND to download static files
    * A `PHPBrowser` JavaScript class to consume the above using an iframe
* **php-wasm-browser** – a high-level layer to efficiently run `php-wasm` in the browser
    * `service-worker` utilities to redirect the browser traffic to `PHPServer`
    * `worker-thread` utilities to offload the `PHPServer` to a separate process. Three backends are available: Iframe, Webworker, SharedWorker.
    * A messaging layer and setup helpers to connect the above.
    * Server utilities to serve the correct headers for the `wasm` files via `.htaccess`.
* **wordpress-wasm** – WordPress-specific WASM PHP bindings for web and node.js
    * The required WordPress-specific setup like constants and filters
    * `wp.data` bundling pipeline for the web configurable to bundle custom code
    * WordPress API to ease common tasks like login, install a plugin, start a block editor with specific settings and content
    * A `fetch`-based transport for HTTP requests
    * An example app demonstrating WordPress in the browser. Let's eventually extract it into a separate package or at least a directory.

Other, general notes:

* Pre-built binaries are shipped in the global `build` directory – it would be nice to either move them to their specific packages, or remove them from the repo completely and download them from somewhere on the initial build.
* `esbuild` is used to build each packages and then the entire app.
* Gulp is used for orchestration. Perhaps https://nx.dev/ would make a good replacement in the future.
* There is no package publishing process yet. Perhaps Lerna would make a good one?

Solves WordPress#51 and WordPress#16
johnhooks pushed a commit to johnhooks/playground-tools that referenced this issue Oct 11, 2024
@adamziel
Add cohesive developer documentation in /docs (WordPress#67)
a2563cd 
This PR populates /docs with a step-by-step documentation connecting the priors documentation efforts shipped in:

* API Reference documentation WordPress#63
* Migrate the project to TypeScript WordPress#61
* Add developer documentation  WordPress#60
* Monorepo WordPress#57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@adamziel @artemiomorales