What is your idea about?
Let’s eliminate one of the biggest entry barriers for people wanting to experience TYPO3 for the first time!
It’s about helping both editors/users wanting to explore TYPO3 UI, or tech-savvy people playing with TYPO3 capabilities or customizations.
No more fiddling with Docker, Ddev, WSL, console, webserver, database, Virtualization disabled in BIOS…. when you just want to try TYPO3, showcase a theme or an extension or perform a training.
The idea is to research and create a browser-based TYPO3 environment, enabling users to explore and interact with TYPO3 directly in their browser without requiring local installation or server configuration.
It will lower the entry barrier into the system, providing zero-setup TYPO3 experience for new users, editors, and developers.
This can be achieved using two potential technologies:
WebAssembly: Emulating a PHP server and database within the browser to run TYPO3. This solution is inspired by the WordPress Playground (https://playground.wordpress.net/)
GitPod: A pre-configured cloud-based development environment for TYPO3 accessible via the browser
What do you want to achieve by the end of Q1 2025?
Proof of concept:
A working prototype of TYPO3 running in a browser using WebAssembly or GitPod.
Demonstration of core TYPO3 features (e.g., backend login, editing content elements, and saving changes) within the browser.
Technical documentation and results of research:
Detailed comparison of WebAssembly vs. GitPod for this use case, highlighting performance, scalability, and limitations.
Documented workflow for launching and running TYPO3 in the browser.
What is the potential impact of your idea for the overall goal?
For TYPO3 adoption:
Lower entry barrier: Simplifies the process for new users to try TYPO3, eliminating the need for local installations and complex setups.
Hands-On demonstrations: Facilitates instant, hands-on demonstrations for end clients
For editors and trainers:
Effortless training environment: Trainers can conduct TYPO3 workshops directly in the browser, reducing setup time and ensuring a consistent experience for all participants.
Immediate access for editors: Editors can experiment with TYPO3 features in a sandbox environment without risk to live systems.
For developers and contributors:
Patch testing simplified: Developers and contributors can test gerrit patches in an isolated, pre-configured browser-based TYPO3 instance, speeding up the review and feedback process.
Strategic advantages:
Competition: Positions TYPO3 alongside other CMS platforms like WordPress or Drupal, offering similar convenience for users.
Community growth: Attracts new contributors and editors by providing a hassle-free way to explore and engage with TYPO3.
Which budget do you need for your idea?
10.000 Euro
Please note: After the start of the voting we can not change the idea description nor the idea outcome. If this idea is selected by the members, it must be archived as described.
I would prefer a GitPod version being the priority in this project. The inclusion of development tools will make onboarding of new developers much easier and enable new contributors to fix bugs without installing a local system.
Drupal is already using this for their contribution onboarding. It is based on DDEV, which would be my recommendation here too. I have seen it in use and it works very well!
Jochen from b13 also worked in the past on some Gitpod + Gerrit Patch Review/Work system along with a browser plugin … not sure about all the links and current working state, but at least I would advise to get in touch with all the preparation work and experience he gained their and to share that:
Beside original doing something I would like to learn about “long term” maintenance of that … These things tends to be one time build and than not maintained over time.
Could not find slides, but as far as I remember Jochen also did talks/sessions about that.
I’m personally fine with having a demo installation at demo.typo3.org. Why would i need a local installation when an online demo installation would also allow me to play with TYPO3? Sorry if I don’t get the point.
I guess I would just like to hear whether this idea would sit alongside the demo (as-in, siblings?), or replace it, or something else? Do they serve two different purposes? If so, I think this should be clearly articulated.
@edwardlenssen1 i like the idea. It would be great for onboarding new devs.
For just having a look at the Backend and it’s features demo.typo3.org is sufficient imo.
I’d say the GitPod part is mostly working. It needs some cleanup and v13 needs to work.
With the VSCode command palette (command + p) Open in VS Code one can work with the local VS Code installation
Pick a PHP Version - 8.1 - 8.4
MailPit MailCatcher
All in all, you get a “ready to develop” TYPO3 instance.
My idea with this was to enable people to review Patches from Gerrit with a single click.
This is possible using the Browser Add-on and GitPod - GitPod uses the TDK to install main branch or any git tag to install TYPO3. Only v12 seems to work and i thing it makes only sense to support v12 and up.
Happy to collaborate to move the GitPod part forward.
Granted, if you’re a non-technical person who only wants to test a standard TYPO3 installation, demo.typo3.org is sufficient. However, it resets after 30 minutes and if you want to go any further, like play around with configuration or code, you’re on your own with today’s availability.
Especially for more technical (or wannabe technical) testers of TYPO3, setting up a local installation is tedious, especially if you use Windows and especially if you don’t have Docker and DDEV installed already.
In my work for the Community Expansion Committee I have first-hand experience of how very time-consuming it can be for inexperienced people with minimal command-line know-how to do this.
demo.typo3.org is nice for some purposes but it has strong limits at the same time.
it reset after 30min, so you can’t use it for proof of concept - doing some work and presenting it later to somebody else, or just continue to play yourself over longer period of time
it shows TYPO3 v12 LTS. You can’t play with sprint releases nor with v13 LTS, so it doesn’t help with sppeding up adoption of new TYPO3 versions.
it doesn’t help with training, workshops or onboarding
it doesn’t help with contribution workflow
it doesn’t allow to play with themes, extensions or more advanced settings
The gitpod is a interesting and useful technology and it has to be considered, the problem is that its comercial and you have to register with 3rd party to use it. The work from Johen around gitpod is really great starting point!
Indeed. I’m unsure if we can always get away from commercial and third-party registration. But in this case, it’s more like an opt-in hosting platform and it’s not a requirement for anyone to do it. TYPO3 can always choose to stop using it too.
If this is also an opportunity for newcomers to get to know TYPO3, it would also be interesting to have a concept how to promote it. For demo.typo3.org there is a link in the main nav. Would there be also a link in the main nav for gitpod? If nobody finds it easily, how will you know it exists?
I wonder how the long term sustainability would look like. How much work is needed to make this solution fit for the next major TYPO3 version? 10K is a lot of money and with DDEV I have a trusted solution where I’m very confident that it will also exist in 5 years. Nevertheless I get the point that the proposed solution has a different and less technical approach.
My experience with webassembly in browser is not good either. The Drupal Community has been experimenting with this exact same approach, but the time required to download and set up is quite harsh. It looks like they’ve given up on that approach: https://mglaman.dev/blog/web-apis-powering-drupal-cms-trial-experience
DDEV is a great local development environment for professionals. But it solves a different problem than this initiative. DDEV is not helpful in lowering the entry barrier for people wanting to try TYPO3. You still need to get docker and other dependencies steight before. Especially on Windows, its a really painful to install and easy to make a mistake.
We’ve conducted plenty of trainings for TYPO3 developers using ddev as a base, and always there were some issues with getting local envs ready for some people (and it was not ddev itsefl fault).
the question about further maintainace is a valid question, and it needs to be answered within the budget initiative.
the goal of this initiative is not to reinvent a wheel and redo what others have already done, but to analyze what is there, test it, build poc and recommend a best way forward for the TYPO3
I’ve tried the drupal wasm, and it took ~5min to initialize it in the browser, so it’s not ideal, but still fast enough. It would be interesting to see what Wordpress have done differently to succeed with their WASM project as its working very fine.
reading the article shared by Randy, I don’t see the information there