ICAL UID in Event Feeds

We provide an ICAL feed of events from LiveWhale into our portal (Pathify). Pathify uses UIDs in the feed to identify unique events, so if a UID changes, it will delete the event and recreate a new one. This can be problematic because we have the ability to add event check-ins in Pathify, but if the event gets deleted, we lose that data.

So what would cause a UID to change? Looking at a LiveWhale ICAL feed, it looks like UIDs are generated from the event start date/time/ID. So in practice, if the date or time changes, the UID will change. In fact, this just happened last weekend. A last-minute time change caused a Pathify event to lose its check-in data.

Would it be reasonable for me to modify the UIDs in these feeds to prevent this? For example, would it be a problem to strip the time portion of the UID? That would at least prevent event time changes from affecting the UID.

Or would it be possible for me to generate a completely different identifier that is still unique to each event? Pathify can use a field besides UID to identify events.

Has anyone dealt with similar issues, and how did you solve them?

Hi Jon,

Hmm what an interesting puzzle. You’re right, the UIDs we published in LiveWhale-generated ICAL feeds are encoded from the event date time (in UTC format) plus the event ID and then the LiveWhale hostname. I don’t have the full backstory on that, but my guess it that we reasoned, if your event changes day/time, you want to ensure receiving feeds “grab” the updated event. (I certainly see your point of wanting that to be more universally stable though.)

I think my first-pass suggestion would be to use onWidgetFormat and try maybe adding a new criteria like $buffer['pathify_uid'] that way? You can experiment and see if stripping something from UID or etc works to your intended outcome that way?

LiveWhale IDs don’t really change unless you migrate from a LW-to-LW site (that’s why we now use url slugs, as of 2.10+) but slugs can be customized or overridden too, so I don’t think URL slug is the right choice for a uid source. Let me know how this goes or what you run into; thanks Jon!

Karl

You’re right, and I just realized this is more complicated than I thought. Pathify does not actually update event details when they change in the source, so getting an updated date/time does require events to be deleted/recreated.

So perhaps the UID is fine as-is, and we need to look at people processes to mitigate any issues.

Thanks.