Dynamische QR-Codes in TYPO3 – warum der Resolver alles verändert
Typo3

Dynamische QR-Codes in TYPO3 – warum der Resolver alles verändert

Yannick Aister 3 min read 40 Views

Das Problem mit normalen QR-Codes

QR-Codes auf Printmaterialien haben ein grundlegendes Problem: sie sind unveränderlich. Wer eine URL direkt in einen QR-Code kodiert und diesen dann auf Flyern, Messebannern oder Produktverpackungen druckt, ist gebunden. Ändert sich die Ziel-URL – neues Kampagnen-Landing-Page, Domainwechsel, Seitenumbau – ist der QR-Code wertlos. Neu drucken oder altes Material wegwerfen.

Für einmalige Aktionen ist das akzeptabel. Aber für alles was länger lebt – Broschüren, Visitenkarten, Schilder, Produktbeilagen – ist das ein echtes Problem. Genau das hat mich dazu gebracht, eine eigene TYPO3-Extension dafür zu bauen.

Die Lösung: ein stabiler Resolver statt direkter URL

Das Kernprinzip ist einfach: der QR-Code enthält nicht die finale Ziel-URL, sondern eine kurze Resolver-URL die dauerhaft stabil bleibt:

 

/q/{uid}/{hash}

 

Diese URL ändert sich nie. Was sich ändern kann, ist das Ziel dahinter – die target_url im Backend. Der Redakteur ändert die Ziel-URL, speichert – und alle bereits gedruckten QR-Codes zeigen automatisch auf die neue Seite.

Wie der Resolver technisch funktioniert

Die Extension registriert eine eigene TYPO3-Middleware die Requests auf /q/... abfängt, bevor TYPO3 sein normales Rendering startet. Der Ablauf bei jedem Scan:

  1. Scanner ruft /q/123/1a2b3c4d auf
  2. Middleware validiert UID und HMAC-Hash
  3. QR-Datensatz wird geladen
  4. Scan wird serverseitig getrackt
  5. Middleware antwortet mit 302-Redirect auf target_url

Der HMAC-Hash im Resolver-Pfad schützt dabei vor dem Erraten fremder QR-UIDs. Jeder QR-Code hat einen individuellen Hash der serverseitig geprüft wird.

Integration mit TYPO3 sys_redirect

Was die Extension besonders macht: sie nutzt die TYPO3-native Redirect-Infrastruktur als zusätzliche Schicht. Voraussetzung ist dass EXT:redirects installiert ist – was auf den meisten TYPO3-Instanzen der Fall ist. Beim Speichern eines QR-Datensatzes legt ein DataHandlerHook automatisch einen Eintrag in sys_redirect an – oder aktualisiert einen bestehenden.

Das hat zwei Vorteile:

  • Redundanz: Auch wenn die eigene Middleware ausfällt oder deaktiviert ist, funktioniert der Redirect über TYPO3s Redirect-Modul weiter
  • Transparenz: Alle aktiven QR-Redirects sind im TYPO3-Backend sichtbar und können von Administratoren nachvollzogen werden

Das eigentliche fachliche Tracking läuft aber nicht über sys_redirect.hitcount, sondern über eine eigene Scan-Tabelle mit deutlich mehr Kontext: Zeitpunkt, Referer, User-Agent, gehashte IP und Bot-Erkennung.

Serverseitiges Tracking – warum das wichtig ist

QR-Code-Scans kommen aus Kamera-Apps, Messenger-Previews und externen Browsern. Clientseitiges Analytics-JavaScript wird dabei oft nicht ausgeführt – oder der Nutzer hat JavaScript deaktiviert. Die Extension trackt deshalb serverseitig direkt am Resolver-Einstieg: jeder Scan wird gezählt, unabhängig davon was im Browser danach passiert.

Das Ergebnis sind verlässliche Zahlen direkt im TYPO3-Backend: Total Scans, Unique Scans, Human vs. Bot, Tagesverlauf, Top-Referer – alles ohne externe Analytics-Tools.

Was die Extension sonst noch kann

Neben dem Resolver-Konzept bietet die Extension einiges mehr: QR-Code-Erzeugung als SVG mit weitreichenden Styling-Optionen (Dot-Styles, Eye-Styles, Farbverläufe, Logo, Shadow), eine Live-Preview direkt im TYPO3-Backend ohne Speichern, Style-Presets und einen CSV-Export der Scan-Rohdaten.

Die Extension ist aktuell nicht öffentlich verfügbar. Bei Interesse an einer Lizenz oder einer projektspezifischen Implementierung bin ich gerne erreichbar.

Zusammengefasst

  1. QR-Codes zeigen auf eine stabile Resolver-URL /q/{uid}/{hash} statt direkt auf die Ziel-URL
  2. Die Ziel-URL kann jederzeit im Backend geändert werden – gedruckte QR-Codes bleiben gültig
  3. Eine TYPO3-Middleware fängt Resolver-Requests ab, trackt serverseitig und leitet per 302 weiter
  4. TYPO3 sys_redirect wird automatisch synchronisiert – als redundante Schicht
  5. Tracking läuft serverseitig – funktioniert auch ohne JavaScript und in Kamera-Apps

Leave a comment