Everyone started in a different phase of WordPress; some started with 5.0 when GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ was released. I personally started with version 2.5, and I can’t remember what the internet was like. WordPress Playground is the fastest way to open a modern WordPress site in the browser. It’s becoming something broader: a version-spanning WordPress lab. Now you are able to see how WordPress worked at the time that you started to use it.

Recent Playground updates make it possible to boot legacy WordPress releases in the browser, including versions that predate the blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. editor, the REST APIREST API The REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/rest-api/, modern 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/index.php syntax, and many assumptions baked into today’s development tools. That changes what Playground can do. It is no longer only a quick sandbox for the latest WordPress. It can also be a place to investigate old compatibility reports, compare admin experiences across releases, and preserve the behavior of earlier WordPress eras.

This work brings together three pieces:

• PHP 5.2.17 compiled to WebAssembly.
• Browser boot support for WordPress 0.7 through 6.2.
• UIUI UI is an acronym for User Interface - the layout of the page the user interacts with. Think ‘how are they doing that’ and less about what they are doing. and compatibility fixes that make old versions practical to explore.

The result is a smoother way to move across WordPress history without installing old PHP runtimes, configuring a database, or keeping a collection of local server stacks alive. This is not a contribution to WordPress history, but it also improves WordPress Playground Compatibility.

What changed

The most visible change is in the Playground settings panel. A new Include older versions option expands the WordPress version picker to show older releases. The checkbox is under the WordPress version; once selected, Playground shows older versions of WordPress.

When older versions are visible, Playground handles the PHP pairing automatically:

WordPress version range	Runtime behavior
WordPress 0.7-4.9	PHP locks to 5.2
WordPress 5.0-6.2	PHP locks to 7.4
WordPress 6.3 and newer	Playground uses the modern default flow

That automatic locking matters. A WordPress version that expects PHP 5.2 doesn’t benefit from a modern PHP 8.x runtime. Conversely, mid-modern WordPress releases can fail in surprising ways on current PHP versions even though they are not ancient. Playground chooses the runtime that gives each era the best chance to boot and behave like itself.

The picker also shows release code names, so contributors can move through versions by both number and WordPress history. Testing WordPress 2.8 “Baker” or WordPress 6.9 “Gene” becomes a browser setting rather than a local environment project.

Why it matters

Legacy support is not about recommending old software for production. It is about making old software observable.

That is useful for several kinds of work.

Reproduce old compatibility reports

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. and theme developers often receive reports that mention an old WordPress version but do not include a full reproduction environment. Historically, testing those reports meant building an old stack: an old WordPress zip, an old PHP runtime, a database, and enough local configuration to keep everything running.

Playground can now remove most of that setup. Open a legacy version, install or load the plugin, and check whether the report reproduces. If it does, you can compare the same steps against a newer release and decide whether you are looking at a plugin bug, a WordPress behavior change, or an environment-specific problem.

Validate support decisions

Dropping support for an old WordPress version should be a product decision, not a guess. Playground makes it easier to verify what actually breaks.

A contributor can test a plugin on a legacy release, confirm whether activation works, visit the admin screen, create a post, and inspect any fatal errors or editor failures. That is much more useful than relying on assumptions about what “probably” still works.

Compare editor and admin behavior

WordPress changed significantly between the classic admin era, the REST API era, and the block editor era. Running old versions in Playground gives contributors a quick way to see those differences directly.

That can help with documentation, contributor onboarding, migrationMigration Moving the code, database and media files for a website site from one server to another. Most typically done when changing hosting companies. planning, and support work. Instead of describing how a workflow used to behave, you can open it.

Preserve WordPress history

WordPress is more than the current release. Old admin screens, editor flows, database assumptions, and plugin APIs are part of the project’s history.

Running those versions in the browser creates a lightweight preservation tool. It gives contributors, educators, and historians a way to inspect earlier WordPress releases without maintaining obsolete local infrastructure.

How it works

The feature looks simple in the UI, but it required several layers of runtime and compatibility work.

PHP 5.2.17 in WebAssembly

WordPress 1.0 through 4.9 expects a PHP era that modern development machines usually do not provide. Playground now includes PHP 5.2.17 WebAssembly builds for browser and Node runtimes, across the supported async modes.

Getting PHP 5.2 into that environment required more than changing a version number. The build needed legacy compiler support, compatibility shims, PHP source adjustments, runtime wiring, and safeguards for extensions that do not make sense in the old runtime.

The important user-facing result is simple: Playground can run the PHP generation that early WordPress expects, without asking contributors to install it locally.

Legacy WordPress boot flow

Modern Playground boot logic assumes a relatively recent WordPress. Legacy WordPress versions need different handling.

The legacy boot flow accounts for older package formats, older PHP syntax expectations, database assumptions, and WordPress source quirks across the early release line. It also covers the mid-modern range where WordPress 5.0 through 6.2 behaves more reliably on PHP 7.4 than on the newest PHP runtimes.

This is why the version picker can expose a broad set of releases while keeping the PHP selector locked to a compatible runtime.

SQLite compatibility

Playground uses SQLite instead of a traditional 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 server. Modern WordPress support already depends on SQLite integration, but older WordPress releases introduce additional compatibility issues.

Recent work patches the SQLite integration path for PHP 5.2 compatibility and adjusts legacy boot behavior so older WordPress versions can reach a usable installed state in the browser. For contributors, this means the site can boot, load the admin, create content, and activate plugins without requiring a separate database service.

Classic editor compatibility

Legacy WordPress support also needs the editor to load. In older versions, TinyMCE initialization can be sensitive to how inline editor CSSCSS CSS is an acronym for cascading style sheets. This is what controls the design or look and feel of a site. is serialized into 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.

Playground now escapes the CSS it inlines into TinyMCE’s content_style path. That prevents characters from Dashicons and other editor styles from breaking the classic editor initialization script. The legacy test coverage now checks real browser editor boot behavior, including older new-post screens.

That detail may sound small, but it is the difference between “WordPress boots” and “WordPress is useful enough to inspect.”

Real scenarios

Investigate a plugin activation issue

A user reports that a plugin fails on WordPress 4.9. Open Playground, enable older versions, select WordPress 4.9, and let Playground lock PHP to 5.2. Install the plugin and try the activation path.

If activation fails, you have a fast reproduction environment. If it works, compare it against WordPress 5.0 or 6.2 to see whether the issue depends on a specific WordPress era.

Check a classic editor regression

Some support reports are really editor reports: a button disappears, TinyMCE fails to initialize, or old metaboxMetabox A post metabox is a draggable box shown on the post editing screen. Its purpose is to allow the user to select or enter information in addition to the main post content. This information should be related to the post in some way. behavior changes. With legacy WordPress available in Playground, contributors can open a pre-block-editor release and inspect the classic editing flow directly.

That is especially useful when debugging migration issues from classic editing workflows to block-editor workflows.

Audit a support policy

Before changing a plugin’s minimum supported WordPress version, test the versions near the proposed cutoff. Does the plugin still activate? Does the settings screen load? Does the admin flow produce fatal errors?

Playground will not answer every support question, but it gives you a quick first pass that is much more concrete than guessing.

Teach WordPress evolution

For educators and contributors onboarding new people, being able to open WordPress 1.x, 2.x, 3.x, 4.x, and modern WordPress side by side is valuable. It makes the project’s evolution tangible: admin navigation, writing flows, media handling, plugin screens, and editor behavior all become visible.

Limits and expectations

Legacy support in Playground is a compatibility and exploration tool. It does not make old WordPress or old PHP versions suitable for production.

Expect a few boundaries:

• Old WordPress versions may still expose historical bugs, missing APIs, and outdated assumptions.
• Plugin and theme code written for modern WordPress may not run on older PHP syntax or older WordPress APIs.
• Browser-based compatibility is not identical to every historical hosting environment.
• The goal is to make old versions boot and behave usefully enough for testing, inspection, education, and preservation.

That boundary is important. Playground gives contributors a controlled lab, not a recommendation to keep obsolete stacks alive in production.

A broader Playground story

This update fits a broader direction for Playground. The project is moving from “run WordPress in the browser” toward “make WordPress environments portable, inspectable, and automatable.”

Running legacy versions is part of that story. It means Playground can help with current development, future compatibility, and historical understanding. A contributor can open the latest WordPress release, switch to an old classic release, compare behavior, and learn from both without leaving the browser.

For a project with more than two decades of history, that is a meaningful shift.

References

These recent upstream changes provide the technical foundation for this post:

• PHP 5.2 WebAssembly runtime support
• Legacy WordPress support in Playground
• TinyMCE compatibility fix for legacy editor boot

Props to @janjakes for reviewing the post.