Recurring Events Are Where Plugins Break

A Tuesday-night pottery class runs every week for a year. Week fourteen, the studio needs the room for a private booking, so that one session moves to Thursday. Week twenty-two, the instructor is out sick and the class is skipped entirely. Week thirty, a new venue opens across town and the class relocates there for the rest of the run.

None of that is unusual. It’s what actually happens to a “simple” weekly series once it meets a real calendar. And it’s exactly the point where a lot of WordPress event setups start to creak, because most of them were built to solve a much smaller problem: showing one event on one page.

A series is not the same as a pile of copies

The easy way to build recurring events is to generate a separate post for every occurrence the moment the series is created. Fifty-two posts for a year of weekly classes, sitting in the database like fifty-two unrelated events.

It looks fine on day one. It breaks the moment anything about the series needs to change. Rename the class, and now you’re editing fifty-two posts by hand, or writing a bulk-update query and hoping nothing else references those posts individually. Change the venue for the whole run, same problem multiplied by every occurrence.

The alternative is a model where the series is the actual record, and each date is a computed occurrence of that record, with room for individual dates to override the pattern when they need to. That distinction, series versus copies, is invisible when everything is going smoothly and expensive to fix after the fact if you picked wrong.

The moment one occurrence needs to be different

Every recurring series eventually needs an exception. A single date changes venue. A single date gets cancelled without cancelling the whole series. A single date runs at a different time because the room isn’t free at the usual slot.

This is where the “pile of copies” approach actually turns out to be fine for the entity itself, since each occurrence already had its own record, and where a naive “one record generates everything on the fly” approach falls over, since there’s nowhere to attach the override. You end up needing both things: a pattern that generates the regular occurrences, and a way to say “this specific date is not the pattern, it’s an override” without breaking the rest of the series.

If your event plugin can’t express “week fourteen moved to Thursday” without either deleting the whole series and starting over, or manually faking a one-off event that has no connection back to the series, you’ve found the gap. It usually doesn’t show up in a demo. It shows up in week fourteen.

”Edit all future occurrences” is where the data model leaks

Most event tools that support recurrence eventually offer some version of “edit this event” versus “edit all future events in this series.” That single choice is doing a lot of quiet work.

Editing all future occurrences has to decide what “future” means relative to occurrences that have already been individually overridden. If week fourteen was moved to Thursday and week twenty-two was cancelled, does an “edit all future” action from week ten steamroll those exceptions, or respect them? There isn’t a universally correct answer, but there is a correct expectation to set: the organizer should be told, not surprised. A plugin that silently reverts your manual fixes the next time you touch the series description is a plugin whose recurrence model wasn’t built with exceptions in mind from the start, only bolted on afterward.

This is also where you find out whether “the series” is a real object in the system or just a label applied to a batch of otherwise ordinary events. If it’s just a label, “edit all future” is guesswork dressed up as a feature.

RSVPs per occurrence, not per series

A monthly meetup with forty regular attendees doesn’t have forty people who RSVP to “the meetup” as an abstract concept. It has forty people who RSVP to specific dates, and the numbers move: thirty-five for the regular slot, twelve for the one that got moved to a weeknight, zero for the one that got cancelled.

If RSVPs live at the series level instead of the occurrence level, that distinction disappears, and organizers lose the one number they actually need before ordering catering or setting up chairs. Per-occurrence RSVP tracking, including waitlist behavior when a specific date fills up, is what makes recurring events usable for anything with a headcount attached rather than just a listing that repeats.

The same logic applies to attendance data after the fact. “How many people came to the Tuesday class” is a per-occurrence question. A system that can only answer “how many people are signed up for the class” in general is answering a different, less useful question.

The ICS feed people subscribe to once

Recurring events don’t stay inside your website. Someone finds your weekly class, clicks “add to calendar,” and their phone subscribes to an ICS feed once. From that point on, every change to the series has to propagate through that feed correctly, or their calendar quietly drifts out of sync with reality.

A moved date needs to move in their calendar app, not just on your event page. A cancelled occurrence needs to show as cancelled, not silently vanish while their phone still reminds them to show up. This is the practical test of whether the series-with-exceptions model actually works end to end: does a change made in the WordPress admin reach a calendar app that already subscribed weeks ago, or does it only update the page a visitor happens to reload.

If you’re publishing anything with more than a handful of dates, this is worth checking before you commit to a plugin, not after your regulars start showing up on the wrong day.

Why this matters before you build anything

Recurring events are one of the areas where a plugin’s free-versus-paid split tells you something real about how it was built, not just how it’s priced. Several tools that get recurring series right hold that capability back for a paid tier, which is a reasonable business decision but also a signal that they consider it the harder, more valuable piece of the system. In Eventonomy, recurring events, including per-occurrence overrides, ships in the free plan alongside RSVPs and the ICS feed, because a series that can’t handle its own exceptions isn’t really a series.

None of this is an argument for a specific tool over another in the abstract. It’s an argument for asking the right question before you set up a weekly class, a monthly meetup, or a recurring workshop: not “does it support recurring events,” but “what happens the first time one occurrence needs to be different.” If you’re comparing options for a WordPress site, our event plugin overview and the free versus pro breakdown go through what’s included at each tier. If you’re specifically running a regular meetup, the meetups page covers the parts of this that come up most in that context.

Set the series up expecting exceptions, not hoping to avoid them. Week fourteen always comes eventually.