Professional Content Management

Free and open source, TYPO3 CMS is the most widely used enterprise-level CMS.

Test TYPO3 now:

TYPO3 live demo

Inspire people to share

Offer your skills and contribute to the project. The community is growing and does more than just coding. 

A Community Effort

TYPO3 CMS is an Open Source project managed by the TYPO3 Association.

The Project

Do you have a question?

Ask the community or a professional partner.

Budget Idea Report: One-Click TYPO3 Playground

Categories: Budget idea Created by Łukasz Uznański
A split-screen shows a TYPO3 CMS setup interface on the left, with version and language options, and the TYPO3 CMS homepage on the right, featuring the text TYPO3 - Open source, enterprise CMS.
Łukasz Uznański shares the journey behind the technical achievement to implement a working proof-of-concept for TYPO3 running entirely in the browser — no installation, no Docker, no hosting setup required.

The TYPO3 Community Budget Ideas initiative selected the project One-Click TYPO3 Playground for Q1/2025. This solution lowers the barrier to entry for new users, simplifies contributor onboarding, and opens new possibilities for training and demos.

Here we include a high-level summary of the work, milestones, and next steps. Following that is the full report, which provides a detailed breakdown of the research, implementation, and challenges along the way.

Summary

What We Built

A browser-based environment where TYPO3 v13.4 runs entirely via WebAssembly, without external servers or installations. It includes backend and frontend functionality, supports extension installation, and saves application state in the browser.

Try it Now: Playground Live Demo

Why it Matters

This solution directly responds to long-standing pain points raised by the TYPO3 community — especially for developers, trainers, and contributors. Unlike demo.typo3.org, which resets after 30 minutes, this new playground allows persistent sessions, real editing, and deeper exploration of TYPO3 features.

It opens up new possibilities for:

  • Running TYPO3 demos for clients entirely in the browser
  • Editing and testing extensions without a local setup
  • Onboarding new users in training sessions with zero configuration
  • Reviewing patches or prototyping content safely in a disposable sandbox.

By removing the friction of installation and setup, the project helps make TYPO3 more accessible, discoverable, and developer-friendly.

Key Milestones

What’s Next

Plans include frontend performance optimization, support for multiple TYPO3 versions, integration with Gerrit for patch reviews, and eventually, blueprints for launching custom TYPO3 setups instantly.

Try it now

Full Report

1. Initial Motivation and Research

Initially, we considered solutions like GitPod, which already provides existing applications for in-browser development. However, we wanted to try an alternative approach — one successfully used by WordPress: compiling a PHP-based application to WebAssembly to run entirely in the browser. This offered the potential for high performance, full open source control, and no reliance on third-party hosting and services. All that is needed is a modern web browser, which we viewed as an essential advantage.

We began with general research into existing solutions:

  • php-wasm includes demos of popular CMSs, showing it is possible to run large PHP applications in WebAssembly.
  • We also tested a Drupal WASM demo, but its performance and stability did not meet our standards.
  • We then noticed WordPress Playground, which is stable, can save states, switch environments, and does not crash. Given it was already deployed successfully, we felt it was an innovative, open source option worth exploring in the TYPO3 ecosystem.
  • We also checked whether GitPod would be a better fit for this use case. You can look into our findings in the Google Doc WebAssembly vs. GitPod.

2. Early Attempts With Php-wasm

We initially forked php-wasm because it demonstrated multiple CMS frameworks (e.g., CakePHP, CodeIgniter, Drupal, Laravel).

Our approach involved:

  • Sending a bundled (non-Composer) version of TYPO3 as a ZIP file to the browser.
  • Using the built-in shared storage for the filesystem.
  • Incorporating PostgreSQL (in the form of pglite) into WASM.

While we successfully extracted TYPO3 and connected to the database, the frontend displayed a blank screen. The Install Tool only partially loaded, likely because static files were not being fetched correctly. After multiple fixes and discussions (including with Tymoteusz Motylewski), we concluded this approach posed numerous problems. We then decided to switch to WordPress Playground — though it appeared more complex, it promised to solve more issues out of the box.

3. Transition to WordPress Playground

Upon further research, we discovered that WordPress Playground has thorough documentation and a series of blog posts by its author, Adam Zieliński. It is based on a php-wasm fork but adds extra methods and compiled modules and provides solutions for multiple problems.

For instance:

  • They solved issues with service-worker and switching application URLs (they built it based on iframes).
  • They built a whole layer as a solution for external networking
  • There is a Dockerfile to build PHP versions for WASM with Emscripten, leaving room to add custom PHP extensions — which we did.

For more information, please take a look at the documentation.

We decided to adapt this architecture to TYPO3. We noticed that WordPress Playground uses SQLite, so we switched TYPO3 to SQLite accordingly. Once we zipped TYPO3 for the browser, we encountered an error regarding the missing php-intl extension, not included by default in Playground modules. Oskar Dydo compiled php-intl with Emscripten, submitting a pull request (#2173) to the WordPress Playground repository. This was a major step — after that, TYPO3 no longer crashed and instead displayed its 404 page, signifying real progress.

4. Handling Browser Scopes and Static Assets

WordPress Playground applies a unique browser scope appended to each request URI. (Details can be found in the browser scopes documentation.) Because each instance in the browser receives its own scope, we had to modify TYPO3’s site configuration so it would handle these scoped URLs. Without the scope in place, CSS, JavaScript, and other static assets failed to load, causing partial or completely blank pages. After injecting the scope properly, the frontend rendered as expected.

Screenshot of a TYPO3 CMS setup page showing settings for TYPO3 and PHP versions, language choice, and options to create an admin user or multisite network, with a preview of the TYPO3 welcome page on the right.

5. Backend Fixes: Bypassing Login and Overriding Top References

To confirm that the backend was functional, we initially bypassed TYPO3 authentication. Once inside, we discovered that direct references to top inside iframes caused conflicts because our setup uses multiple iframes. To resolve this, we patched these references in TYPO3’s JavaScript. Rather than referring directly to top, we created a dedicated object at the backend rendering level (for example, within the BackendController or a similar component) and modified the code to reference that object. This ensures that the correct context is used, preventing conflicts with iframe boundaries.

Similarly, certain modules — such as Filelist and the Install Tool — assumed direct access to the top-level browser window. We applied similar overrides to these modules. After these fixes, the backend stabilized sufficiently to allow page creation and made the TYPO3 backend generally usable.

Screenshot of TYPO3's About TYPO3 moduel in dark mode, showing the left navigation menu and “Getting Started with TYPO3” tutorial box on the main workspace.

6. Implementing a Storage-Based Log Viewer

We were looking for a way to view logs in the application, so we introduced a storage-based log viewer accessible via Filelist. It provides a way to view errors and debug messages from within the browser’s filesystem. This was particularly helpful for diagnosing missing asset references or scope injection issues, confirming that the relevant patches worked as intended.

A dark-themed TYPO3 backend displays a the file management module with a sidebar menu on the left, a search bar, and two log files shown in the main panel labeled as log. Tabs and folders are visible.

7. Testing Extension Installation and CORS Proxy

One core requirement was easy installation of TYPO3 extensions without a local environment. Initially, we faced problems downloading packages directly from the web. We realized that, similar to WordPress Playground, a CORS proxy was needed to enable network access from the browser. We deployed one (inspired by WordPress Playground issue #85), allowing us to fetch extensions from the TYPO3 Extension Repository (TER) seamlessly in the browser.

A dark-themed TYPO3 backend displays the Extensions module, listing extensions with details such as name, version, key, last updated date, manual status, and stability. The sidebar shows navigation icons for different sections.

8. Optimization and Consultation With WordPress Playground Creator

During our development process, we held a call with Adam Zieliński, the creator of WordPress Playground, to review challenges and explore improvements for our TYPO3 WebAssembly project. We discussed several key points:

  1. Image rendering: We started exploring the idea of using ImageMagick compiled to WASM, which should normally be able to handle exec() calls. Adam explained a method to intercept these exec() calls within the WASM environment. Unfortunately, we were unable to fully implement this approach. As a result, we now have two potential strategies to address image processing: one, by intercepting exec() calls as Adam suggested, and two, using VRZNO as an alternative solution.
  2. Preserving application state (scope) across sessions: A major challenge was keeping the unique browser scope intact. Adam provided useful ideas on how to save and restore the application’s state, so users can keep their session data even after closing or refreshing the browser.
  3. Reducing the initial ZIP size: We reviewed ways to reduce the size of the initial ZIP bundle (which is over 100 MB). Options include splitting static assets from the main code or offering a minimal TYPO3 variant. A smaller ZIP would improve the first-page load time and overall user experience.
  4. Debugging PHP in WASM: Although we briefly considered integrating Sentry for profiling and debugging, adding such tools requires extra profiling modules. Adam shared some basic debugging strategies for PHP in a WASM context, which will help us improve our approach in future updates.

Adam’s insights on reducing build size, enabling networking for extensions, and preserving the current scope were valuable in helping us achieve a working proof of concept. His guidance has helped shape our plans for further optimization and stability improvements.

9. Possible Usages

  • Fully functional TYPO3 backend in the browser: All core features like creating pages, editing content, and managing users work reliably.
  • Extension management on the fly: Install extensions directly from TER inside the browser — for QA, experimentation, or demos — without setting up a dev environment.
  • Client demos & live previews: Share a running TYPO3 instance with clients via a link. Everything runs locally in the browser, making it perfect for showcasing features or custom solutions.
  • Persistent application state (scope saving): Save and restore the entire TYPO3 environment state — including content and settings — between sessions, directly from the browser.
  • Safe and disposable sandbox: Test, break, or explore without fear — just reload to reset the instance to its original state.
  • Content editing & prototyping: Edit real TYPO3 content in a self-contained instance and optionally sync or export results to staging or production.
  • PHP version switching: If multiple PHP versions are compiled, users can toggle between them to test compatibility.

10. Known Issues

Large Initial ZIP Size (~100 MB)

The current package includes the full TYPO3 core, Introduction Package, extensions, and an SQLite database. We are exploring:

  • Providing a minimal clean install option, letting users install extra packages manually.
  • Splitting static assets to allow quicker page rendering with lazy loading.
  • Further ZIP optimization strategies, e.g., stripping unused files.

Frontend Performance

While the backend is fast (close to native speed), the frontend may feel sluggish in larger setups. Improvements may include:

  • Using minimal templates or disabling non-essential frontend features.
  • WebAssembly profiling with Emscripten tools.
  • Reducing extension and JS overhead in the frontend.

Image Processing

PHP’s exec("convert") for ImageMagick is currently not functional in WASM. Workarounds in progress:

  • Compiling ImageMagick to WASM and intercepting exec() calls.
  • Offloading image transformations to a remote microservice.
  • Exploring in-browser JS wrappers like VRZNO to bridge this gap.

PHP and Code Adjustments

There are minor changes to the TYPO3 code that require additional work. For example, adapting PHP for TYPO3 meant modifying certain functions like mktime to overcome 32-bit time limitations, and removing or adjusting some environment checks that were causing the instance to crash. Additionally, during our image generation tests, we encountered PHP errors that suggest the GD module may not be functioning correctly. These modifications are necessary to ensure compatibility across all TYPO3 versions.

11. What’s next?

  • Frontend performance debugging: We aim to apply profiling and performance tooling to ensure both backend and frontend are optimized for speed.
  • WASM-compatible ImageMagick: Finalize a reliable WASM-based image manipulation solution for TYPO3’s image-handling features.
  • Browser-based IDE support: Embed a lightweight code editor (e.g., browser VS Code) for real-time file and extension editing inside the Playground.
  • Gerrit integration for one-click patch reviews: Similar to WordPress Playground, enabling reviewers to spin up a demo instance from a patch link.
  • Multiple TYPO3 versions: Offer users a choice between different TYPO3 versions (e.g., 12.x, 13.x) by bundling precompiled builds and toggling overlays.
  • Commit to any repository: Directly push changes from the Playground environment.
  • Multiple TYPO3 versions: that point requires doublecheck on overwrites that we are doing to javascript and PHP, but if we want to support another version, it’s rather straightforward
  • Blueprints: WordPress Playground includes a feature called Blueprints, a set of instructions for assembling an instance with specific extensions or configurations. We envision a similar approach for TYPO3, letting users define a blueprint (e.g., “install these extensions” and “set up site X”). More details on WordPress Playground Blueprints.

Conclusion

At this point, we have a stable TYPO3 WASM instance running in the browser. We've successfully delivered a working proof-of-concept for running TYPO3 v13.4 entirely in the browser — without any additional infrastracture — by extending and adapting the foundation laid by WordPress Playground. Our research showed that it is possible to develop a working solution, as WordPress Playground did.

This browser-based environment provides a fully functional TYPO3 backend and frontend that operates within a sandboxed WebAssembly context. Key backend features such as page creation, content management, and extension installation are all supported. The environment is isolated, secure, and requires no installation or setup, making it ideal for demos, extension testing, and onboarding.

The project has two key repositories:

  1. A TYPO3 Playground containing the adapted Wordpress Playground code.
  2. A TYPO3 Backend ZIP that packages the full CMS into a ZIP and provides changes required to work in browser installation.

You can find them here:

Additional contributors for this article

Related News

Latest news

Show more