TYPO3Camp Central Germany: Concourse CI, Automated Testing, Static File Cache and many more

While we presented our community-praised TYPO3 extension nr_sync in the first part of our review on TYPO3Camp Central Germany, we now want to address my talk on the subject of deployment with Concourse CI.

In addition, I was able to take away a lot from the lectures of the other participants, which I'd like to share with you.

Netresearch lecture: Concourse CI

In my lecture I discussed the advantages of the Continuous Integration Tool Concourse CI and showed in a live demo how to start and extend Concourse.

Overview Continuous Integration

The market for Continuous Integration systems is growing all the time. Jenkins used to lead the market, but now there's a diverse range. You can choose between SaaS providers such as CircleCI, Travis, GitHub, GitLab and many more, and if you want to run the build process on your own infrastructure, there is also a wide range of offers from the open-source world.

Advantages of Concourse CI

Concourse CI can be started on your own server. The advantages of Concourse CI over other solutions are:

• Easy scalability through Docker
• Easy to extend
• Can listen to various data sources, like Git repositories, to trigger a build
• Can listen to various types of sources, like Docker registries, versions control systems (Git,svn,mercury), or other sources like MQTT, e-mail or Slack messages

Run Concourse on your own machine

I've started a small example project so you can start Concourse on your own machine: https://github.com/vergissberlin/t3cmd

The only requirement is to install Docker (takes 5 minutes).

Other interesting topics at the Barcamp

Automated Testing

Daniel Siepmann gave an insight into Unit Testing of TYPO3 controllers and models. For me the subject was interesting from two points of view. On the one hand, I haven't written PHP for a long time and will need it more often in the future; on the other hand, I often heard the argument "Unit tests only for relevant things, definitely no models and controllers".

1. In the best case, controllers only load functions from other classes and execute them. They themselves do not provide any functions that need to be tested.
2. Models are often generated automatically, e.g. with the Extension Builder or Apiman. Therefore testing is not necessary.

I asked Daniel (very nice guy) this question and he said it was a good start for every extension developer, because you definitely have a controller and a model. Furthermore, he was able to explain the principle of mocking using an example.

As a reminder, what are the purposes of tests?

1. Discover mistakes before anyone notices them.
2. You make sure that the same error does not occur a second time.
3. Errors can be reproduced with tests.
4. Speed up development.
5. Documents how to use the code.
6. A pull-request documents the acceptance criteria or how they were understood.
7. Write code without a working system. Instead use tests.
8. Tests enable safe refactoring.
9. Tests enforce writing clean code.

In any case, the presentation gave me the impetus to write Unit Tests for the upcoming TYPO3 plugins for the current project in order to write down the acceptance criteria.

HMENU is bad

TYPO3 is very popular in the enterprise field in Germany. At universities, hospitals, institutions and federal states and communities, web projects with more than 18,000 pages are implemented. Mapping these in a menu is not an easy challenge. Often this ends up in a mega menu with many levels and menu items. What should be bad about my HMENU? The problem: Because of the active status, a separate cache has to be created for the menu for each page. This means that even a 64GB Redis cache fills itself within minutes. It is interesting to know that the v:menu Viewhelper also uses the HMENU under the hood.

Benni Mack, project lead of the content management system TYPO3, has put things right with his company b13. With its approach, MegaMenus no longer cause problems: https://github.com/b13/menus Whether this is also something for the TYPO3 Core remains to be seen.

Static File Cache

Static file page generators have been the hot shit (<2020) in the world of high-performance web applications for a few years now. Thanks to Tim Lochmüller and staticfilecache, a solution exists for TYPO3 since 2016. Tim told us which new features have been introduced:

• Gzip and Brotli file cache compressor
• Cache control header
• Cache tags
• HTTP2/Push for assets
• Fallback middleware

He then gave an outlook on future features. Client-side offline caches are to be used and a Fastly cache to be purged via the backend will be made possible.

What was new for me was that Tim is also the founder and maintainer of Sourceopt, a TYPO3 extension that removes unnecessary characters from the HTML documents and thus increases the speed. Hats off to Tim Lochmüller, the man with the black TYPO3 blog!

Semantic Data with TYPO3

In the enterprise field, semantic data are highly relevant. They help the search algorithms to understand the content. In order to semantically enrich your content, you add a JSONLD string to the HTML document, which adheres to the schema.org schemas. With the template engine Fluid of the TYPO3 Framework this is not always that easy to implement, because the template engine also uses curly brackets, in this case to output variable content. To solve this problem, the TYPO3 Extension Repository (TER for short) currently offers two extensions. Chris Müller presented his solution schema at the TYPO3Camp Mitteldeutschland.

What is particularly smart about his approach is that the extension offers a ViewHelper to which you can pass the necessary data. At Netresearch, we often work for the travel industry and I'm pretty sure that the extension will soon be used by us, because the tagging of semantic data gives you the chance to look in specially prepared search results such as to appear when searching for a hotel.