It will soon be two years since we started working on Studio. I’ve led the project technically and, for most of that time, on the product side as well.
When we began, the local WordPress development space was dominated by tools like Local by WP Engine and MAMP. We wanted to try something different – a lighter, more portable approach built on Playground’s WebAssembly technology. We weren’t sure it would work. Two years later, I’m proud of what we’ve built and learned along the way.
Studio on Playground
When we started the project, we made two key decisions. First, we chose Electron to power Studio as we had experienced React engineers and had team members who already worked with Electron. Of course, cross-platform capability was a huge part, too. This allowed us to quickly release Studio for Windows as well, and to keep unofficial support for Linux builds.
Second, for the underlying technology, we chose Playground, a technology based on WebAssembly (WASM) that allowed us to run WordPress in a browser, basically server-less. The technology was a WordPress.org project started and led by Adam Zielinski, and funded mostly by Automattic. It has brought a lot of challenges, but overcoming them has let us improve not only Studio, but also Playground.
Preview sites
The most outstanding feature in the first Studio release was demo sites, now known as preview sites. They are powered by WordPress.com on a temporary domain, and they allow users to share snapshots of local sites with colleagues, clients or team members. We wanted to make them better than tunnel-based solutions, so we essentially hosted Studio’s sites on temporary WP Cloud instances.
Import and Export
Because Studio uses Playground and a SQLite database, users were somewhat locked inside the tool. It was difficult to import an existing WordPress site into Studio or export it to a remote host. We tried to overcome this by recommending SQLite editors, but this didn’t work well, as Playground added a MySQL compatibility layer on top of that.
Thus, we added the ability to import sites from popular formats like .wpress, Local’s or Playground’s ZIP files or Jetpack Backup. Then, we added the ability to export the database to a MySQL-compatible file, and the whole site into a Jetpack Backup file. It was a great start, and a foundation for the Sync feature that was added later.
To add comprehensive import and export support, we needed to overcome the lack of a good way to produce a MySQL-compatible dump from Studio’s SQLite database, and vice versa. To enable that, we decided to develop custom WP CLI commands which reuse the SQLite plugin’s logic.
While working on that part of the integration, we kept uncovering missing bits in the MySQL-SQLite compatibility layer. It pushed our teams to rewrite the SQLite plugin from a query translation-based approach to an Abstract Syntax Tree approach which is much more robust.
Studio Assistant
We added an LLM-based assistant to Studio before vibe-coding became a thing, but coding wasn’t the primary goal. The assistant should be great at answering general questions about WordPress, and questions about the particular site. It has access to the site context it gets from Studio, so it is aware of plugins and themes installed, and a few other details. It can also be a helper and guide that can run WP CLI commands on the Studio site.
It’s delivered on those goals. We’ve seen users using it as we designed it, but also got reports on more creative use cases like using the assistant to prepare Studio bug reports or writing small plugins.
We keep expanding that feature, and now, the actions it can perform have been enriched by the ability to create a blueprint and start a new site based on that Blueprint.
WordPress.com and Pressable Sync
To ensure users can easily synchronize Studio sites with the remote environment, we expanded the Import and Export feature, and introduced the Sync feature, allowing them to push and pull sites between Studio and WordPress.com or Pressable.
We debated whether to build our own sync logic or base it on Jetpack Backups, and decided on the latter. Backups were already well adopted in our ecosystem, we had the infrastructure ready, and the solution was proven – it was already being used for production-staging synchronization.
We followed up with multiple further improvements, and now it lets users pick files and directories they want to synchronize with production or staging sites. Some recent improvements we’ve shipped there include the ability to create a new site from an existing remote site, and a bar showing the selected size, making it easier to work with upload size limits.
Studio CLI
The first iteration of Studio CLI was quite basic, with preview sites as the only feature available. However, it was a significant step internally, as it paved the way for more features to come. We have a few more in progress, like creating, starting, stopping, and deleting sites, and our end goal is to have all Studio features available in Studio CLI – even without Studio open.
CLI access to Studio features opens up multiple use cases and workflows such as automated testing or scripting for local workflow automations. It also provides an interface for tools like Claude Code, so they can not only help write code on the WordPress site, but cooperate with Studio, too.
Studio Blueprints
Blueprints are templates, or recipes, that can be used to set up WordPress sites. They can include details like a list of plugins to install, a theme to use, options to configure, or even PHP code to execute.
We’ve recently added support for them in Studio, and now users can create Studio sites from those templates. This feature enables plenty of use cases – freelancers can maintain their WordPress site template that includes a premade starter theme and their favorite set of plugins and reuse it to create new sites. A plugin developer team can provide a Blueprint file which makes development and testing easier. Then, a theme author can share a Blueprint to let users easily preview their theme in Studio.
What’s next
We’re not slowing down. Here is what’s coming to Studio:
The CLI will be enhanced with expanded capabilities, including site creation, editing, and deletion, as well as syncing, importing, exporting, and WP-CLI support. This will make Studio much more powerful for developers who prefer working from the terminal, and will let users use Studio site with tools like Claude code.
Xdebug, a frequently requested feature, is on its way. Users will be able to step through code, inspect variables, and debug local sites without relying on die() or var_dump().
Multi-worker capability is already available as a Beta Feature, letting sites handle concurrent requests more realistically. Without that feature, pages like Site Editor aren’t as fast as they could be.
We’re also going to add support for Blueprints v2 as soon as they are finished and stable in Playground core.
Then, we will add the database management through phpMyAdmin or Adminer. This was recently added in Playground, and we are figuring out the best way to include it in Studio.
Leading Studio for two years has taught me a lot about balancing technical ambition with shipping something people can rely on. I’m proud of what we’ve built, and grateful to the team that made it happen.
Two years in, and there’s still plenty to build!
Leave a Reply