People often ask me why did you build WordPress Playground? Well, here’s the story:
One time I wrote an entry-level introduction to the Gutenberg data layer, and I noticed it was everything but entry-level. It starts with an innocent-looking tar pit of setup instructions where you’re asked to:
- Install Node.js and npm
- Install Git
- Install Docker Desktop
- Know what a CLI is
- Install wp-env from a CLI
- Install a few VS Code extensions
- Save a few PHP, CSS, and JS files locally
- Setup wp-env to use that plugin
- Install npm packages and run npm start
- Really hope none of these steps produced a cryptic error message
If you’ve ever been to a WordPress Contributor day, you know that six hours and help from other developers may not be enough to complete these steps – especially on Windows.
Here’s the setup checklist that I wanted to have:
(yes, that’s a blank list)
The Node.js part of the setup could be scraped by writing
React.createElement() instead of using JSX, but it wasn’t an option for this or that reason. Too bad!
However, installing WordPress was a problem I couldn’t solve. I came up with four ideas, and neither was helpful:
- An isolated WordPress installation just for that course would make people interfere with each other (and prank others).
- A separate cloud instance of WordPress for every participant would be too expensive.
- A private local installation was what I was trying to avoid.
And then it hit me: What if the browser could run a WordPress installation directly in that tutorial? Then I wouldn’t have to install WordPress anywhere. A week later I was looking at a proof of concept, and today we call it WordPress Playground.
Playground already powers some interactive tutorials. In my perfect world, the entire WordPress documentation will become interactive one day – including the Gutenberg data layer introduction.