What stays behind
Catalogue files do not contain attendees, payments or financial history. Images and attachments are also excluded, so personal records and uploaded files are not moved as part of a catalogue transfer.
Referenced parent listings and groups must already exist at the destination. An import is rejected if its name is already in use or its data does not match the supported format, and the page names the field at fault.
Moving attendees and payment history needs a full database backup rather than a catalogue file.
Example
An organiser runs a "Summer Sessions" group of six workshops on a
self-hosted copy of Chobble Tickets and decides to move to Chobble's
managed hosting. They choose Export on the group's page and download a
.json file named after the group. On the new site they choose Import
under Groups and upload the file, and the group and its six listings
are re-created with the same prices. The move works the same way in the
other direction, or to any other host running Chobble Tickets.
Why names, not numbers
The file joins listings, groups and parents by name rather than by
internal number. Numbers differ from one site to the next, while names
survive the move. Each file carries a format version, so a file from an
incompatible version is refused rather than loaded wrongly.
Checked before changes are made
Chobble Tickets validates the complete file before applying it. The import is atomic, which means a failed import does not leave part of a listing or group behind.
Import from markdown frontmatter
Catalogue content does not have to start as JSON. It can be kept as
markdown frontmatter in a repository and imported through the command
line. That suits a catalogue that is versioned and edited alongside the
site's source.
For copies within one site, bulk event management can duplicate a group and shift all its dates. CSV export covers attendee, listing and calendar reports rather than reusable event setup.