Please note that the importer plugin is a beta feature, this documentation is subject to change whilst the plugin is developed further.

When importing from any source, consistent and unique IDs are needed for each event or location provided to the importer so that when re-importing from the same source previously imported items can be identified and ignored or updated accordingly, preventing duplicates.

Some sources such as iCal and CSV may not provide a consistently unique ID (or any at all) and can create nuances when re-importing or syncing from the same source regularly. We’ll use iCal to illustrate two common scenarios.

IDs that change when the event or location is modified

In many cases, event IDs on iCal feeds are generated by mixing in the event dates with other unique information, meaning that any change to the date or time will change the ID. This scenario creates a nuance where the importer will not be able to identify a modified item as previously imported and therefore will create a new event or location instead of updating the previously updated event.

Unfortunately, there is no solution at the moment to prevent duplicates in these situations.

IDs that change each time you reload the feed

In some less common cases (such as older versions of Events Manager prior to 5.6.6, yes we were guilty of this too!) the event identifier changes each time the feed is loaded. This presents an issue because each time you re-import from this feed, previously imported events can’t be identified and therefore will be imported again, creating duplicates each time you run the import.

The solution in this case is to set the Ignore Source IDs? option to ‘Yes’. In this case, a unique ID will be generated by the importer based on the information provided and will remain consistent provided the event or location does not change. Should the source information change, the same issue described in the section above will occur.

The Ideal Scenario

Ideally, a feed will always provide a consistent unique ID for the event and/or the location. That way, even if the details of the event or location change, the importer can correctly find previously imported events and update the item, and ignore those that haven’t been modified at all.