Eine schnelle Suche ist die halbe Miete – die andere Hälfte ist, was Besucherinnen und Besucher mit der Ergebnisliste anfangen können. In derselben Woche haben wir bei zwei Weinplattformen, VINUM und dem Grand Prix du Vin Suisse, die Such-Trefferlisten spürbar nutzerfreundlicher gemacht. Dieser Beitrag zeigt am echten Beispiel, wie kleine Interaktions-Verbesserungen eine Katalog- bzw. Suchseite aufwerten – und welche technischen Fallstricke dabei lauern.
Um die reine Geschwindigkeit der Suche ging es diesmal nicht; die hatten wir bereits in einem früheren Projekt mit SolR optimiert. Hier steht die Bedienbarkeit der Ergebnisliste im Mittelpunkt.
Die Trefferlisten taten, was sie sollten – aber nicht mehr. Die Ergebnisse waren fest nach dem besten Rating vorsortiert, ohne Möglichkeit für die Besucher, selbst umzusortieren. Produzenten standen als reiner Text in der Liste, obwohl zu vielen eine Website hinterlegt war. Auszeichnungen wurden als Wort (“Gold”, “Silber”) ausgegeben statt visuell erkennbar. Und beim Grand Prix du Vin Suisse blähten zwölf Spalten die Tabelle auf, von denen mehrere redundant waren.
Der Wunsch klingt simpel: Ein Klick auf eine Spaltenüberschrift sortiert die Liste nach dieser Spalte, auf- oder absteigend – nach Weinname, Jahrgang, Bewertung und so weiter. Der entscheidende technische Punkt steckt im Detail: Eine rein client-seitige Sortierung (etwa mit DataTables im Browser) funktioniert nur, wenn alle Treffer gleichzeitig im Seitenquelltext stehen. Beide Weinsuchen sind aber server-seitig paginiert – es liegen immer nur die aktuell angezeigten Treffer im Browser. Eine Browser-Sortierung würde also nur die sichtbare Seite umsortieren, nicht die gesamte Ergebnismenge.
Deshalb sortieren wir server-seitig über den vollständigen Treffersatz und paginieren erst danach. Bei VINUM geschieht das direkt in der SolR-Abfrage, beim Grand Prix du Vin Suisse über die TYPO3-/Extbase-Datenbankabfrage. Zwei Details waren uns dabei wichtig:
Eine Spalte ließ sich nicht einfach alphabetisch sortieren: die Auszeichnungen. “Absteigend” bedeutet hier nicht “Z bis A”, sondern beste zuerst: Grosses Gold, Gold, Silber, Bronze, Nominiert, keine. Wir bilden diese Rangfolge über eine feste Zuordnung ab und sortieren diese eine Spalte bewusst in der Anwendungslogik – die übrigen Spalten laufen über die Datenbankabfrage. So bleibt die Reihenfolge fachlich korrekt, auch wenn für einzelne Medaillen-Stufen noch nicht alle Stammdaten vorhanden sind.
Zu vielen Weingütern ist eine Website hinterlegt – bisher ungenutzt. Jetzt ist der Produzentenname anklickbar und öffnet die Website in einem neuen Tab. Ein Detail aus den echten Daten war hier entscheidend: Die allermeisten Adressen sind als reine Domain erfasst (z. B. www.weingut.ch) und nur eine Handvoll mit vorangestelltem https://. Ohne Schema interpretiert der Browser www.weingut.ch als Pfad auf der eigenen Seite – der Link liefe ins Leere. Wir ergänzen das Schema deshalb automatisch, sodass aus www.weingut.ch zuverlässig https://www.weingut.ch wird. Bereits vollständige Adressen bleiben unangetastet, und die Links tragen rel="noopener noreferrer" für ein sicheres Öffnen in neuen Tabs.
Statt des Wortes “Gold” zeigt die Auszeichnungsspalte nun ein Medaillen-Icon, exakt auf Texthöhe skaliert, sodass es sich harmonisch in die Zeile einfügt. Die Plattform ist zweisprachig (Deutsch/Französisch); damit das Icon in beiden Sprachen identisch erscheint, wählen wir es über einen sprachunabhängigen Schlüssel statt über den (übersetzten) Anzeigetext aus. Für unbekannte Werte fällt die Darstellung sauber auf den Text zurück, und das Bronze-Icon ist bereits hinterlegt, falls künftig eine Bronze-Medaille vergeben wird.
Schließlich haben wir die Tabelle beim Grand Prix du Vin Suisse von zwölf auf acht Spalten reduziert. Entfernt wurden vor allem redundante Angaben – etwa eine separate Jahr-Spalte, deren Wert sich bereits aus der Edition ergibt. Felder wie Farbe, Kanton und Rebsorte stehen weiterhin als Filter zur Verfügung; nur die Trefferliste selbst wurde verschlankt. Das Ergebnis ist eine ruhigere, besser scanbare Tabelle, die auch auf dem Smartphone deutlich aufgeräumter wirkt.
Keine dieser Änderungen ist für sich genommen spektakulär – in Summe machen sie aus einer funktionalen Trefferliste aber ein Werkzeug, mit dem Besucher tatsächlich arbeiten können: sortieren nach dem, was sie interessiert, mit einem Klick zum Produzenten und Auszeichnungen auf den ersten Blick erkennbar. Genau dieser Feinschliff an der Interaktion entscheidet oft darüber, ob eine Such- oder Katalogseite als angenehm empfunden wird.
Eine gute Suchseite ist mehr als ein schneller Index. Wer die Ergebnisliste konsequent vom Nutzen pro Treffer her denkt – sortierbar, verlinkt, visuell – holt aus bestehenden Daten erstaunlich viel zusätzlichen Mehrwert heraus, oft mit überschaubarem Aufwand.
Möchten Sie die Such- oder Katalogseite Ihrer Website nutzerfreundlicher machen? Sprechen Sie uns an – wir schauen uns Ihre Ergebnisliste gerne an.
]]>Profenster ist Spezialist für Fenster, Türen, Sonnenschutz und Wintergärten und betreibt seine Webpräsenz auf TYPO3. Nach dem Upgrade von TYPO3 12 auf 13 stand der entscheidende Schritt an: die Seite aus der Entwicklungsumgebung heraus sicher und stabil in den Produktivbetrieb zu bringen. Genau hier entscheidet die Konfiguration über Sicherheit, Zustellbarkeit von E-Mails und die Stabilität der Seite – und genau hier haben wir eine ganze Reihe typischer Stolperfallen ausgeräumt.
Eine Website, die in der Entwicklung tadellos läuft, ist noch lange nicht produktionsreif. Die Konfiguration trug an vielen Stellen Entwicklungswerte, die im Live-Betrieb entweder nicht funktionieren oder ein Sicherheitsrisiko darstellen:
Unser Ziel: eine konkrete, nachvollziehbare Checkliste abarbeiten, sodass die Seite sicher, stabil und ohne böse Überraschungen live geht.
Datenbank- und SMTP-Zugänge werden nicht mehr fest in der Konfiguration gespeichert, sondern zur Laufzeit aus Umgebungsvariablen gelesen. Die produktiven Geheimnisse liegen ausschließlich als Deploy- bzw. CI-Secrets vor und werden über die Container-Umgebung eingespielt. Für die lokale Entwicklung greifen weiterhin sichere Standardwerte – dieselbe, eingecheckte Konfiguration funktioniert damit in Entwicklung und Produktion, ohne dass ein einziges Passwort im Repository landet.
In der Entwicklung landen E-Mails in einem lokalen Auffang-Werkzeug – praktisch zum Testen, aber in Produktion ein stiller Totalausfall. Wir haben den Versand auf einen echten SMTP-Dienst umgestellt, inklusive Absenderadresse und -name. Das Zugangspasswort kommt auch hier aus einer geschützten CI-Variable, nicht aus dem Code. Damit erreichen Kontaktformular-Anfragen und Systembenachrichtigungen zuverlässig ihr Ziel – kein verlorener Lead mehr.
Für den Live-Betrieb haben wir Debug-Modus, Fehleranzeige und die Entwickler-Freischaltung per IP konsequent deaktiviert. So bekommen Besucher im Fehlerfall keine internen Stacktraces, Pfade oder Konfigurationsdetails mehr zu sehen – ein wichtiger Baustein, sobald echter Live-Traffic auf den neuen Server trifft.
Der Versionssprung von 12 auf 13 hat im individuellen Erweiterungspaket Warnungen ausgelöst, weil dort Schnittstellen verwendet wurden, die in Version 13 entfernt wurden – etwa für den Seitentitel in den Social-Media-Metadaten oder für die Bild-Auszeichnung. Wir haben diese Stellen auf die unterstützten Wege der Version 13 umgestellt (Seitentitel aus der Site-Konfiguration, Bildpfade aus der regulären Bildverarbeitung) und eine nicht initialisierte Variable bereinigt. Das Frontend rendert seitdem sauber, ohne Warnungen im Log.
Der Produktions-Build zog zuvor das komplette Arbeitsverzeichnis als Kontext mit – inklusive eines mehrere Gigabyte großen Datei-Verzeichnisses, an dem er schließlich scheiterte. Mit einer sauberen Ausschlussliste (.dockerignore) wandern nur noch die wirklich benötigten Dateien in den Build-Kontext. Das Ergebnis: ein schneller, schlanker und reproduzierbarer Build – ohne Datenballast und ohne versehentlich eingepackte Geheimnisse oder Datenbank-Dumps.
Die Website von Profenster läuft seit dem Go-live stabil und sicher auf TYPO3 13:
Ein erfolgreicher Go-live ist kein Zufall, sondern das Abarbeiten einer durchdachten Checkliste: Geheimnisse in die Umgebung, Mailversand auf einen echten Dienst, Debug-Ausgaben aus, veraltete Schnittstellen ersetzen und den Build von Ballast befreien. Wer einen TYPO3-Relaunch oder ein Major-Upgrade plant, sollte diese Punkte früh einplanen – statt mit einer halb konfigurierten Entwicklungsumgebung live zu gehen.
Sie planen einen TYPO3-Relaunch oder ein Upgrade und möchten sicher in Produktion gehen? Sprechen Sie uns an – wir begleiten Ihren Go-live von der ersten Checkliste bis zum stabilen Live-Betrieb.
]]>Im “Datenrecherche”-Backend-Modul von VINUM.eu können Redaktion und Datenpflege beliebige Treffermengen aus dem Wein- und Adressbestand als XLSX exportieren. Ein typischer Use-Case: alle Winzer aus der Schweiz, die in den letzten fünf Jahren mindestens einen 18-Punkte-Wein hatten – für einen redaktionellen Newsletter oder eine Eventeinladung.
Bisher lief das problemlos. Bis ein Redakteur eine Suche mit 19.565 Treffern abgesetzt hat, den Export-Button klickte – und nichts passierte.
Aus Benutzersicht: kein Fehler, kein Download, kein Hinweis. Aus Sicht der Logs: ein PHP-Fatal, sechsmal hintereinander, weil der Redakteur den Button mehrfach gedrückt hatte:
PHP Fatal error: Allowed memory size of 1073741824 bytes exhausted
(tried to allocate 167772160 bytes)
in /var/www/html/vendor/phpoffice/phpspreadsheet/src/PhpSpreadsheet/Collection/Cells.php
on line 395
Das memory_limit der Produktion liegt bei 1 GB – großzügig dimensioniert. PhpSpreadsheet hat es trotzdem gesprengt.
Die Ursache lag nicht in der Datenbankabfrage. Die war bereits gebatcht: BackendSearchHelper::exportXlsx() lädt die Treffer in Hunderter-Schritten über eine Pagination-Hilfsmethode. Das eigentliche Problem war die Spreadsheet-Erstellung:
$spreadsheet = new Spreadsheet();
$worksheet = $spreadsheet->getActiveSheet();
foreach ($paginatedResults as $row) {
$worksheet->fromArray($row, null, "A{$rowIndex}");
$rowIndex++;
}
$writer = new Xlsx($spreadsheet);
$writer->save($tmpFile);
PhpSpreadsheet hält intern die komplette Cells-Collection im Arbeitsspeicher, bis save() aufgerufen wird. Egal wie elegant man die Daten in 100er-Blöcken liest – die Mappe selbst wächst monoton mit. Bei rund 19.500 Zeilen × der vollständigen TCA-Spaltenliste war Schluss.
Im Frontend gab es zusätzlich ein UI-Problem: Der Export-Button wurde durch ein <f:if condition="{pagination.count} <= 35000"> ausgeblendet, sobald mehr als 35.000 Treffer in der Suche standen. Bei genau 19.565 war der Button sichtbar – und scheiterte trotzdem. Schlimmer noch: Beim Überschreiten der Grenze verschwand der Button kommentarlos, ohne dem Nutzer zu erklären, warum.
Wir haben den Export auf OpenSpout migriert – eine Library, die XLSX-Zeilen direkt auf die Festplatte streamt, statt sie im RAM zu sammeln. Der Speicherverbrauch bleibt damit konstant, unabhängig von der Zeilenzahl.
Die Migration war erstaunlich überschaubar, weil sich die API-Konzepte ähneln:
use OpenSpout\Common\Entity\Row;
use OpenSpout\Writer\XLSX\Writer;
$writer = new Writer();
$writer->openToFile($tmpFile);
$writer->addRow(Row::fromValues($headers));
foreach ($this->iterateResults($table, $repository, $search) as $row) {
$writer->addRow(Row::fromValues($row));
}
$writer->close();
Statt einer Spreadsheet-Instanz wird ein Writer geöffnet, der direkt in den Output-Stream schreibt. Jeder addRow()-Aufruf flusht die Zeile, der Speicher bleibt im einstelligen MB-Bereich – auch bei 100.000 Zeilen.
Wichtig: openspout/openspout haben wir explizit in der composer.json der backendsearch-Extension deklariert. Vorher griff die Extension auf PhpSpreadsheet zu, das nur transitive Abhängigkeit der Haupt-Extension vinum war. Solche impliziten Vendor-Abhängigkeiten sind eine tickende Zeitbombe: Wenn die übergeordnete Extension irgendwann auf eine andere Library wechselt, bricht der Export ohne sichtbaren Anlass.
Das <f:if> blendet den Button nicht mehr stumm aus, sondern ersetzt ihn durch eine erklärende Zeile:
<f:if condition="{pagination.count} <= {settings.maxExportRows}">
<f:then>
<f:render section="ExportButton" arguments="{_all}" />
</f:then>
<f:else>
<p class="text-muted">
<f:translate
key="export.tooManyResults"
arguments="{0: '{settings.maxExportRows}'}" />
</p>
</f:else>
</f:if>
Auf Deutsch: “Export nur bis 35.000 Treffer möglich. Bitte Suche eingrenzen.” Der Schwellwert ist konfigurierbar, das tatsächliche Limit wird im Text genannt. Mit OpenSpout könnten wir die Obergrenze theoretisch deutlich höher legen – pragmatisch belassen wir sie aber bei 35.000, weil ein Export dieser Größenordnung in Excel ohnehin nicht mehr sinnvoll zu bearbeiten ist.
Was bei diesem Fix unterschätzt wird: Der größere Aufwand steckte nicht in der Code-Änderung, sondern in der Diagnose. Ohne den Blick in fpm-stderr.log wäre die Ursache nicht eindeutig zuzuordnen gewesen – der Browser meldet keinen Fehler, das Backend liefert eine leere Antwort, und der Button “tut einfach nichts”.
Wir haben den Diagnose-Pfad daher in der Projektdokumentation festgehalten: Welche Logs für welche Symptome relevant sind, welche memory_limit- und max_execution_time-Werte produktiv gelten, und wie man PHP-Fatals einer konkreten Action im Backend zuordnet. Das spart bei der nächsten ähnlichen Meldung schlicht Zeit.
backendsearch-Extension hat ihre Abhängigkeit zu Excel-Libraries jetzt sauber in der eigenen composer.json deklariert.exportXlsx(string $table, object $repository, array $search): string) ist unverändert – der Refactoring lief vollständig innerhalb der Implementierung.PhpSpreadsheet ist eine ausgezeichnete Library, wenn man Formatierungen, Formeln, Diagramme oder mehrere Sheets benötigt. Für reine Datentabellen-Exporte mit größeren Treffermengen ist OpenSpout aber fast immer die bessere Wahl: schneller, schlanker, und ohne harte Obergrenze beim Datenvolumen.
Wenn Sie ähnliche Probleme mit Exporten, Imports oder generell speicherintensiven Backend-Modulen in TYPO3 haben, sprechen Sie uns an. Oft genügen punktuelle Eingriffe an den richtigen Stellen, um aus einem “geht nicht mehr” wieder ein “läuft zuverlässig” zu machen.
]]>Das Online-Archiv von VINUM.eu listet alle bisher erschienenen Magazin-Ausgaben seit 2014. Über die Jahre sind dort 356 Ausgaben zusammengekommen, 320 davon mit hochauflösendem Cover. Optisch beeindruckend – technisch problematisch.
Ein Blick in die Produktion hat den Ist-Zustand schnell sichtbar gemacht:
display: none ausgeblendet – die Bilder im DOM blieben aber geladen.loading="lazy" an einem <img>-Tag.Im ungünstigsten Fall musste der Browser also über 1 GB an Bildmaterial nachladen, nur um eine einzige Ausgabe anzuzeigen. Auf Mobilgeräten war das Archiv kaum benutzbar, und selbst auf dem Desktop dauerte das initiale Rendering mehrere Sekunden.
Interessant: Im ursprünglichen Kundenticket war von “den großen PNGs” die Rede. Die Datenbankanalyse hat aber klar gezeigt, dass die JPGs die eigentlichen Schwergewichte waren. Ohne diesen Blick in die Produktionsdaten wäre die Optimierung auf die falsche Stelle gelaufen.
Statt 320 Karten zu rendern und 285 davon im Browser zu verstecken, filtert jetzt der Server. Die listAction im IssueController akzeptiert einen optionalen ?year-Parameter und liefert standardmäßig nur das aktuelle Jahr aus – aktuell 35 Ausgaben statt 320:
public function listAction(?string $year = null): ResponseInterface
{
$years = $this->issueRepository->findYears();
$selectedYear = $year ?? (string)($years[0] ?? '');
$issues = $this->issueRepository->findByYear($selectedYear);
$this->view->assignMultiple([
'years' => $years,
'selectedYear' => $selectedYear,
'issues' => $issues,
]);
return $this->htmlResponse();
}
Im Repository werden die Jahre über einen QueryBuilder ermittelt – bewusst nicht über Extbase, um nicht jedes Issue-Objekt zu hydratieren, nur um daraus eine Jahreszahl zu lesen:
public function findYears(): array
{
$queryBuilder = GeneralUtility::makeInstance(ConnectionPool::class)
->getQueryBuilderForTable('tx_vinum_domain_model_issue');
return $queryBuilder
->select('year')
->distinct()
->from('tx_vinum_domain_model_issue')
->where(
$queryBuilder->expr()->neq('cover_image', $queryBuilder->createNamedParameter('')),
$queryBuilder->expr()->eq('deleted', 0),
$queryBuilder->expr()->eq('hidden', 0),
)
->orderBy('year', 'DESC')
->executeQuery()
->fetchFirstColumn();
}
Das Dropdown im Template wird serverseitig mit <f:form.select> befüllt und submittet beim change-Event. Deep-Links wie /archiv/?tx_vinum_issues[year]=2024 funktionieren ohne cHash-Fehler, weil die Argumente getypt sind.
Der bestehende SafeImageViewHelper der VINUM-Plattform unterstützt bereits maxWidth, fileExtension und loading-Attribute – die wurden nur noch nie genutzt:
<vinum:safeImage
src="{issue.coverImage.uid}"
treatIdAsReference="true"
maxWidth="700"
fileExtension="jpg"
loading="lazy" />
Drei Hebel in einer Zeile:
maxWidth="700" reduziert übergroße Originale auf eine sinnvolle Darstellungsgröße. Kleinere Originale werden nicht hochskaliert.fileExtension="jpg" zwingt TYPO3, auch PNGs als JPG auszuspielen. Für Magazincover, die ohnehin keine Transparenzen enthalten, ist das deutlich effizienter.loading="lazy" ist das native Lazy-Loading der Browser – kein JavaScript, kein Framework, keine Abhängigkeit.Die Re-Encoding-Qualität haben wir global in typo3/config/system/settings.php festgesetzt:
'GFX' => [
'jpg_quality' => 90,
],
90 ist ein bewährter Wert für Cover-Bilder: visuell kaum vom Original zu unterscheiden, aber typischerweise 5–10× kleiner als das JPG-Original aus der Druckvorstufe.
Im Frontend-JavaScript (Archive.js) blieb der Filter nach Ausgabennummer erhalten – der arbeitet jetzt auf maximal 35 Karten pro Jahr und ist daher unkritisch. Entfernt wurde nur die Logik, die das Jahres-Dropdown clientseitig befüllt und die Cover-Karten ein- und ausblendet. Weniger Code, weniger Sonderfälle.
Die Archivseite lädt nun in einem Bruchteil der ursprünglichen Zeit:
fileadmin bleiben unangetastet – die kleineren Varianten landen ausschließlich im TYPO3-Image-Cache.Spannend an diesem Projekt war weniger die einzelne Technik (Lazy-Loading, ImageProcessor, server-seitiger Filter sind alle Standard) als der Weg dorthin: Erst die Produktionsdaten analysieren, dann die Annahmen aus dem Ticket prüfen – und dann gezielt am richtigen Hebel ansetzen.
Performance-Probleme auf gewachsenen TYPO3-Seiten lassen sich fast immer auf eine Handvoll klassischer Muster zurückführen: clientseitige Filter über vollständige Listen, unkomprimierte Bilder, fehlendes Lazy-Loading, ungebatchte Repository-Calls. Wir analysieren Ihre konkrete Situation – inklusive Blick in die Datenbank und Logs – und benennen die Hebel mit dem besten Aufwand-Nutzen-Verhältnis.
]]>In einem früheren Beitrag haben wir gezeigt, wie ein einzelner Vulnerability Scanner eine TYPO3-Website lahmlegen konnte — nicht durch einen DDoS-Angriff, sondern durch die Erschöpfung von PHP-FPM-Workern. Das Rate Limit allein reichte nicht aus. Erst die Kombination aus Connection Limiting und fail2ban löste das Problem.
Dieser Fall illustriert ein grundlegendes Prinzip der IT-Sicherheit: Defense in Depth. Keine einzelne Schutzmassnahme ist perfekt. Jede Ebene hat blinde Flecken — was die Firewall nicht sieht, fängt das Rate Limiting ab; was das Rate Limiting nicht erkennt, blockiert die Intrusion Detection. Die Stärke liegt in der Kombination.
Für unsere TYPO3-Produktionsumgebungen setzen wir sieben aufeinander aufbauende Sicherheitsebenen ein, die wir im Folgenden durchgehen.
Die erste Verteidigungslinie ist der Server selbst. Über Cloud-Init wird jeder neue Server automatisch mit einer gehärteten Grundkonfiguration provisioniert:
SSH-Härtung:
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
ClientAliveInterval 300
ClientAliveCountMax 2
Root-Login ist deaktiviert, Passwort-Authentifizierung verboten. Nur Public-Key-Authentifizierung ist erlaubt, mit maximal 3 Fehlversuchen. Inaktive Verbindungen werden nach 10 Minuten getrennt — das verhindert vergessene SSH-Sessions als potenzielle Angriffsfläche.
Firewall (UFW):
ufw default deny incoming
ufw default allow outgoing
ufw allow ssh
ufw allow 80/tcp
ufw allow 443/tcp
Standardmässig wird jeglicher eingehender Traffic blockiert. Nur drei Ports sind offen: SSH für Administration, HTTP und HTTPS für Web-Traffic. Kein MySQL-Port, kein Redis-Port, kein phpMyAdmin — diese Dienste sind ausschliesslich über die interne Docker-Netzwerkkommunikation erreichbar.
Automatische Sicherheitsupdates: Unattended Upgrades prüfen täglich auf Patches und installieren Sicherheitsupdates automatisch. Bei Kernel-Updates erfolgt ein Reboot um 4:00 Uhr morgens. Docker-Pakete sind von automatischen Updates ausgenommen, da ein unerwartetes Docker-Upgrade laufende Container beeinträchtigen könnte.
Die Docker-Compose-Konfiguration definiert zwei getrennte Netzwerke:
networks:
backend:
internal: true
frontend:
Das backend-Netzwerk ist als internal markiert — Container in diesem Netzwerk haben keinen Zugang zum Internet und sind von aussen nicht erreichbar. MariaDB und Redis befinden sich ausschliesslich in diesem Netzwerk. Nur der TYPO3-Container hat Zugang zu beiden Netzwerken und fungiert als einziger Zugangspunkt.
Warum das wichtig ist: Selbst wenn ein Angreifer Code-Ausführung im TYPO3-Container erlangt, kann er die Datenbank nicht direkt aus dem Internet ansprechen. Es gibt keinen offenen Port, keinen Weg am Application Layer vorbei. Ein nmap-Scan auf dem Host zeigt nur Port 80, 443 und 22 — die Datenbankports existieren auf Netzwerkebene schlicht nicht.
Die Verschlüsselung zwischen Browser und Server ist die nächste Schicht:
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:...';
ssl_stapling on;
ssl_stapling_verify on;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
TLS 1.2 und 1.3 ausschliesslich — ältere Versionen mit bekannten Schwächen (POODLE, BEAST) sind deaktiviert. Die Cipher Suite priorisiert Forward Secrecy (ECDHE) und moderne Algorithmen (ChaCha20, AES-GCM).
OCSP Stapling beschleunigt die Zertifikatsprüfung: Statt dass der Browser den Zertifikatsstatus bei der CA abfragen muss, liefert der Server die signierte Bestätigung gleich mit. Das spart einen Roundtrip und verhindert Privacy-Leaks an die CA.
HSTS mit Preload sorgt dafür, dass Browser die Domain ausschliesslich über HTTPS laden — auch beim ersten Besuch, wenn der Nutzer http:// eingibt. Das preload-Flag registriert die Domain in den HSTS-Preload-Listen der Browser, sodass selbst der allererste HTTP-Request nie unverschlüsselt gesendet wird.
Automatische Zertifikats-Verwaltung: Let’s-Encrypt-Zertifikate werden beim Container-Start automatisch angefordert und zweimal täglich per Cron erneuert. Kein manuelles Eingreifen, keine abgelaufenen Zertifikate.
Nginx bildet die zentrale Verteidigung auf Applikationsebene:
Rate Limiting begrenzt jeden Client auf 5 Requests pro Sekunde mit einem Burst von 15. Das verhindert Brute-Force-Angriffe und bremst automatisierte Scanner. TYPO3-Backend-Dateiuploads (AJAX-Requests) sind vom Rate Limit ausgenommen, damit Redakteure nicht beim Hochladen grosser Dateien blockiert werden.
Blockierte Angriffspfade schliessen bekannte Einfallstore:
# Versteckte Dateien (.env, .git, .htaccess)
location ~ /\.(?!well-known\/) { deny all; }
# PHP-Ausführung in Upload-Verzeichnissen
location ~* ^/(?:fileadmin|typo3conf|typo3temp|uploads)/.*\.php$ { deny all; }
# Konfigurationsdateien und Backups
location ~ /(?:composer\.(?:json|lock)|.*\.(?:bak|conf|cfg|sql|log|sh))$ { deny all; }
# TYPO3-interne Verzeichnisse
location ~ /(?:typo3conf/ext|typo3/sysext)/[^/]+/(?:Resources/Private|Tests)/ { deny all; }
Die Regel für Upload-Verzeichnisse ist besonders kritisch: Wenn ein Angreifer eine PHP-Datei in fileadmin/ hochladen kann (z.B. über eine Schwachstelle im Datei-Upload), wird sie von Nginx nicht an PHP-FPM weitergeleitet, sondern blockiert. Die hochgeladene Datei ist nutzlos.
Security Headers ergänzen den Schutz auf HTTP-Ebene:
X-Content-Type-Options: nosniff # Verhindert MIME-Type-Sniffing
X-Frame-Options: SAMEORIGIN # Clickjacking-Schutz
Referrer-Policy: strict-origin-when-cross-origin
Server-Identität verbergen: Der X-Powered-By-Header, den PHP standardmässig sendet, wird über fastcgi_hide_header entfernt. Ein Angreifer soll nicht ohne Weiteres erkennen, welche PHP-Version läuft.
fail2ban überwacht die Nginx-Access-Logs und erkennt typische Scanner-Muster:
[Definition]
failregex = ^<HOST> -.*"(GET|POST) /\.env[^\s]* HTTP/.*$
^<HOST> -.*"(GET|POST) /wp-(admin|content|includes|json|login)[^\s]* HTTP/.*$
^<HOST> -.*"(GET|POST) /xmlrpc\.php[^\s]* HTTP/.*$
^<HOST> -.*"(GET|POST) /administrator[^\s]* HTTP/.*$
^<HOST> -.*"(GET|POST) /phpmyadmin[^\s]* HTTP/.*$
^<HOST> -.*"(GET|POST) /\.git[^\s]* HTTP/.*$
Jede IP, die innerhalb von 60 Sekunden 5 dieser Muster auslöst, wird für eine Stunde per nftables-Firewall-Regel auf allen Ports gesperrt. Der Scanner erhält keinen einzigen Response mehr — nicht einmal ein 403 Forbidden.
Warum nftables statt HTTP-Block? Ein HTTP-Level-Block (z.B. deny in Nginx) verbraucht trotzdem Server-Ressourcen: Nginx muss die Verbindung annehmen, den Request parsen und eine Antwort senden. Eine Firewall-Regel verwirft die Pakete bereits auf Kernel-Ebene, bevor sie den Userspace erreichen. Bei einem aggressiven Scanner spart das messbar CPU-Last.
Innerhalb des Containers ist PHP selbst gehärtet:
OPcache mit 256 MB Speicher und 10.000 gecachten Dateien sorgt dafür, dass PHP-Dateien nur einmal kompiliert werden. Das verbessert nicht nur die Performance, sondern verhindert auch, dass ein zur Laufzeit modifiziertes Script sofort ausgeführt wird — der OPcache liefert die kompilierte Version aus dem Speicher, bis revalidate_freq erreicht ist.
Ressourcen-Limits auf Container-Ebene verhindern, dass ein einzelner Service den gesamten Server lahmlegt. Die Limits werden vom Setup-Script berechnet und als Docker deploy.resources gesetzt:
deploy:
resources:
limits:
memory: 2G
cpus: "1.1"
reservations:
memory: 819M
Überschreitet ein Container sein Memory-Limit, wird er von Docker beendet und automatisch neu gestartet (restart: unless-stopped). Das ist besser als ein OOM-Kill auf Host-Ebene, der unkontrolliert Prozesse beenden könnte.
PHP-FPM Worker-Berechnung: Die Anzahl der Worker wird automatisch an den verfügbaren Speicher angepasst — ein Worker pro 80 MB. Das verhindert sowohl Worker-Erschöpfung (zu wenige) als auch Speicherüberläufe (zu viele).
Die letzte Ebene stellt sicher, dass Probleme erkannt werden, bevor sie zu Ausfällen führen:
Health Checks überwachen die Dienste. Redis wird alle 10 Sekunden per redis-cli ping geprüft. Nach 5 fehlgeschlagenen Checks startet Docker den Container automatisch neu.
Log Rotation verhindert, dass Logs die Festplatte füllen:
Scheduler-Lock-Reset: Beim Container-Start werden alle blockierten TYPO3-Scheduler-Tasks zurückgesetzt. Wird ein Container während eines laufenden Cronjobs beendet (z.B. bei einem Deployment), bleiben die Tasks sonst dauerhaft als “running” markiert und werden nie wieder ausgeführt. Der Entrypoint-Script erkennt diesen Zustand und bereinigt ihn automatisch.
Die Stärke von Defense in Depth liegt nicht in der einzelnen Massnahme, sondern im Zusammenspiel:
| Angriffsvektor | Ebene 1–2 | Ebene 3–4 | Ebene 5–7 |
|---|---|---|---|
| SSH-Brute-Force | UFW + SSH-Härtung | — | fail2ban sperrt nach 3 Versuchen |
| Vulnerability Scanner | Firewall blockiert unbekannte Ports | Rate Limiting bremst, Pfade blockiert | fail2ban sperrt per Muster |
| Hochgeladene PHP-Shell | — | Nginx blockiert PHP in Upload-Dirs | Logs zeigen den Versuch |
| SQL Injection | Netzwerkisolation begrenzt Schaden | — | Container-Limits verhindern Eskalation |
| Abgelaufenes Zertifikat | — | Automatische Erneuerung | Certbot-Logs bei Fehler |
Selbst wenn eine Ebene versagt, greifen die anderen. Ein Scanner, der das Rate Limit unterläuft (wie in unserem dokumentierten Fall), wird trotzdem von fail2ban erkannt. Ein PHP-Prozess, der ausser Kontrolle gerät, wird durch das Container-Memory-Limit begrenzt.
Sicherheit ist kein Feature, das man einmal konfiguriert. Es ist ein System aus sich ergänzenden Massnahmen, das regelmässig überprüft und erweitert wird. Unser Boilerplate automatisiert dieses System, sodass jedes neue Projekt automatisch alle sieben Ebenen erhält — ohne manuellen Aufwand und ohne die Möglichkeit, eine Ebene zu vergessen.
Die hier beschriebenen Massnahmen sind nicht TYPO3-spezifisch. Dieselben Prinzipien gelten für jede PHP-Anwendung hinter Nginx — ob WordPress, Symfony oder Laravel. Der Ansatz ändert sich nicht, nur die Applikationsschicht.
Möchten Sie wissen, wie gut Ihre aktuelle Server-Konfiguration gegen diese Angriffsvektoren geschützt ist? Wir analysieren Ihre Infrastruktur und identifizieren Lücken. Nehmen Sie über unser Kontaktformular unverbindlich Kontakt mit uns auf.
]]>Jedes neue TYPO3-Projekt braucht eine Produktionsumgebung. Server aufsetzen, Docker konfigurieren, Nginx härten, SSL einrichten, Firewall-Regeln definieren, CI/CD-Pipeline bauen — das sind pro Projekt schnell mehrere Tage Arbeit. Und bei jedem manuellen Schritt schleichen sich potenzielle Fehler ein: ein vergessener Security Header, eine fehlende Rate-Limiting-Regel, PHP-FPM-Worker die nicht zum verfügbaren RAM passen.
Wir haben über die letzten Jahre für jedes Kundenprojekt dieselben Bausteine konfiguriert — mit leichten Variationen je nach Servergrösse und Domain. Die Frage war: Können wir diesen Prozess so standardisieren, dass jedes neue Projekt automatisch den gleichen gehärteten Standard bekommt?
Wir haben ein TYPO3-Boilerplate entwickelt, das mit einem einzigen setup.sh-Aufruf ein vollständiges, produktionsreifes Projekt generiert. Das Script fragt Domain, Projektname und Server-Ressourcen ab und erzeugt daraus die komplette Infrastruktur — von Docker Compose über Nginx-Konfiguration bis zur GitLab-CI/CD-Pipeline.
Die generierte Umgebung besteht aus drei Services in Docker Compose:
Entscheidend ist die Netzwerktrennung: MariaDB und Redis befinden sich ausschliesslich im internen backend-Netzwerk. Nur der TYPO3-Container hat Zugang zu beiden Netzwerken — backend für die Datenbank-Kommunikation und frontend für HTTP/HTTPS-Traffic. Die Datenbank ist damit von aussen nicht erreichbar, auch nicht über einen Portscan auf dem Host.
networks:
backend:
internal: true # Kein Zugang von aussen
frontend:
Für die lokale Entwicklung stehen zusätzlich phpMyAdmin und MailHog als Docker-Profiles zur Verfügung — sie werden nur mit COMPOSE_PROFILES=development gestartet und sind in Staging/Production nicht vorhanden.
Einer der Kernaspekte des Boilerplates ist die automatische Berechnung von Docker-Ressourcenlimits basierend auf dem verfügbaren Server-RAM. Das Setup-Script fragt die RAM-Grösse für Staging und Production ab und generiert daraus jeweils eine docker-compose.staging.yml und docker-compose.production.yml mit passenden Limits.
Die Verteilung folgt einem festen Schema:
| Komponente | RAM-Anteil | CPU-Anteil |
|---|---|---|
| MariaDB | 35% | 25% |
| TYPO3 (PHP-FPM) | 50% | 55% |
| Redis | 5% (min. 128 MB) | 10% |
| Betriebssystem | 10% | — |
Aus dem TYPO3-Anteil berechnet das Script zusätzlich die optimale Anzahl PHP-FPM-Worker — ein Worker pro 80 MB verfügbarem Speicher. Bei einem 4-GB-Server ergeben sich so ca. 25 Worker, bei 8 GB etwa 51. Die pm.start_servers, pm.min_spare_servers und pm.max_spare_servers-Werte werden proportional dazu gesetzt.
Auch die MariaDB-Konfiguration wird angepasst: Der InnoDB Buffer Pool erhält 60% des Datenbank-Limits, die InnoDB Log File Size skaliert mit der RAM-Grösse (64 MB bis 256 MB). Ab 16 GB RAM werden zusätzliche Performance-Optionen wie tmp-table-size, join-buffer-size und Performance Schema aktiviert.
Das Ergebnis: Kein manuelles Tuning mehr. Die Ressourcen-Konfiguration ist immer auf den jeweiligen Server abgestimmt und verhindert sowohl OOM-Kills als auch ungenutzte Kapazität.
Für neue Server liefert das Boilerplate eine Cloud-Init-Konfiguration mit, die den Server beim ersten Start automatisch härtet:
deploy-Benutzer mit Docker-Zugang für CI/CD-DeploymentsDer gesamte Prozess läuft ohne manuellen Eingriff. Nach dem Boot ist der Server produktionsbereit.
Das Boilerplate enthält drei Nginx-Konfigurationen — Development, Staging und Production — die der Container beim Start je nach TYPO3_CONTEXT-Umgebungsvariable automatisch aktiviert. Die Production-Konfiguration umfasst:
TLS-Härtung:
includeSubDomains und preload (1 Jahr)Rate Limiting:
Blockierte Angriffspfade:
.git, .env, .svn)fileadmin, typo3temp, uploads)composer.json, Konfigurationsdateien, Logs und SQL-DumpsResources/Private, Tests, Documentation)Performance:
immutable-Flagstyle.abc123.css)Der Entrypoint-Script des TYPO3-Containers kümmert sich selbstständig um Let’s-Encrypt-Zertifikate. Beim ersten Start erkennt er, ob bereits Zertifikate vorhanden sind. Falls nicht, startet er zunächst eine temporäre HTTP-only-Konfiguration, fordert über Certbot ein Zertifikat an und wechselt dann zur vollständigen HTTPS-Konfiguration. Die Zertifikate werden in einem Docker Volume persistiert und zweimal täglich per Cron-Job erneuert.
Dieser Mechanismus funktioniert identisch für Staging und Production — der einzige Unterschied ist die Domain. Manuelle Zertifikats-Verwaltung entfällt komplett.
Die generierte .gitlab-ci.yml definiert zwei Deployment-Stages:
staging-Branchmain-BranchBeide Stages folgen demselben Ablauf:
rsync auf den Server synchronisieren (Runtime-Verzeichnisse und .env werden ausgeschlossen).env-Datei aus GitLab-CI-Variablen generieren (Passwörter liegen nie im Repository)docker-compose.override.yml aktivierenLogs werden auf drei Ebenen rotiert:
Redis hat einen eingebauten Health Check (10-Sekunden-Intervall), der Container-Neustarts bei Problemen auslöst. Der Entrypoint-Script setzt beim Start alle blockierten Scheduler-Tasks zurück — ein häufiges Problem, wenn Container während laufender Cronjobs beendet werden.
Was früher Tage manueller Konfiguration erforderte, ist jetzt ein 5-Minuten-Prozess:
./setup.sh
# → Domain, Titel, Server-RAM eingeben
# → Fertiges Projekt mit allen Konfigurationen
cd ../client.tld
docker compose up -d
Jedes Projekt startet mit demselben gehärteten Standard — unabhängig davon, ob es auf einem 2-GB-VPS oder einem 32-GB-Dedicated-Server läuft. Die Ressourcen-Konfiguration passt sich automatisch an, die Sicherheitsmassnahmen sind identisch.
Das Boilerplate ist ein lebendes System: Erkenntnisse aus dem Betrieb — wie die Absicherung gegen Vulnerability Scanner, die wir kürzlich beschrieben haben — fliessen zurück in die Standardkonfiguration. Jedes neue Projekt profitiert automatisch von den Erfahrungen aller bestehenden Projekte.
Sie suchen eine Agentur, die nicht nur TYPO3-Websites entwickelt, sondern auch das Hosting und die Infrastruktur professionell betreut? Sprechen Sie uns über unser Kontaktformular an — wir beraten Sie gerne.
]]>An einem Vormittag bemerkten wir über unser Monitoring eine erhöhte Antwortzeit bei VINUM.eu. Innerhalb weniger Minuten war die Website für reguläre Besucher nicht mehr erreichbar — Requests liefen in Timeouts. Die Ursache war kein klassischer DDoS-Angriff mit massenhaft verteiltem Traffic, sondern ein einzelner Vulnerability Scanner von der IP 185.177.72.50.
Der Scanner feuerte in nur 8 Minuten rund 964 Requests gegen die Website. Dabei probierte er systematisch typische Angriffsvektoren durch: .env-Dateien, WordPress-Endpunkte wie wp-json, wp-content und wp-admin, xmlrpc.php und diverse andere bekannte Pfade. Keiner dieser Pfade existierte auf der TYPO3-Installation — aber genau das war das Problem.
Auf dem Server war bereits ein Rate Limit von 5 Requests pro Sekunde konfiguriert. Im Durchschnitt lag der Scanner mit ca. 2 Requests pro Sekunde deutlich darunter. Allerdings öffnete er viele Verbindungen gleichzeitig, die parallel auf eine Antwort warteten. Jeder dieser Requests landete bei PHP-FPM, weil nginx die nicht existierenden Pfade an TYPO3 weiterreichte — und TYPO3 brauchte für jede 404-Antwort den vollen Rendering-Durchlauf.
Das Ergebnis: Alle 20 konfigurierten pm.max_children-Worker in PHP-FPM waren belegt. Legitime Requests von echten Besuchern konnten nicht mehr bedient werden und liefen in eine Queue, die sich über ca. 15 Minuten aufbaute.
Das Rate Limit schützt gegen Anfragen pro Sekunde — aber nicht gegen viele gleichzeitig offene Verbindungen, die jeweils einen Worker blockieren. Ein klassischer Fall, in dem Request Rate und Connection Concurrency zwei unterschiedliche Probleme sind.
Die Absicherung besteht aus zwei Ebenen: nginx begrenzt die gleichzeitigen Verbindungen pro IP, und fail2ban sperrt Scanner anhand ihrer typischen Request-Muster komplett aus.
Zusätzlich zum bestehenden Rate Limit haben wir ein Connection Limit eingeführt. In der nginx.conf wird zunächst eine Shared-Memory-Zone definiert:
http {
# Bestehend: Rate Limit
limit_req_zone $remote_addr zone=per_ip_rate:10m rate=5r/s;
# Neu: Connection Limit
limit_conn_zone $remote_addr zone=per_ip:10m;
}
In den PHP-Locations für das Frontend wird das Limit dann aktiviert:
location ~ \.php$ {
# Connection Limit: max. 10 gleichzeitige Verbindungen pro IP
limit_conn per_ip 10;
# Rate Limit: Burst von 15 auf 8 reduziert
limit_req zone=per_ip_rate burst=8 nodelay;
fastcgi_pass unix:/run/php/php-fpm.sock;
# ... weitere fastcgi-Parameter
}
Für das TYPO3-Backend (/typo3/) erlauben wir etwas mehr gleichzeitige Verbindungen, da Redakteure im Backend naturgemäss mehr parallele Requests erzeugen (AJAX-Calls, Modul-Loads etc.):
location /typo3/ {
limit_conn per_ip 15;
limit_req zone=per_ip_rate burst=8 nodelay;
# ... Backend-spezifische Konfiguration
}
Mit limit_conn per_ip 10 kann eine einzelne IP maximal 10 Verbindungen gleichzeitig offen halten. Der Scanner, der dutzende parallele Connections aufbaute, wird damit auf 10 begrenzt — die restlichen Verbindungen erhalten sofort einen 503 Service Temporarily Unavailable. Die PHP-FPM-Worker bleiben für legitime Besucher verfügbar.
Das Connection Limit begrenzt den Schaden, aber ein Vulnerability Scanner hat auf der Website grundsätzlich nichts verloren. Mit einem fail2ban-Jail erkennen wir typische Scanner-Muster und sperren die IP komplett per Firewall.
Der Filter (/etc/fail2ban/filter.d/nginx-scanner.conf):
[Definition]
failregex = ^<HOST> .* "(GET|POST|HEAD) /\.env.*"
^<HOST> .* "(GET|POST|HEAD) /wp-(admin|content|includes|json|login).*"
^<HOST> .* "(GET|POST|HEAD) /xmlrpc\.php.*"
^<HOST> .* "(GET|POST|HEAD) /administrator/.*"
^<HOST> .* "(GET|POST|HEAD) /config\.(php|yml|json|bak).*"
^<HOST> .* "(GET|POST|HEAD) /\.git/.*"
ignoreregex =
Das zugehörige Jail (/etc/fail2ban/jail.d/nginx-scanner.conf):
[nginx-scanner]
enabled = true
port = http,https
filter = nginx-scanner
logpath = /var/log/nginx/access.log
maxretry = 3
findtime = 600
bantime = 86400
action = iptables-multiport[name=scanner, port="http,https", protocol=tcp]
Mit maxretry = 3 und findtime = 600 wird eine IP gesperrt, sobald sie innerhalb von 10 Minuten 3 dieser typischen Scanner-Requests absetzt. Die Sperre (bantime = 86400) gilt für 24 Stunden. Damit wäre der Scanner aus unserem Vorfall bereits nach seinen ersten drei Probing-Versuchen geblockt worden — weit bevor er die PHP-FPM-Worker hätte erschöpfen können.
Die Kombination aus Connection Limiting und fail2ban bietet einen zweischichtigen Schutz:
Sofortwirkung durch Connection Limit: Selbst wenn ein Scanner noch nicht von fail2ban erkannt wurde, kann er maximal 10 gleichzeitige Verbindungen aufbauen. Die restlichen PHP-FPM-Worker bleiben für regulären Traffic verfügbar.
Nachhaltige Sperre durch fail2ban: Scanner werden anhand ihrer typischen Muster erkannt und per Firewall komplett ausgesperrt — ohne dass ein einziger PHP-FPM-Worker belastet wird.
Kein Einfluss auf reguläre Besucher: 10 gleichzeitige Verbindungen pro IP sind für normales Browsing mehr als ausreichend. Auch der reduzierte Burst-Wert von 8 schränkt reguläre Nutzer nicht ein.
Diese Massnahmen sind nicht TYPO3-spezifisch. Jede PHP-Anwendung, die hinter nginx und PHP-FPM läuft — ob WordPress, Symfony oder Laravel — profitiert von dieser Absicherung. Entscheidend ist, dass Rate Limiting allein nicht ausreicht: Wer nur Requests pro Sekunde begrenzt, übersieht das Problem gleichzeitig offener Verbindungen, die Worker blockieren.
Steht Ihre Website regelmässig unter Beschuss durch Scanner oder Bots? Wir analysieren Ihre Server-Konfiguration und implementieren passende Schutzmassnahmen. Nehmen Sie über unser Kontaktformular unverbindlich Kontakt mit uns auf.
]]>VINUM.eu betreibt mehrere Ländereditionen – CH, DE, FR und EN – und leitet Besucher beim ersten Aufruf automatisch anhand ihrer IP-Adresse auf die passende Edition weiter. Klingt einfach, funktioniert in der Praxis aber nicht immer. Besonders bei Schweizer Nutzern.
Während eines Seminars in Zürich fiel auf, dass ein Grossteil der Teilnehmer trotz Schweizer Standort auf die deutsche Edition von VINUM weitergeleitet wurde. Die Ursache: GeoIP-Datenbanken erreichen für Schweizer IP-Adressen nur eine Trefferquote von rund 78 %.
Die Gründe dafür sind vielfältig:
Das Ergebnis: Mehr als jeder fünfte Schweizer Besucher landete auf der falschen Länderseite – ein Problem für User Experience und Conversion gleichermassen.
Browser senden bei jedem Request einen Accept-Language-Header mit, der die bevorzugten Sprachen und Regionen des Nutzers enthält. Schweizer Browser liefern dabei typischerweise Subtags wie de-CH, fr-CH oder it-CH – unabhängig davon, welche IP-Adresse der Nutzer gerade hat.
Wir haben in TYPO3 die bestehende GeoipHelper.php um eine neue Methode hasSwissAcceptLanguage() erweitert. Diese prüft den Accept-Language-Header gegen eine Konstante SWISS_ACCEPT_LANGUAGE_SUBTAGS, die alle relevanten Schweizer Locale-Subtags enthält:
const SWISS_ACCEPT_LANGUAGE_SUBTAGS = ['de-CH', 'fr-CH', 'it-CH', 'rm-CH'];
Die Logik greift an zwei Stellen:
RedirectController::detectLanguageUid() – die initiale Weiterleitung beim ersten Seitenaufruf. Wenn GeoIP das Land als DE erkennt, der Accept-Language-Header aber einen Schweizer Subtag enthält, wird stattdessen auf /ch/ weitergeleitet.LanguageController::popupAction() – das Popup zur Länderauswahl. Auch hier wird das Fallback-Signal berücksichtigt, damit der Nutzer direkt den richtigen Vorschlag sieht.Der Vorteil: Der Accept-Language-Header ist bei jedem Request vorhanden, verursacht keine zusätzlichen Kosten und erfordert keinen externen Dienst.
Zusätzlich haben wir die manuelle Länderauswahl überarbeitet:
| Sprechende Labels: Statt der kryptischen Kürzel “CH | DE | FR” stehen jetzt die ausgeschriebenen Namen “Deutschland”, “Schweiz” und “Suisse romande” in der Auswahl. |
Beide Massnahmen senken die Hürde für Nutzer, die trotz aller Automatik auf der falschen Edition gelandet sind.
Die Kombination aus GeoIP und Accept-Language-Fallback löst 60–70 % der bisherigen Fehlerkennungen bei Schweizer Nutzern auf. Konkret bedeutet das:
Für die verbleibenden Fälle (z. B. Nutzer mit vollständig nicht-schweizerischer Browserkonfiguration hinter einem deutschen VPN) sorgt die verbesserte manuelle Länderauswahl dafür, dass der Wechsel zur richtigen Edition schnell und unkompliziert möglich ist.
GeoIP-basierte Weiterleitungen sind ein häufiges Muster bei mehrsprachigen Websites – und die Tücken liegen im Detail. Wenn Sie Probleme mit der Ländererkennung haben oder eine mehrsprachige TYPO3-Website planen, sprechen Sie uns an. Wir finden eine Lösung, die zu Ihrem Setup passt.
]]>Im vorangegangenen Beitrag haben wir gezeigt, welche Typfehler beim PHP 8.4-Upgrade in TYPO3-Extensions auftreten. Die manuelle Suche nach diesen Mustern ist zeitaufwändig: findByUid() wird in einem typischen Projekt hunderte Male aufgerufen, und nicht jeder Aufruf ist problematisch. Klassische statische Analyse-Tools wie PHPStan stoßen hier an Grenzen — besonders bei dynamischen Framework-Konstrukten wie TypoScript-Settings, Extbase-Argumenten oder $GLOBALS-Zugriffen.
Die Frage war: Können wir die Erkennung dieser Muster automatisieren?
Wir haben unser bestehendes /techdebt-Kommando in Claude Code um eine neue Prüfkategorie erweitert: Call-Site Type Mismatch Detection. Das Tool scannt TYPO3-Extensions gezielt nach den Mustern, die wir in der Praxis als häufigste Fehlerquellen identifiziert haben.
Die Erkennung konzentriert sich auf vier Kategorien, die in der Praxis die meisten TypeError-Crashes verursachen:
1. String-Argumente an findByUid()
Das Tool identifiziert Aufrufe, bei denen der übergebene Wert aus einer String-Quelle stammt — etwa $GLOBALS-Arrays, getArgument(), TypoScript-Settings, explode() oder String-Literale wie '1':
⚠ EventController.php:1028 — findByUid('1') receives string literal
Fix: Replace '1' with 1
⚠ EventController.php:415 — findByUid($uid) where $uid comes from getArgument()
Fix: Add (int) cast
2. date('U') für int-Spalten
date('U') gibt einen String zurück. Wird er in ein Datenbankfeld vom Typ int geschrieben, schlägt das unter strict_types fehl:
⚠ EventController.php:892 — date('U') assigned to int column 'tstamp'
Fix: Replace with time()
3. Falsche Cast-Typen bei Settern
Setter mit bool-Signatur erhalten (int)-Casts, oder umgekehrt:
⚠ EventController.php:340 — setDataForwarding((int)$value) but parameter expects bool
Fix: Change cast to (bool)
4. Doctrine DBAL Result-Objekte
Seit TYPO3 12 gibt execute() ein Result-Objekt zurück. Das Tool erkennt, wenn dieses Objekt ohne fetchAllAssociative() weitergegeben wird.
Neben der Erkennung bietet das Tool auch Auto-Fix-Regeln. Für jedes gefundene Muster wird ein konkreter Fix vorgeschlagen und auf Wunsch direkt angewendet:
findByUid('1') → findByUid(1)findByUid($stringVar) → findByUid((int)$stringVar)date('U') → time()(int)$value bei Bool-Setter → (bool)$valueBeim ersten Durchlauf auf dem betroffenen Projekt fand das Tool alle 15 Typ-Mismatches, die wir zuvor manuell identifiziert hatten — plus drei weitere, die noch nicht zu Crashes geführt hatten, aber es unter bestimmten Bedingungen getan hätten.
Der entscheidende Vorteil: Das Tool läuft jetzt als Teil unseres regulären Code-Quality-Checks. Neue Typfehler werden erkannt, bevor sie in die Produktion gelangen — nicht erst, wenn ein Nutzer auf den betroffenen Code-Pfad trifft.
Statische Analyse-Tools sind unverzichtbar, aber sie decken nicht alles ab — besonders nicht in Framework-Code mit dynamischen Werten. KI-gestützte Tools wie Claude Code schließen diese Lücke, weil sie Muster kontextbezogen erkennen können, nicht nur syntaktisch.
Für uns ist das ein Baustein in einer größeren Entwicklung: KI nicht als Ersatz für Entwickler, sondern als Werkzeug, das die Code-Qualität systematisch verbessert und Fehler abfängt, bevor sie Schaden anrichten.
Sie möchten KI-gestützte Workflows in Ihre Entwicklungsprozesse integrieren? Kontaktieren Sie uns — wir teilen gerne unsere Erfahrungen.
]]>Mit dem Upgrade auf PHP 8.4 und der konsequenten Nutzung von declare(strict_types=1) treten in vielen TYPO3-Projekten plötzlich TypeError-Exceptions auf — an Stellen, die jahrelang problemlos liefen. Der Grund: PHP akzeptierte in früheren Versionen stillschweigend falsche Typen und konvertierte sie automatisch. Unter strict_types ist damit Schluss.
In einem unserer TYPO3-Projekte führte das zu Produktionsausfällen: Nutzer konnten keine Bilder mehr hochladen, Stammdaten nicht bearbeiten und Events nicht aktualisieren. Die Fehler traten erst im Live-Betrieb auf, weil die betroffenen Code-Pfade in der Entwicklungsumgebung nicht vollständig durchlaufen wurden.
Wir haben die Fehler analysiert und fünf wiederkehrende Muster identifiziert, die in fast jeder gewachsenen TYPO3-Extension vorkommen:
findByUid() erhält einen String statt intDas häufigste Problem. Werte aus $GLOBALS['TSFE'], Request-Argumenten oder TypoScript-Settings sind immer Strings — findByUid() erwartet aber einen int.
// Vorher — crasht unter strict_types
$storage = $this->storageRepository->findByUid('1');
$user = $this->userRepository->findByUid($GLOBALS['TSFE']->fe_user->user['uid']);
$event = $this->eventRepository->findByUid($eventUid); // aus explode()
// Nachher
$storage = $this->storageRepository->findByUid(1);
$user = $this->userRepository->findByUid((int)$GLOBALS['TSFE']->fe_user->user['uid']);
$event = $this->eventRepository->findByUid((int)$eventUid);
date('U') statt time()date('U') gibt einen Unix-Timestamp zurück — aber als String. Wird dieser Wert in eine Datenbankspalte vom Typ int geschrieben, knallt es.
// Vorher
$object->setTstamp(date('U'));
// Nachher
$object->setTstamp(time());
execute() gibt kein Array mehr zurückIn Doctrine DBAL 3 (ab TYPO3 12) liefert QueryBuilder->execute() bei SELECT-Queries ein Result-Objekt statt eines Arrays. Wird dieses direkt an ein Fluid <f:form.select> übergeben, kommt es zum Fehler.
// Vorher
$regions = $queryBuilder->execute();
$this->view->assign('regions', $regions);
// Nachher
$regions = $queryBuilder->executeQuery()->fetchAllAssociative();
$this->view->assign('regions', $regions);
Setter-Methoden mit bool-Typdeklaration erhalten oft int-Werte (0 oder 1) aus der Datenbank oder Formularen.
// Vorher
$object->setDataForwarding((int)$value);
// Nachher
$object->setDataForwarding((bool)$value);
Die EXT:solr Queue::updateItem() erwartet int als $forcedChangeTime — bekommt aber häufig Strings aus Datenbankfeldern oder date()-Aufrufen.
// Vorher
$queue->updateItem($item, $indexConfig, $record['tstamp']);
// Nachher
$queue->updateItem($item, $indexConfig, (int)$record['tstamp']);
Insgesamt haben wir über 15 Typ-Korrekturen in einem einzigen Controller durchgeführt — und ähnliche Muster in weiteren Klassen gefunden. Die Crashes im Live-Betrieb waren sofort behoben, und die Nutzer konnten die betroffenen Funktionen wieder normal verwenden.
PHP 8.4 mit strict_types ist kein Feind — es ist ein Verbündeter. Die Typfehler waren schon immer da, nur hat PHP sie bisher stillschweigend geschluckt. Wer den Umstieg systematisch angeht und die fünf häufigsten Muster kennt, kann ein ganzes Projekt in kurzer Zeit absichern.
Im nächsten Beitrag zeigen wir, wie wir diesen Prozess mit einem KI-gestützten Tool automatisiert haben.
Sie planen ein PHP-Upgrade oder kämpfen mit Typfehlern in Ihrem TYPO3-Projekt? Sprechen Sie uns an — wir unterstützen Sie gerne bei der Migration.
]]>