gb_events for TYPO3

Not every event needs registration, but every event needs a proper listing

sf_event_mgt is the standard for event management in TYPO3: registration, waiting lists, payment, attendee management. But many organizations only publish their events and don’t take online registrations. A concert calendar, a town’s events program, the schedule of an adult education center: in all of these cases, sf_event_mgt would be overkill. gb_events fills that gap with a simple event listing and calendar view, without the overhead of a full event management system.

The extension is built for organizations that want to publish dates, not manage them. No registration form, no attendee list, no payment processing. Instead, you get a clean list view, a calendar view and a detail page for each event.

Typical use cases

Municipal and parish websites. Church services, concerts, community festivals, afternoons for seniors: a typical community calendar has 20-40 events a month. Visitors want to see what’s happening when, and perhaps add a date to their personal calendar. Registration isn’t needed because the events are open to the public. gb_events covers this with minimal configuration effort.

Adult education centers and other education providers (course catalog). Course enrollment runs through an external course management system such as KuferSQL, but the program should be searchable on the TYPO3 website. gb_events shows the courses as an event list, filtered by category (languages, creative arts, IT, health) and date range. The detail page links to the external enrollment system.

Event series with recurring dates. A sports club trains on Mondays and Wednesdays, a regulars’ meetup takes place on the first Thursday of every month. gb_events displays recurring dates without anyone having to create each individual date by hand. You configure the recurrence, and gb_events generates the dates automatically.

Technical architecture

gb_events is built on Extbase/Fluid and uses its own database table, tx_gbevents_domain_model_event. Each event has the fields title, description, start date, end date, location, image, category and, optionally, a recurrence rule. Categories use TYPO3’s system categories, which makes integration with other extensions easier.

The frontend consists of three views: a list view (chronological, filterable by category and date range), a calendar view (monthly grid with clickable days) and a detail view (full event information). All views are Fluid templates and can be overridden in the sitepackage.

The calendar view renders an HTML table grid with 7 columns (weekdays) and 4-6 rows (weeks). Each cell lists that day’s events as linked titles. Navigation between months uses link parameters (GET), not AJAX. That’s SEO-friendly, because every month has its own URL that Google can index.

The recurrence logic works much like calendarize’s: a record with a recurrence rule produces virtual events. These are calculated at runtime rather than stored in the database. That saves storage but costs processing time on every page request. TYPO3’s caching framework cancels out this drawback for cached pages.

Common problems and solutions

Events don’t appear in the list view. A frequent cause: the storage folder (storage PID) set in the plugin doesn’t match the folder where the events were created. gb_events filters events by storage PID. Solution: select the correct storage folder in the plugin’s FlexForm, or remove the restriction via TypoScript (persistence.storagePid = 0 shows events from all folders).

Past events disappear immediately. By default, gb_events hides an event as soon as its end date has passed. For some use cases (an event archive, references), past events should stay visible. Solution: adjust the repository query in the controller to include past events, or configure a separate “archive” mode for the list view.

No iCal export. Visitors want to add events to their own calendars, but gb_events doesn’t offer an .ics download out of the box. Solution: create a dedicated page type for the iCal export. The Fluid template produces iCalendar-compliant output (VCALENDAR, VEVENT, DTSTART, DTEND, SUMMARY, LOCATION). This takes about 3 hours of development time.

Migration and version compatibility

gb_events supports TYPO3 v10 and v11. A community version for v12 is available on GitHub, but its compatibility has not been fully verified. There are currently no plans for v13.

The alternative for TYPO3 v12/v13 is sf_event_mgt, the far more comprehensive and better-maintained event extension. sf_event_mgt officially supports v12 and v13. If you don’t need registration, you can configure sf_event_mgt without it and still use its event listing and calendar view. You get more functionality, but also more complexity.

Moving from gb_events to sf_event_mgt requires a data migration: the events have to be transferred from tx_gbevents_domain_model_event to tx_sfeventmgt_domain_model_event. The fields are similar (title, description, date, location) but not identical. An SQL-based migration script handles this in 1-2 hours. The Fluid templates need to be adapted, because sf_event_mgt uses different ViewHelpers and variables.

For projects with only a few events (fewer than 50 a year), a custom solution based on tx_news is another option: events as news records with date fields and a calendar view in the template. Gosign advises on the most cost-effective solution and handles the migration if needed.