• Overview
    • Django
    • Next.js
    • Drupal
    • WordPress
    • Symfony
    • Magento
    • See all frameworks
    • Observability
    • Auto-scaling
    • Marketing Teams
    • Retail
    • Higher Education
  • Pricing
  • Featured articles
    • Switching to Platform.sh can help IT/DevOps organizations drive 219% ROI
    • Organizations, the ultimate way to manage your users and projects
  • Support
  • Docs
  • Contact
  • Login
  • Free Trial

Hosting your TYPO3 website with Platform.sh: Part 2 Branching and Workspaces

July 21, 2017

In the first article in this TYPO3 series, I explained that when you host TYPO3 at Platform.sh, it is hosted on a read-only file system which will both be more secure and which will ensure a good development workflow.

Today, you’ll learn how to use Platform.sh's branching with the TYPO3 workspaces so that you can easily develop a new version of your website without breaking your live site or losing data.

Branching with Platform.sh

One of the best features of Platform.sh is the ability to branch any environment within seconds, and use the new branch as a development server which can be merged back to the live site just a fast as it was initially created.

If you are building a custom extension for a TYPO3 site and discover that you need to edit the controller of one of your plugins, you can easily branch the whole website in a few seconds with a custom label describing exactly what you are doing. This branching includes complete copies of all of the data, including the database, uploaded files, and any extra services that you use, like Solr or Redis.

If there are multiple developers working on your project, or if you are working on more than one feature or bugfix in parallel, you can create multiple branches (full copies of the website, each with their own URL) for each case. Once you fix an issue or complete a feature, Platform.sh supports your testing and integration workflow, after which you can merge your changes back into the live site with minimal risk of incurring downtime or causing corruption on the live site.

These development branches also help you when you're working in your local development branch (ie your laptop). Each branch in the cloud has its own copy of all the site's data, and you can connect to these data sources from your laptop with tunnels, meaning you don't have to export, download, and import the database every time you switch contexts. Just switch tunnels. And, it's easy with the Platform CLI tool... it's literally a one-line command.

Of course, your branch database and files will slowly fall out of sync as your branch gets older, but with single push of the Synchronise button, you can easily refresh your branch to the latest database!

Platform.sh has your back...

Workspaces with TYPO3

For over 12 years, TYPO3 has been supporting workspaces with greater and greater assurance to the point where a few years ago, they became almost bullet-proof.

You can easily create a new workspace in TYPO3 allowing you to seemingly work in a separate version of your website which is only accessible from a workspace preview link.

Create new content, new pages and modify existing articles: nothing will change in the live site if you are working in a workspace.

Ever since the DAM  (Digital Asset Management) was released (and later the superior FAL – File Abstraction Layer which replaced it), even files were properly tracked when working with Workspaces so that your user files would be properly maintained in the live site even if you were preparing brand new ones in a draft workspace.

Granted, some custom-made TYPO3 extensions do not fully support workspaces, but they are getting rarer and it is easy for a developer to add workspace support, even to a third-party extension.

TYPO3 Workspaces and Platform.sh Branches: made for each other?

Platform.sh has a concept of data flowing down from the live site to the development branches, and code merging up from feature and development branches into the live site. There is no support for merging the actual data from a development branch into a live site. All of the changes that move from development into the live site need to be expressed in the Git repository. We consider this to be modern best practice web development.

TYPO3 Workspaces are also amazing, but they only work on your database records and their associated file: each of the workspaces can have different content but all share the same source code.

Do you see now how both systems complement each other?

All you need to remember is:

  1. Work on your source code in your development branch
  2. Work on your database records and their associated records (like product or news images) in a workspace, on the live site
  3. Sync your live database and files down into development and feature branches, thus inheriting the live sites workspaces
  4. Merge code changes up from feature branches into the live site

You will thus be able to easily prepare an updated version of your website with new content, new extensions, new images while keeping your live site untouched.

When it will be time to go live, you’ll be able to do so in two easy steps together taking about a minute:

  1. Merge your branch in your Platform.sh control panel. This will update your source code.
  2. Merge your workspace in your TYPO3 back-end (or change the active Workspace)

This workflow is recommended only when your code is not changing the database schema at the same time. Changes that trigger database schema updates should be rolled out separately and independently from workspace updates.

What about your templates?

Most TYPO3 integrators place the website templates in the /fileadmin/templates directory out of habit. Since that directory is within the writable mounts, it means that the directory is synced between the branches, but can't be merged back to the live site, so any improvements wouldn't be easy to deploy.

But honestly, why would you want to keep your templates in a writable mount?

The actual location of your website template files is arbitrary and often only placed in /fileadmin/templates because that’s where the now obsolete TemplaVoilà was looking for its templates and the integrators are just used to using it.

A better solution is to place your templates within the read-only space that is managed by Git, for example, in /templates, so that not only will any changes be tracked by Git and protected from accidental changes, but you will be able to easily have different versions of your templates depending on which Platform.sh branch you are working on. Templates are code, after all.

So, whether you are a TYPO3 developer frustrated by the fact that you can’t have different extension source code depending on which workspace you are working on, or if you are a Platform.sh client wanting to work on databases records on development branches, you will find that combining the two will solve all of these problems.

Even better, in both cases, Branches and Workspace both start as identical copies of their parent and only track actual changes, keeping the differences with the live site as the only data to keep and the time to merge and deploy to its minimum.

A TYPO3 website hosted at Platform.sh is a little like a high-powered motorcycle: Platform.sh drives the back wheel with raw power, while the TYPO3 workspaces provide the steering with the front wheel.

This is the second article in the TYPO3 at Platform.sh series. Next time: Caching, more Caching, and how your site can fly!

Get the latest Platform.sh news and resources

Related Content

Infrastructure metrics expanded to longer time frames

Infrastructure metrics expanded to longer time frames

AboutSecurity and complianceTrust CenterBoard and investorsCareersPressContact us
Leader Winter 2023
System StatusPrivacyTerms of ServiceImpressumWCAG ComplianceManage your cookie preferencesReport a security issue
© 2023 Platform.sh. All rights reserved.
Supported by Horizon 2020's SME Instrument - European Commission 🇪🇺