Initial release.<\/p>"},"ratings":[],"assets_icons":[],"assets_banners":[],"assets_blueprints":{},"all_blocks":[],"tagged_versions":["1.0.0"],"block_files":[],"assets_screenshots":[],"screenshots":[]},"plugin_section":[],"plugin_tags":[1556,1486,87,12097,286],"plugin_category":[40,45,59],"plugin_contributors":[269929,269930],"plugin_business_model":[],"class_list":["post-393134","plugin","type-plugin","status-publish","hentry","plugin_tags-api","plugin_tags-events","plugin_tags-import","plugin_tags-the-events-calendar","plugin_tags-woocommerce","plugin_category-calendar-and-events","plugin_category-ecommerce","plugin_category-utilities-and-tools","plugin_contributors-oatsafrica","plugin_contributors-oatsafrica01","plugin_committers-oatsafrica01"],"banners":[],"icons":{"svg":false,"icon":"https:\/\/s.w.org\/plugins\/geopattern-icon\/oats-africa-event-data-migrator.svg","icon_2x":false,"generated":true},"screenshots":[],"raw_content":"\n
Oats Africa Event Data Migrator connects your WordPress site to another<\/strong> self-hosted WordPress site \u2014 a source site you already control \u2014 and pulls its event data across so it can be handed off, in a consistent shape, to an external API of your choosing.<\/p>\n\n It's built for the common case where the events \"live\" on one WordPress install (running The Events Calendar, or plain WooCommerce as a fallback), but a separate system needs a normalized feed of that data: another app, an internal dashboard, a data warehouse, anything that can accept a JSON POST.<\/p>\n\n From a The Events Calendar<\/strong> source: event details (title, description, dates, venue, organizer, cost, categories) in every status visible on your wp-admin Events screen \u2014 Published, Draft, Pending Review, Private, and Scheduled (everything except Trash) \u2014 along with each event's own status, so an import can be reconciled directly against wp-admin instead of only ever importing what's already public; ticket types and prices; and attendee records (name, email, and any custom fields the site's ticket form collects, such as phone number).<\/p>\n\n Every attendee is also matched up with the order behind their ticket, in the same spirit as the events-status handling above \u2014 a complete picture, not just the paid half of it. A ticket bought through WooCommerce is matched to its real WooCommerce order (status, total, currency, billing name\/email\/phone), covering every order status visible on the source site's WooCommerce \u2192 Orders screen (Pending, Processing, On hold, Completed, Cancelled, Refunded, Failed \u2014 everything except Trash), not only completed ones. A free RSVP<\/strong> \u2014 which has no checkout step and so no real WooCommerce order to find \u2014 instead gets an order built automatically by this plugin: cost From a WooCommerce<\/strong> fallback source: product details treated as events (best-effort field guessing, since WooCommerce has no built-in \"event\" concept), and the orders placed against each product, in the same An optional \"skip details\" mode is available for faster imports that fetch just the top-level event\/product list, without the extra ticket, attendee, or order data.<\/p>\n\n The admin screen's per-event breakdown and Last Import summary are built to make an import checkable at a glance rather than something you have to take on faith: a Status column on every event, a running total of orders fetched from WooCommerce versus how many are actually linked to an event (split further into paid vs. RSVP-generated), and explicit warnings whenever a fetch fails partway through or a paid order can't be matched \u2014 instead of a partial result that silently looks the same as a complete one.<\/p>\n\n This plugin moves data between two systems you control the configuration of: a source WordPress site, and an external API. Please read this section before activating it on a live site.<\/p>\n\n What is retrieved from the source site:<\/strong> event details, and \u2014 unless you enable \"skip details\" \u2014 ticket, attendee, or order records. Attendee and order records can contain real personal data: names, email addresses, and any custom fields a ticket form asks for (for example, a phone number). Not every order record is retrieved from the source site as-is \u2014 a free RSVP attendee has no real WooCommerce order behind it, so this plugin generates a zero-cost stand-in order for them (see the FAQ above) using the attendee's own name\/email; it is otherwise treated the same as any other order record for privacy purposes. This data is retrieved using the WordPress Application Password you provide, which is scoped to whatever that WordPress user account is permitted to see on the source site.<\/p>\n\n What is sent to the external API:<\/strong> the same normalized data, in a single batch, whenever you click \"Import Now\" and a destination endpoint is configured. There is no background or scheduled sending \u2014 every send is a result of an explicit admin action.<\/p>\n\n What is stored locally, on the site this plugin is installed on:<\/strong>\n* The source site connection details (site URL, username, and an encrypted Application Password).\n* The external API destination (endpoint URL and an encrypted API key).\n* A record of the most recent import (timestamp, counts, success\/failure) for the admin screen's status display.\n* If no API destination is configured yet, the most recent import's full normalized payload \u2014 including any personal data it contains \u2014 saved as a temporary WordPress transient that expires automatically after 24 hours. This exists purely so you can inspect what an import produces before wiring up a real destination.<\/p>\n\n What this plugin does not do:<\/strong> it does not send data to Oats Africa, to any Oats Africa service, or to any third party other than the exact API endpoint you configure yourself. It does not phone home, collect telemetry, or make any outbound request other than to the source site you connect and the API endpoint you set.<\/p>\n\n Because personal data can pass through this plugin, treat both the source site's Application Password and the destination API key with the same care as any other credential, and make sure the destination API itself handles the data you send it appropriately (encryption at rest, access controls, and a retention policy) \u2014 this plugin's job ends once the data leaves your server.<\/p>\n\n Uninstalling the plugin deletes all of the above from your database, including the encrypted credentials and any pending dry-run payload.<\/p>\n\n\n No. Nothing leaves your site until you explicitly configure both a source connection (Application Password) and, separately, an external API endpoint and key. Before an API destination is configured, imports run in dry-run mode: the plugin fetches and normalizes data from your source site, but only saves the resulting payload locally (for 24 hours) rather than sending it anywhere.<\/p><\/dd>\n Once configured, it sends whatever the connected source site returns for events, and \u2014 unless \"skip details\" is enabled \u2014 the associated tickets, attendees, or orders. That can include personal data: attendee or customer names, email addresses, and any custom fields a ticket form collects (e.g. phone numbers). See \"Privacy\" below for full details.<\/p><\/dd>\n Your source site's Application Password and your external API key are encrypted before being saved to the WordPress database, using a key derived from your site's own WordPress secret keys (the ones already in The source site does not need this plugin installed. It only needs The Events Calendar or WooCommerce active, and its REST API reachable (the WordPress REST API is enabled by default), plus an Application Password for an account with permission to read the relevant data.<\/p><\/dd>\n Detection reports that no supported source was found, and imports won't run until one of those is active on the source site.<\/p><\/dd>\n That's expected, not a bug. A free RSVP has no checkout step, so there's no real WooCommerce order behind it to fetch \u2014 this plugin builds one automatically instead, so the attendee still has an order on record on the receiving side, rather than being the one type of attendee with nothing associated with them. Its How it works<\/h4>\n\n
\n
What gets imported<\/h4>\n\n
0<\/code>, an order id this plugin generates (so it can never collide with a real WooCommerce order number), and a source<\/code> field of rsvp<\/code> (versus woo<\/code> for a real order) so the two are easy to tell apart downstream. Because a free RSVP has no separate \"billing\" step the way a WooCommerce checkout does, its generated order's first_name<\/code> field carries the attendee's whole display name rather than a properly split first name, with last_name<\/code> left empty.<\/p>\n\ntickets<\/code>\/attendees<\/code> shape a The Events Calendar import uses. On a site where The Events Calendar and Event Tickets Plus are also active, some \"products\" are really just ticket SKUs for a TEC event rather than real products \u2014 these are still included rather than silently dropped, but with their event-shaped fields (title, dates, venue) left empty since a ticket product genuinely doesn't carry that information; the ticket's own name and price appear correctly in its tickets<\/code> entry instead, and its buyers still populate attendees<\/code>.<\/p>\n\nRequirements<\/h4>\n\n
\n
Privacy<\/h3>\n\n
\n
\/wp-content\/plugins\/oats-africa-event-data-migrator<\/code>, or install the plugin through the WordPress admin's Plugins \u2192 Add New screen.<\/li>\n\n
Does this plugin send my data anywhere by default?<\/h3><\/dt>\n
What data does this plugin send to the external API?<\/h3><\/dt>\n
Where are my credentials stored?<\/h3><\/dt>\n
wp-config.php<\/code>). They are never displayed back in the admin screen once saved, and are deleted entirely when the plugin is uninstalled.<\/p><\/dd>\nDoes this work with any WordPress site as a source, or does the source site need this plugin too?<\/h3><\/dt>\n
What happens if the source site has neither The Events Calendar nor WooCommerce?<\/h3><\/dt>\n
Why does an order show up with a status of \"rsvp\" and a cost of 0 \u2014 I can't find it on the WooCommerce Orders screen<\/h3><\/dt>\n
source<\/code> field reads rsvp<\/code> (a real order's reads woo<\/code>) specifically so it's easy to tell the two apart; there's nothing to go looking for on the source site's Orders screen, because it was never a WooCommerce order in the first place.<\/p><\/dd>\n\n<\/dl>\n\n\n1.0.0<\/h4>\n\n
\n
source<\/code> of rsvp<\/code> versus woo<\/code> for a real order \u2014 so every attendee has an order on record rather than the RSVP ones having nothing associated with them.<\/li>\n