I tried to improve the downlad-time and size of the assets used in this blog. This is mainly about optimizing the images for web. Not only that all JavaScript from this site has been removed previously, the images were a huge factor in the traffic of this page.. The images used in this blog are of different types. We use PNG, JPEG and SVG. Some of these files are huge and not optimized for web use.

A data import is part of most of our projects and in some cases, we need to re-import all the data from time to time. This post shows how you can delegate this task to a GitLab CI job and start it by adding a certain keyword to your commit message. What is the problem? There are several circumstances when a data import (or a re-import) is required.

First of all - I could have put much more words in the title because we are covering a complete workflow for our TYPO3 documentation (for our customers and their sites). We will see the tools used, how it is organized and finally how it is deployed. Format TYPO3 used to use an OpenOffice-based documentation shipped as *.sxw files ages ago.

On many of our Websites we have contact forms. And recently there seems to be an elevated number of bots filling out these forms with spam data. That’s especially a problem, when a contact form is directly connected to an Issue Tracker, that automatically generates an issue when a mail to a specified address arrives. A possible solution for avoiding automated form-fills is using CAPTCHAs.

In our University - and also our Data-Center GWDG we use Open-Source Software whenever it is possible. So, instead of using proprietary Video Conferencing Services, such as Zoom, Google Meet or Microsoft Teams / Skype, the GWDG provided us a reliable Big Blue Button Service. This Software is - compared to the proprietary solutions mentioned above - limited in its functionality, especially the fun part!

The way we are using TYPO3 has constantly been changed in the last 10 years. I will show you, how we use state-of-the-art technologies to optimize and automatize the way of building and deploying our TYPO3 sites. History There were times no source code repository existed and everything was done live on the server. Then we had monolithic repositories in Subversion (do you member?) where each and everything belonging to the site was stored.

C reate R ead U pdate D elete — these operations describe the most common tasks a relational database is used for. A common task on top of that, is to build interfaces for users, to execute these operations in a nice way and create a frontend for these task.

This blog post accompanies my DH-Tech talk about config management. tl;dr : There is a recording available. Problems with infrastructure administration Operating an infrastructure can be hard. Among the most common problems is that of reproducibility, i.e. Is the documentation both current and correct? Is it clear how to do a fresh install or set up a secondary system? Another is that of uniformity, i.e. are there any standards?

Sometimes the most sophisticated deployment strategies and infrastructure models can unfortunatly not be shifted into the real life, so one has to go back a few decades and use tools from that time and mix them with current ones. In a former post I described a cool solution for building a static HTML website and putting it into a Docker image.

Web-scraping is ugly, but sometimes it may become necessary, because services don’t expose an API to retrieve data. Basically web-scraping is a mechanism to programatically open a website and grab the contents in order to using it for own purposes. The mission In one of our sites, we are using the HTML output of a not-that-hip-anymore-database allegro.