Every PHPPHP PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML. https://www.php.net/manual/en/preface.php version WordPress Playground supports ships as a WebAssembly binary. Across all builds and versions, those binaries totaled 888 MB. Two compiler flag changes reduced that to 766 MB, a 122 MB saving (13.7%) without removing a single feature.

What changed?

Playground compiles PHP to WebAssembly using Emscripten. The compiler flag MAIN_MODULE controls which symbols get exported for dynamic linking. Previously, Playground used MAIN_MODULE=1, which exports everything, including thousands of symbols that no extension ever calls.

Switching to MAIN_MODULE=2 tells Emscripten to export only the symbols extensions actually use, similar to tree-shaking in JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com bundlers. The compiler drops everything else.

The challenge: keeping extensions alive

Flipping a compiler flag sounds simple, but MAIN_MODULE=2 aggressively eliminates code that the main module considers “dead.” Playground loads extensions like Intl, Xdebug, Memcached, and Redis as dynamic .so modules, and those modules depend on specific symbols from the main PHP binary. Remove the wrong symbol, and the extension crashes on load.

PR #3244 first mapped the approach: scanning each compiled extension wasm-dis to extract which symbols it references. The build system then feeds those symbols back to the linker as explicit exports, keeping every extension working while eliminating thousands of unused ones.

Three extensions required direct fixes. Xdebug required a __c_longjmp WebAssembly tag injection. Memcached called recv and setsockopt through libmemcached internals, so the build added C shim wrappers. Intl alone needed over 5,000 export symbols, including libc++ functions.

Why two build types?

PHP is synchronous. Browsers are not. Playground solves this mismatch with two compilation strategies, and each one produces a separate set of binaries:

• Asyncify transforms compiled code at build time so it can pause and resume execution. This approach works in every browser but adds overhead to the binary. Learn more about Asyncify.
• JSPI (JavaScript Promise Integration) takes a different approach. It lets WebAssembly call async browser APIs directly, without transforming the compiled code. JSPI produces smaller binaries but currently requires V8-based browsers (Chrome, Edge). Learn more about JSPI.

Playground ships both variants for each PHP version, so the MAIN_MODULE=2 optimization is applied to both:

• PR #3332 targeted JSPI builds.
• PR #3335 completed the same change for Asyncify builds.

The numbers

Per-version .wasm sizes dropped consistently across all supported PHP versions:

The two PRs combined removed 554,793 lines of JavaScript glue code across all builds.

Why smaller binaries matter

Faster downloads and CI. 122 MB fewer bytes to transfer during repository clones, CI pipelines, and deployments. That adds up across all contributors and all automated runs.

Faster WebAssembly instantiation. Smaller .wasm files compile faster in the browser. Compilation cost scales roughly with binary size, so 16% smaller binaries translate directly to faster WordPress startup.

Lower memory usage. Fewer exported symbols produce a smaller function table. The runtime allocates less memory before PHP even starts.

Faster JavaScript parsing. 63% less JS glue code means the browser parses and evaluates significantly less JavaScript before handing control to PHP.

What this means for php-wasm packages

Version-specific packages like @php-wasm/web-8.4 and @php-wasm/node-8.4 ship lighter binaries. No APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. changes — this is purely a build optimization. Existing code that depends on these packages works unchanged.

What comes next

The next step is to benchmark the runtime impact by measuring instantiation time, time-to-first-PHP-response, and memory usage across builds. Those numbers will confirm how the smaller binaries translate to real-world performance gains.

Props to @mho22 for implementing both PRs and reviewing the post, @brandonpayton for reviewing, and @adamziel for the architectural direction. See the full details in PR #3332 and PR #3335.

Setting up a local WordPress environment should be as simple as running a single command. We are excited to introduce the new start command in the WordPress Playground CLICLI Command Line Interface. Terminal (Bash) in Mac, Command Prompt in Windows, or WP-CLI for WordPress., simplifying how you run your local environments.

A simpler way to start

The WordPress Playground CLI is a powerful tool for running WordPress in your terminal. The command server allows users to customize the Playground instance at several levels, but those customizations can be daunting for users who want to run a WordPress instance with a theme/pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party.. With the introduction of the high-level start command (introduced in PR #3040), you can launch a local WordPress instance more intuitively.

Instead of configuring complex parameters, you can now run:

npx @wp-playground/cli start

This command automatically configures the environment with sensible defaults, so you can focus on building.

Persistence by default

The most significant update in this release is persistence (PR #3119). Previously, closing the CLI meant losing your database and file changes unless you manually configured mounts. This update is a major milestone toward simplifying the WordPress development ecosystem. By adding persistence and a high-level entry point, the Playground CLI achieves feature parity with wp-now.

Now, the start command automatically saves your site’s state in your home directory (~/.wordpress-playground/sites/). This ensures your plugins, themes, and content are preserved between sessions. You can stop your server and resume exactly where you left off.

Quick reset for a fresh start

Sometimes, you need to start over. If you want to wipe your persisted site and begin with a clean installation, use the --reset flag:

npx @wp-playground/cli start --reset

Other flags are available for the `start` command:

• --blueprint — Execute a Blueprint file to preconfigure your site with plugins, themes, settings, and content.
• --php — Choose your PHPPHP PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML. https://www.php.net/manual/en/preface.php version. Supported versions: 7.4, to 8.5. Defaults to 8.3.
• --wp — Set the WordPress version. Defaults to latest.
• --port — Define the port for the local server. Defaults to 9400.
• --login — Automatically log in to the WordPress dashboard on launch.

Get started

The start command is available now in the latest version of @wp-playground/cli. Whether you’re testing a new plugin or building a theme, the Playground CLI provides a lightweight, zero-config environment directly in your terminal.

To learn more, check the Playground CLI documentation.

Need to inspect WordPress data, debug a query, or check if a pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party. saved options correctly? The Playground CLICLI Command Line Interface. Terminal (Bash) in Mac, Command Prompt in Windows, or WP-CLI for WordPress. now includes a --phpmyadmin flag that launches phpMyAdmin alongside your local WordPress instance. No extra setup, no separate database server, just one command.

Where is your data?

When developing locally with Playground CLI, you often need to verify what the database actually contains. Until now, doing that required writing custom PHPPHP PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML. https://www.php.net/manual/en/preface.php queries or adding debug output to your code.

The --phpmyadmin flag solves this by giving you a full phpMyAdmin interface right from the CLI.

Getting started

Add --phpmyadmin to your regular CLI command:

npx @wp-playground/cli@latest server --phpmyadmin

After WordPress boots, the CLI prints the phpMyAdmin URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org:

WordPress Playground CLI

PHP 8.3  WordPress latest
Extensions intl

Ready! WordPress is running on http://127.0.0.1:9400 (11 workers)

phpMyAdmin available at http://127.0.0.1:9400/phpmyadmin/index.php?route=/database/structure&db=wordpress

Open that URL in your browser, and you get full access to browse tables, run SQL queries, and inspect your WordPress data:

Custom URL path

By default, phpMyAdmin serves at /phpmyadmin. Change this path to anything you prefer:

npx @wp-playground/cli@latest server --phpmyadmin=/my-db

This serves phpMyAdmin at http://127.0.0.1:9400/my-db/index.php instead.

Combine with other CLI flags

The --phpmyadmin flag works alongside all existing CLI options:

Test a plugin and inspect its database changes

npx @wp-playground/cli@latest server --phpmyadmin --auto-mount

Run this from your plugin directory. Playground mounts your plugin automatically, and phpMyAdmin lets you verify the database tables and options your plugin creates.

Pin a specific WordPress and PHP version

npx @wp-playground/cli@latest server --phpmyadmin --wp=latest --php=8.5

Useful when you need to check how your plugin handles data across different WordPress versions.

Use a Blueprint with phpMyAdmin

npx @wp-playground/cli@latest server --phpmyadmin --blueprint=my-blueprint.json

Combine Blueprints with phpMyAdmin to pre-configure your WordPress instance and then inspect the resulting database state.

Cache phpMyAdmin for faster starts

Each time you use --phpmyadmin, Playground downloads and installs phpMyAdmin into the instance. To skip the download on subsequent runs, mount a local directory to cache the files:

mkdir -p ./pma-cache
npx @wp-playground/cli@latest server --phpmyadmin --mount ./pma-cache:/tools/phpmyadmin

The first run populates ./pma-cache with the phpMyAdmin files. On every subsequent run, Playground detects the existing installation and skips the download.

Where this helps

Here are some practical scenarios where --phpmyadmin saves time:

• Plugin development: Verify that your plugin creates the correct custom tables and stores data in the expected format.
• Debugging options: Check wp_options directly to confirm your plugin settings saved correctly, without writing get_option() debug code.
• Content migrationMigration Moving the code, database and media files for a website site from one server to another. Most typically done when changing hosting companies. testing: Import content via a Blueprint and verify the resulting posts, terms, and metadata in the database.
• Learning WordPress internals: Explore how WordPress organizes its database tables — see how posts relate to postmeta, how taxonomies link to terms, and how user data connects across tables.
• SQL query testing: Run raw SQL queries against your test data before embedding them in your plugin code.

How it works under the hood

phpMyAdmin installs at /tools/phpmyadmin on the virtual filesystem — outside the WordPress document root at /wordpress. The CLI uses a path alias (similar to NginxNGINX NGINX is open source software for web serving, reverse proxying, caching, load balancing, media streaming, and more. It started out as a web server designed for maximum performance and stability. In addition to its HTTP server capabilities, NGINX can also function as a proxy server for email (IMAP, POP3, and SMTP) and a reverse proxy and load balancer for HTTP, TCP, and UDP servers. https://www.nginx.com/.’s alias directive) to serve it at your chosen URL path. This design keeps phpMyAdmin files separate from your WordPress installation, so they never appear in site exports or interfere with your project files.

Since Playground uses SQLite instead of MySQLMySQL MySQL is a relational database management system. A database is a structured collection of data where content, configuration and other options are stored. https://www.mysql.com, phpMyAdmin connects through a custom MySQL-on-SQLite driver that translates queries between the two dialects.

Share your feedback

The phpMyAdmin integration in the CLI came from the same effort that brought the Database panel to the Playground web interface. If you run into issues or have suggestions, share them on the Making WordPress Slack or open an issue on GitHub.

Props to @JanJakes for reviewing this post.

WordPress Playground no longer supports PHPPHP PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML. https://www.php.net/manual/en/preface.php 7.2 and 7.3. The minimum PHP version is now 7.4.

Your existing Blueprints will continue to work. If a Blueprint requests PHP 7.2 or 7.3, Playground automatically upgrades it to PHP 7.4 and displays a warning. No action is required, but you should update your Blueprints when convenient.

Why now?

Three factors drove this decision:

• WordPress CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. is moving forward. WordPress 7.0 (releasing April 2026) drops support for PHP 7.2 and 7.3. These versions now power less than 4% of WordPress sites combined—well below the 5% threshold the project uses for version support decisions.
• These versions don’t work reliably in Playground. PHP 7.2 crashes after a minute or two of use. PHP 7.3 runs noticeably slower than newer versions. These issues existed for months without user reports, confirming low adoption.  Also, they don’t seem to work with the PROXYFS mmap implementation. 
• Maintenance takes time away from improvements. Supporting older PHP versions requires workarounds that delay features everyone can use—like fixing the intl extension crash.

What you need to do

For most users: nothing. Playground handles the migrationMigration Moving the code, database and media files for a website site from one server to another. Most typically done when changing hosting companies. automatically. Blueprint compilation requires PHP 7.4 or later; a warning will be displayed to remove it and update your Blueprint to load a supported version. If you are using the modular loaders, versions 7.2 and 7.3 will not receive updates.

Supported PHP versions

Playground now supports PHP 7.4 through PHP 8.5:

Use latest In your Blueprint, always get the most recent stable PHP version.

Timeline

This change takes effect immediately in WordPress Playground. The automatic upgrade ensures backward compatibility—your existing Blueprints won’t break.

WordPress Core follows in April 2026 with WordPress 7.0, which sets PHP 7.4 as the minimum required version.

Questions?

Reach out in the #playground channel on WordPress.org Slack or open a GitHub issue.