The symptom

A weekly event's occurrences have permalinks like /event/quiz-night-2026-09-01/, then /event/quiz-night-2026-09-01-2026-09-08/, then a third date appended, and a fourth. Eventually the slug hits the database column's limit, gets truncated mid-date, and you are left with URLs nobody can read and links that break when the series is regenerated.

What causes it

It is what happens when occurrence records are built in a loop that reuses the same working data. The code takes the base slug, appends the occurrence's date, and stores the result back into the variable it will use for the next iteration. The second occurrence therefore starts from “base plus first date” and appends its own. The third starts from that. The chain grows by one date per occurrence.

The deeper cause is writing rows straight into the posts table rather than going through WordPress's own insert function — which generates unique slugs by itself, for free, and would have made the whole problem impossible.

It is a good example of a bug that is not carelessness so much as accumulated consequence: materialise occurrences, build them in a loop, reuse a variable, bypass the standard insert. Each step is defensible; the combination produces this.

Why it matters beyond looking untidy

Those URLs get shared. They go into Facebook posts, newsletters, printed flyers and Google's index. When the series is regenerated — as it will be, because materialised occurrences have to be — the slugs change, and every one of those links 404s.

For a venue, that is customers arriving at an error page from a post advertising the night they were coming to. It is a bigger commercial problem than it looks in a bug report.

How to check whether you have it

Create a weekly event with twenty occurrences on a staging site, then look at the last few permalinks. If they are longer than the first ones, you have it. Also check the posts table directly: if there are twenty rows, you are in the materialising design and this class of bug is available to you whether or not it has happened yet.

The design that avoids it

Do not create occurrence records. One event, one rule, one permalink; the dates are worked out when the page is drawn, and an occurrence is addressed by adding its date as a parameter rather than by having its own post. There is no slug to accumulate, because there is no slug.

Exceptions — a cancelled or moved date — do become small records, but they are per exception, not per occurrence, and there are almost never more than a handful.