Why host your TYPO3 website with Platform.sh: Part 1, Git and the Read Only file system

TYPO3 is one of the most powerful Open Source Content Management Systems, but it can only thrive if you leave it room to fully operate. The same can be said for Neos and the Flow Framework, two, now independent projects that were once created and managed by the TYPO3 community.

As a long-time TYPO3 contributor, and someone that recently joined the Platform.sh’s team, I am going to try to give you some tips and best practices via this series so your TYPO3 journey on Platform.sh is enjoyable and productive. (And by the end I hope I will have convinced you that the TYPO3 association made a good decision by choosing Platform.sh as one of their hosting partners!)

A Git/composer hosting platform

The core philosophy of Platform.sh’s platform is that code isn’t meant to be uploaded. It’s meant to be deployed and compiled.

Instead of manually uploading your core files, you manage them via Git, and prepare the rest of your code with composer.

How does that work at Platform.sh?

When you create a new Platform.sh project, one of the available templates is TYPO3 which will install the most recently integrated TYPO3 version, usually in less than a minute.

You will then have a fully working TYPO3 installation, with your database created, linked and all of the basic requirements fulfilled.

With Platform.sh, you will get a fully powered and functional TYPO3 instance.... and  the TYPO3 install will complain with some  errors.... saying  typo3conf and typo3temp are not writable.

Should you worry? No, not at all: that's actually good thing!

That’s because at Platform.sh, our disk-space is read-only. The default way TYPO3 is installed is already secure but we still hardened it beyond the expectations of the TYPO3 install tool. It expects to have read-write access to these folders and that is really not necessary.

When a TYPO3 installed at Platform.sh, everything is already configured properly: when you run in production, none of the TYPO3 source code will ever be compromised during execution at Platform.sh. That's why code that is read-only is a good thing.

But how will we upload files?

Don’t worry! It is possible to mount a writable folder within your site, which will not only be writable by TYPO3, but which will also persist from container to container as you branch (more on that in later articles).

When you use our TYPO3 one-click easy installation, the following folders (and their subfolders) are writable by default:

• typo3temp/assets
• typo3temp/var
• uploads
• fileadmin
• typo3conf/writeable
• typo3conf/l10n

This means that your fileadmin and your uploads folder (which typically should not contain code) will still be fully editable and that TYPO3 will still be able to write temporary files and update its localization settings on the fly.

So how can TYPO3 update its configuration during execution?

Ok, this one is a little more complicated: TYPO3 should have never been able to modify its own configuration in the first place!

TYPO3 was first created in 1998 and a lot of the settings that are stored in its configuration file (now called LocalConfiguration.php) should in reality have been stored in the TYPO3 database like more modern CMS do. But don't think TYPO3 is outdated just for that fact! It simply uses an older method for storing its settings.

This sadly makes TYPO3, in theory, less secure than other CMS with a fixed read-only config file. The worst is that once the site is fully deployed and working, the config file is rarely modified, so what should we do?

Don't worry! I'll teach you right now how to keep the flexibility of having a writable config file in a Cloud-Friendly instance (such as Platform.sh) until you are 100% happy with your deployment, and then, and how to completely secure your config file.

Initially, when you use the Platform.sh TYPO3 installer, a special task is added during the build process in your .platform.app.yaml file: a symbolic link from typo3conf/LocalConfiguration.php to typo3conf/writeable/LocalConfiguration.php will be automatically created. The same is done for typo3conf/ENABLE_INSTALL_TOOL.

You can see in the .platform.app.yaml file the way it is done, in the build: step:

if [ ! -f web/typo3conf/writeable/LocalConfiguration.php ]; then
cd web
touch FIRST_INSTALL
cd typo3conf ln -sf writeable/LocalConfiguration.php LocalConfiguration.php
ln -sf writeable/ENABLE_INSTALL_TOOL ENABLE_INSTALL_TOOL 
fi; 

That way, those two actual files exist within a writable mount and will be editable by TYPO3 itself, even if TYPO3 accesses them from within a read-only folder.

We had to move them in a subdirectory, because mounting a directory also mounts all of its sub-directories and this would mount the ext subdirectory as writable, defeating the purpose of a read-only file system.

From that moment on, you will be able to edit the LocalConfiguration.php file from within the TYPO3 Install Tool as often as you wish!

As soon you are you fully satisfied with your installation however, you'll be able to remove the above build commands that create the symlinks and add your LocalConfiguration.php file in your git repository to have a fully read-only and 100% secure TYPO3.

Why even have a read-only filesystem?

You’ll hear on our website all of the advantages of having a read-only filesystem (including increased security, protection against hackers, etc… ), but the number one advantage is even simpler: it mandates the use of Git (and optionally Composer) for code deployment.

It enforces good coding practices not just for you, but also for your collaborators and your client if you are an agency.

You will still be able to easily work on your local computer to develop your extensions, simply syncing them via Git to your website instead of using a regular file transfer protocol (FTP or SCP, for example).

This will not only enable you to easily work on your TYPO3 website, but you will also have the advantage of a code base that is fully tracked by Git with no possibility of having any untracked files!

What about installing extensions?

TYPO3 now supports optionally replacing the Extension repository with Composer and that’s the mode used at Platform.sh.

You will be able to easily add extensions using composer as you would on any other TYPO3 setups. For example:

You can easily run it manually in your local CLI from Platform.sh. Here is how you would do it:

platform get <project id> -e <branch name>
composer require typo3-ter/[extension name]
git add composer.*
git commit
git push 

In short, we select which project we want to use and check it out to allow editing. We are then ready to run any Composer command we need!

Once we are done, we add the Composer files to Git. If you are not familiar with Git, add doesn’t just mean adding new files to Git, as if they were new files, it also means “adding” the local files from your hard disk to the staging area where Git actually tracks changes.

The git commit will store in your local git repository the files added to your staging area (you will be asked to provide a comment, such as “Added the news extension via composer”), and the git push command will upload your changes to the Platform.sh servers where we will deploy your updates within a few seconds of the push, automatically.

With a single-click install, full Git (and Composer) support and an easy to use command line interface, Platform.sh really gives you all of the tools you need to fully manage your TYPO3 installation in a secure and fully versioned way.

In the next installment: Branching and Workspaces, discover the full coolness.