camaliga für TYPO3

Für die meisten Listen in TYPO3 braucht man keine eigene Extension

Ein Unternehmen will Referenzen auf der Website zeigen: Logo, Kundenname, Branche, Kurzbeschreibung. Ein anderes will Mitarbeiter auflisten: Foto, Name, Abteilung, Telefon. Ein drittes braucht eine Produktübersicht: Bild, Titel, Preis, Link zur Detailseite. Drei verschiedene Anforderungen, ein gemeinsames Muster: strukturierte Listen mit konfigurierbaren Feldern. camaliga löst dieses Muster als generische Listen-Extension, statt für jeden Listentyp eine Custom Extension zu entwickeln.

Die Extension von quizpalme ist seit Jahren im TYPO3 Extension Repository verfügbar und wird aktiv gepflegt. Ihr Vorteil: Ein Datensatz-Typ mit flexiblen Feldern deckt 80% aller Listen-Anforderungen ab. Der Nachteil: Wer sehr spezifische Datenmodelle braucht (verschachtelte Relationen, Mehrsprachigkeit auf Feldebene, komplexe Validierung), stößt an Grenzen.

Typische Einsatzszenarien

Referenz- und Kundenlisten. Der häufigste Einsatz: Logos und Beschreibungen von Kunden oder Projekten in einer Grid-Darstellung. camaliga bringt fertige Layouts mit: Grid, Karussell, Akkordeon, Tab-Darstellung. Die Daten werden im TYPO3-Backend als Datensätze gepflegt, die Darstellung über Fluid-Templates gesteuert. Bei einem Kunden mit 120 Referenzen war die camaliga-basierte Referenzseite in 3 Tagen live, inklusive Filterung nach Branche.

Team- und Mitarbeiterseiten. Foto, Name, Position, Kontaktdaten, optional ein Kurztext. camaliga bildet das über seine Standard-Felder ab: Titel, Untertitel, Bild, Beschreibung, Link. Für zusätzliche Felder (Telefonnummer, Abteilung) lassen sich Custom-Felder über TCA-Override ergänzen. Die Alternative wäre EXT:tt_address, die aber auf Adressdaten spezialisiert ist und für Teamseiten oft zu viel und gleichzeitig zu wenig bietet.

Einfache Produktübersichten ohne Shop-Funktionalität. Unternehmen, die Produkte darstellen, aber nicht verkaufen wollen, brauchen keinen Shop. camaliga liefert eine Produktliste mit Bild, Titel, Preis-Feld und Link zum Datenblatt. Filterung nach Kategorie ist über die integrierte Kategorie-Zuordnung möglich. Für 50-200 Produkte ohne Warenkorb ist das effizienter als Aimeos oder bernetshop.

Technische Architektur

camaliga basiert auf Extbase/Fluid und folgt dem MVC-Pattern. Der zentrale Datensatz-Typ heißt tx_camaliga_domain_model_content und enthält Felder für Titel, Untertitel, Beschreibung, Kurzbeschreibung, Bild, Link, Kategorie und mehrere Custom-Felder. Die Felder sind im TCA definiert und lassen sich über TCA-Override im Sitepackage erweitern oder reduzieren.

Die Darstellung erfolgt über ein Frontend-Plugin mit konfigurierbarem Layout. Im Plugin-FlexForm wählt der Redakteur: Welche Kategorie anzeigen, welches Layout verwenden, wie viele Einträge pro Seite, ob Paginierung aktiv ist. Die Layouts sind Fluid-Templates, die im Sitepackage überschrieben werden. camaliga liefert circa 15 fertige Layouts mit, von der einfachen Liste bis zum gefilterten Grid mit Isotope-Animation.

Die Kategorie-Filterung nutzt TYPO3s System-Kategorien. Jeder camaliga-Datensatz kann einer oder mehreren Kategorien zugeordnet werden. Im Frontend wird ein Filter-Menü generiert, das per JavaScript (Isotope oder CSS-Filter) oder per Seitenaufruf filtert. Die JavaScript-Variante ist schneller, die Seitenaufruf-Variante SEO-freundlicher.

Für die Sortierung bietet camaliga mehrere Optionen: nach Titel, nach Erstellungsdatum, nach manueller Sortierung (Drag-and-Drop im Backend). Die manuelle Sortierung nutzt das sorting-Feld der Datenbank und funktioniert über TYPO3s Standard-Sortierungsmechanismus im List-Modul.

Häufige Probleme und Lösungen

Layouts sehen anders aus als erwartet. camalias mitgelieferte Layouts setzen auf bestimmte CSS-Frameworks (Bootstrap 3/4) oder JavaScript-Libraries (Isotope, Masonry). Wenn die Website ein anderes Framework nutzt, kollidieren die Styles. Lösung: Nie die Standard-Templates verwenden, sondern eigene Fluid-Templates im Sitepackage anlegen. Der Aufwand für ein eigenes Template liegt bei 1-2 Stunden, danach ist die Darstellung vollständig kontrollierbar.

Performance bei mehr als 500 Datensätzen. camaliga lädt standardmäßig alle Datensätze einer Kategorie und filtert im Frontend per JavaScript. Bei 500+ Einträgen wird die initiale Ladezeit spürbar (3-5 Sekunden bei 1.000 Datensätzen mit Bildern). Lösung: Paginierung aktivieren und die Seitenanzahl auf 20-50 Einträge begrenzen. Für JavaScript-basierte Filterung: Lazy Loading der Bilder aktivieren und die Datenmenge per AJAX nachladen.

Mehrsprachigkeit erfordert Workaround. camaliga unterstützt TYPO3s Sprachhandling, aber die Übersetzung jedes einzelnen Datensatzes ist bei 200+ Einträgen aufwändig. Lösung: Für rein visuelle Listen (Logos ohne Text) reicht ein Datensatz pro Sprache. Für textlastige Listen die Übersetzung per TYPO3s Inline-Translation-Workflow beschleunigen oder ein Migrations-Script schreiben, das DeepL-API-Übersetzungen in die Sprachversionen importiert.

Migration und Versions-Kompatibilität

camaliga wird aktiv gepflegt und unterstützt TYPO3 v11, v12 und nach aktueller Roadmap auch v13. Die Extension folgt dem TYPO3-Release-Zyklus mit kurzer Verzögerung. Composer-Installation über Packagist ist möglich, TER-Installation ebenfalls.

Wer von einer Custom Extension auf camaliga migriert, muss die Daten aus der Custom-Tabelle in tx_camaliga_domain_model_content überführen. Das ist ein SQL-Job, der sich in den meisten Fällen in unter einem Tag erledigen lässt. In die andere Richtung: Wer von camaliga auf eine eigene Extbase-Extension umsteigt, kann die Datenstruktur als Vorlage nutzen.

Für komplexere Anforderungen (verschachtelte Datensätze, Relationen zwischen Listen, Workflow-Steuerung) empfiehlt sich statt camaliga eine Custom Extbase Extension oder EXT:mask. Gosign berät zur passenden Lösung und implementiert sowohl camaliga-basierte Schnelllösungen als auch individuelle Extensions.