Wiederkehrende Termine in WordPress sauber abbilden

Das Problem im Datenmodell

Die meisten Plugins speichern Recurring Events nicht als Serie mit Exceptions, sondern generieren beim Speichern X einzelne Posts. Konsequenz: 52 Datenbankzeilen für einen wöchentlichen Termin, jede Änderung an der Serie muss durch alle gehen, und wenn du einen einzelnen Termin verschiebst, weiß die Serie nichts davon.

Was richtige Recurring Events brauchen

• Eine Serie als ein Objekt — definiert durch eine Regel (z. B. RRULE nach iCalendar/RFC 5545).
• Exceptions als Override — einzelne Instanzen können verschoben, abgesagt oder inhaltlich verändert werden, ohne die Serie zu zerstören.
• "Bearbeiten ab hier" — eine Änderung gilt für alle künftigen Termine, ohne die Vergangenheit zu manipulieren.
• Ticket-Bindung pro Instanz — Tickets müssen sich auf eine konkrete Instanz beziehen, nicht auf die Serie.
• iCal-Export, der stimmt — eine Serie als VEVENT mit RRULE, Exceptions als EXDATE / Override-VEVENT.

Wie PulseWP das löst

PulseWP speichert eine Serie als ein Datenobjekt mit RRULE-konformer Regel. Jede Abweichung wird als Exception gespeichert — entweder als Verschiebung, Absage oder Override mit eigenem Inhalt. Beim Speichern fragt PulseWP, ob die Änderung für diesen Termin,ab hier oder die ganze Serie gelten soll. Genau wie Google Calendar es seit Jahren tut — und wie WordPress-Plugins es seit Jahren nicht tun.

Praktische Folgen

• Eine Serie über 5 Jahre = 1 DB-Zeile statt 260
• Ladezeit auf der Kalenderseite bleibt stabil
• Sauberer iCal-Export, der in Apple Calendar und Outlook korrekt rendert
• Tickets pro Instanz, keine Doppelbuchungen über Serie hinweg

Nächste Schritte

PulseWP ist im Pre-Launch — die ersten 25 Founding-Member bekommen die volle Lizenz für 99 € einmalig und Einfluss auf die Roadmap. Vergleich mit anderen Plugins: WordPress Event-Plugins 2026 oder Eventkalender im Direktvergleich.