DEV Community: Sebastian Michaelsen

Bashing TYPO3 🔥

Sebastian Michaelsen — Tue, 09 Oct 2018 10:58:08 +0000

Since more than 10 years I've been using TYPO3 CMS to create websites, I'm an active community member, I've published extensions, I've contributed to the TYPO3 core and popular extensions.

As a TYPO3 guy I can't understand why it is not the world's most used and loved CMS. 😉

So I challenge you to bash TYPO3 as good as you can. For me it doesn't matter if you have just heard rumors about how bad TYPO3 is or if you have actually worked with it. If you have hard feelings about my favorite CMS please share them with me in the comments.

Maybe I will try to defend TYPO3 against your criticism, I will definitely learn from it.

Fixing git commits - you always did it wrong

Sebastian Michaelsen — Fri, 10 Aug 2018 14:35:48 +0000

... unless you did it with --fixup and --autosquash

The most important thing first: Of course you never change commits in branches that you share with others like develop, master or whatever you call your "main" git branches. If you encounter an error there, just fix it with a new commit.

When you're working on a branch on your own like a feature branch or local branch there's a more elegant way to fix commits.

Take a look at the following git log:

8680a59d This is the 3rd commit
7e866455 This is the 2nd commit
a069e42a This is the 1st commit of my feature branch
0e2977b5 Previous commit that is already integrated in master

Imagine you want to fix an error in the 2nd commit.

Make the file changes to fix the problem and add the changes to the stage, e.g. with git add --all.

git commit --fixup 7e866455

Notice the commit hash 7e866455 is the one from the commit that contained the error. Now your git log looks something like this:

335ca372 fixup! This is the 2nd commit
8680a59d This is the 3rd commit
7e866455 This is the 2nd commit
a069e42a This is the 1st commit of my feature branch
0e2977b5 Previous commit that is already integrated in master

The new commit has the commit message from the 2nd commit, but prefixed with fixup!.

You can do this multiple times for the same or for different commits in your branch. When your branch is ready to be merged (or reviewed) you'll want to clean things up. Just run:

git rebase -i --autosquash 0e2977b5

The commit hash 0e2977b5 is the one your feature branch is based on ("previous commit").

This will apply your fixup commits directly to the commits they belong to and you will get a clean git log with all errors fixed.

26fe362d This is the 3rd commit
5db42a3d This is the 2nd commit
a069e42a This is the 1st commit of my feature branch
0e2977b5 Previous commit that is already integrated in master

✨✨✨

Running TYPO3 with Valet

Sebastian Michaelsen — Fri, 10 Aug 2018 09:48:20 +0000

This article describes my experiences with developing TYPO3 on a Mac. If you're working on another OS you may or may not find this article helpful.

There are a lot of ways to create a local dev environment for TYPO3 and all claim to be super easy and quick to set up - here's why Valet won me over.

I've been developing TYPO3 websites and extensions since > 12 years and I claim to have used or at least tried every possible dev setup that ever existed for TYPO3 (probably not entirely true - try me).

An option I used for quite some time was Vagrant boxes, which I configured with PuPHPet. After that other virtual machine based solutions followed, including docker and ddev. What I dislike about running my TYPO3 environment in a container is the command line access. Yes - all of those solutions allow you to ssh into the container and do what ever you like. But I didn't want that. I wanted to run composer install on my local machine and flush the TYPO3 cache or setup extensions via composer scripts - for example. I was always having headaches with this stuff.

Then I learned about how to install, maintain and run PHP in multiple versions and MySQL with homebrew and realized that I didn't necessarily need Apache or nginx for TYPO3 but the built-in PHP server works fine for most use cases.

But the built-in server has one major limitation. It can only handle one request at a time, which has at least two negative consequences:

Loading a page with many assets and AJAX requests (like the TYPO3 backend) took its time because the requests were not processed simultaneously.
Sometimes parallel requests are necessary, for example when you try to index page content for solr in the TYPO3 backend - that backend requests makes a request to the TYPO3 frontend, which stalls because there's already an active backend request (I eventually found a workaround for this).

After ignoring 2 or 3 hints, this week I finally tried Valet and was immediatelly sold when I learned that it worked with the brew PHP / MySQL that I already had. The benefits it brings is an nginx server which works surprisingly well without any configuration at all. You just tell Valet a projects root folder and it takes care of creating vHosts for your projects. ~/projects/acme/ automagically becomes available as http://acme.test. Zero config per project required. The TLD .test can be reconfigured if you prefer something else. Bottom line: It took me minutes to get Valet installed and my current project running with it.

It comes with drivers to detect and run many PHP frameworks and systems including TYPO3. Only caveat: It assumes that the document root folder in your TYPO3 project is called web. This is not the case in all of my projects. My more recent ones use public. I was able to quickly solve that by placing this custom driver at ~/.valet/Drivers/Typo3PublicFolderValetDriver.php:

<?php

class Typo3PublicFolderValetDriver extends Typo3ValetDriver
{
    protected $documentRoot = '/public';
}

Thanks to @dakira for giving me the crucial nudge on twitter.