gb_events für TYPO3

Nicht jede Veranstaltung braucht eine Registrierung, aber jede braucht eine ordentliche Darstellung

sf_event_mgt ist der Standard für Event-Management in TYPO3: Registrierung, Warteliste, Bezahlung, Teilnehmerverwaltung. Aber viele Organisationen zeigen Veranstaltungen nur an, ohne Online-Registrierung. Ein Konzertkalender, ein Veranstaltungsprogramm einer Gemeinde, die Termine einer Volkshochschule, bei all diesen Szenarien wäre sf_event_mgt Overkill. gb_events füllt diese Lücke: einfache Event-Darstellung mit Kalenderansicht, ohne den Overhead eines vollständigen Event-Management-Systems.

Die Extension ist für Organisationen gemacht, die Termine veröffentlichen, aber nicht verwalten wollen. Kein Registrierungsformular, keine Teilnehmerliste, keine Zahlungsabwicklung. Dafür eine saubere Listendarstellung, eine Kalenderansicht und eine Detailseite pro Event.

Typische Einsatzszenarien

Gemeinde- und Kirchengemeinde-Websites. Gottesdienste, Konzerte, Gemeindefeste, Seniorennachmittage, ein typischer Gemeinde-Kalender hat 20-40 Events pro Monat. Besucher wollen sehen, was wann stattfindet, und vielleicht die Termine in ihren persönlichen Kalender übernehmen. Eine Registrierung ist nicht nötig, die Veranstaltungen sind öffentlich. gb_events bildet das mit minimalem Konfigurationsaufwand ab.

Volkshochschulen und Bildungseinrichtungen (Programmübersicht). Die Kursanmeldung läuft über ein externes System (Kufer, WebOpac, Stufen), aber das Programm soll auf der TYPO3-Website durchsuchbar sein. gb_events zeigt die Kurse als Event-Liste, gefiltert nach Kategorie (Sprachen, Kreativität, IT, Gesundheit) und Zeitraum. Die Detailseite verlinkt auf das externe Anmeldesystem.

Veranstaltungsreihen mit wiederkehrenden Terminen. Ein Sportverein hat Training montags und mittwochs, ein Stammtisch jeden ersten Donnerstag. gb_events stellt wiederkehrende Termine dar, ohne dass jeder Einzeltermin manuell angelegt werden muss. Die Wiederholung wird konfiguriert, gb_events generiert die Termine automatisch.

Technische Architektur

gb_events basiert auf Extbase/Fluid und nutzt eine eigene Datenbanktabelle tx_gbevents_domain_model_event. Jedes Event hat die Felder: Titel, Beschreibung, Startdatum, Enddatum, Ort, Bild, Kategorie und optional eine Wiederholungsregel. Die Kategorien nutzen TYPO3s System-Kategorien, was die Integration mit anderen Extensions vereinfacht.

Das Frontend besteht aus drei Views: Listenansicht (chronologisch, filterbar nach Kategorie und Zeitraum), Kalenderansicht (Monatsdarstellung mit klickbaren Tagen) und Detailansicht (vollständige Event-Informationen). Alle Views sind Fluid-Templates und lassen sich im Sitepackage überschreiben.

Die Kalenderansicht rendert ein HTML-Table-Grid mit 7 Spalten (Wochentage) und 4-6 Zeilen (Wochen). Jede Zelle enthält die Events des jeweiligen Tages als verlinkte Titel. Die Navigation zwischen Monaten erfolgt per Link-Parameter (GET), nicht per AJAX. Das ist SEO-freundlich, weil jeder Monat eine eigene URL hat und von Google indexiert werden kann.

Die Wiederholungslogik arbeitet ähnlich wie bei calendarize: Ein Datensatz mit Wiederholungsregel erzeugt virtuelle Events. Diese werden zur Laufzeit berechnet und nicht in der Datenbank materialisiert. Das spart Speicher, erfordert aber Rechenzeit bei jedem Seitenaufruf. TYPO3s Caching-Framework neutralisiert diesen Nachteil für cached Seiten.

Häufige Probleme und Lösungen

Events erscheinen nicht in der Listenansicht. Häufige Ursache: Der Speicherordner (Storage PID) im Plugin stimmt nicht mit dem Ordner überein, in dem die Events angelegt wurden. gb_events filtert Events nach Storage PID. Lösung: Im Plugin-FlexForm den korrekten Speicherordner auswählen oder die Einschränkung per TypoScript aufheben (persistence.storagePid = 0 zeigt Events aus allen Ordnern).

Vergangene Events verschwinden sofort. gb_events blendet Events standardmäßig aus, sobald das Enddatum überschritten ist. Für manche Anwendungsfälle (Veranstaltungsarchiv, Referenzen) sollen vergangene Events sichtbar bleiben. Lösung: Die Repository-Query im Controller anpassen (vergangene Events einschließen) oder einen separaten Listenansicht-Modus “Archiv” konfigurieren.

Keine iCal-Export-Funktion. Besucher wollen Events in ihren Kalender übernehmen. gb_events bietet standardmäßig keinen .ics-Download. Lösung: Einen eigenen Page-Type für den iCal-Export anlegen. Das Fluid-Template erzeugt iCalendar-konformen Output (VCALENDAR, VEVENT, DTSTART, DTEND, SUMMARY, LOCATION). Der Aufwand liegt bei circa 3 Stunden Entwicklungszeit.

Migration und Versions-Kompatibilität

gb_events unterstützt TYPO3 v10 und v11. Für v12 existiert eine Community-Version auf GitHub, die Kompatibilität ist aber nicht vollständig verifiziert. Für v13 gibt es aktuell keine Planung.

Die Alternative für TYPO3 v12/v13 ist sf_event_mgt, die deutlich umfangreichere und besser gepflegte Event-Extension. sf_event_mgt unterstützt v12 und v13 offiziell. Wer keine Registrierungsfunktion braucht, kann sf_event_mgt ohne Registrierung konfigurieren und trotzdem die Event-Darstellung und Kalenderansicht nutzen. Der Funktionsumfang ist größer, die Komplexität aber auch.

Die Migration von gb_events auf sf_event_mgt erfordert eine Datenmigration: Die Events aus tx_gbevents_domain_model_event in tx_sfeventmgt_domain_model_event überführen. Die Felder sind ähnlich (Titel, Beschreibung, Datum, Ort), aber nicht identisch. Ein SQL-basiertes Migrations-Script erledigt das in 1-2 Stunden. Die Fluid-Templates müssen angepasst werden, da sf_event_mgt andere ViewHelpers und Variablen nutzt.

Für Projekte mit wenigen Events (unter 50 pro Jahr) ist auch eine Custom-Lösung auf Basis von tx_news denkbar: Events als News-Datensätze mit Datumsfeldern und einer Kalender-Darstellung im Template. Gosign berät zur wirtschaftlichsten Lösung und übernimmt bei Bedarf die Migration.