Matthew “Spamboy” McGarity began blogging in 2003 in an effort to entertain his friends and chronicle their many adventures together. These stories have been collected on his website, an ongoing, ever-updated autobiography powered by WordPress and a custom theme. Matthew recently posted an excellent entry on integrating Eventbrite with WordPress using Pods CMS (in association with the OpenCamp web conference). He’s graciously allowed us to excerpt his post here:
OpenCamp was borne out of several events, including WordCamp Dallas. For the past two years, Eventbrite was employed as the WordCamp Dallas ticketing system for several reasons: simple interface, ease of use, efficient handling of merchant processing, and nominal cost.
While Eventbrite was great for the actual ticketing, extracting information was a different matter. We like displaying a list of attendees on our website, but in the past we had to manually pull data from Eventbrite, then manually copy it to our website. This was because we were running the WordCamp Dallas site on the WordCamp.org server, over which we had no control.
The move to OpenCamp meant we would be self-hosting. We now had the opportunity to automate this manual process. And with OpenCamp expecting to more than double last year’s WordCamp attendance, manual was completely out of the question.
We briefly considered implementing our own custom ticketing system, but we didn’t have time. Besides, it would have been alot of wheel-reinventing. We quickly returned to Eventbrite for two reasons:
- Familiarity: two years running, why quit a good thing?
- API: discovery of a robust, well-documented API we could use to extract data from the backend
Although there are several Eventbrite-related WordPress plugins, none met our needs to pull attendees into the system and display them on the website. So we knew we’d have to go custom — but we didn’t want to get bogged down. Whatever we designed had to go live quickly. And this is where Pods CMS came in.
Pods CMS is a powerful plugin that enables quick deployment of CMS functionality within WordPress. If you need to store custom data outside of the core WP Post structure, Pods CMS is your ticket. Our intention was to use its capabilities to create custom WP tables to store attendees, the tickets they registered with, and the answers they provided to our questions (t-shirt size, Twitter handles, and so forth). If you want power with quick implementation, this plugin is a must-have. I cannot recommend it enough! So, let’s get into the details of our integration with Eventbrite.
Our first step was getting attendees pulled into our local database, where we could leverage displayed their data on our website. If you go to our Attendees Page, everything you see is being displayed using the Pods CMS plugin.
We started by building tables to hold our data. Doing this in Pods CMS is easy: log into the WordPress admin panel, navigate to the Pods CMS Setup menu, and add what are called Pods. A Pods is a logical data structure which, when saved, creates a matching table in the WP database. You define what fields you want, their data types, relationships to other Pods, plus more.
We started off with three Pods:
- Ticket: this Pod holds the various ticket types sold on Eventbrite. These types allow us to determine who registered as a Business vs. Student, etc.
- Attendee: this Pod holds the actual individuals who have registered for OpenCamp
- Attendee Answer: this Pod holds the answers to the questions we asked upon registration
To determine what fields to include on each Pod, we consulted the Eventbrite API documentation. For example, we use the event_list_attendees method to extract the current registrants. The result of this call is an XML file containing various elements, all of which are listed in that method’s documentation. Therefore, any element in the XML became a Pods field (so we have a one-to-one match). Here’s a screenshot of a portion of the Attendees Pod to illustrate:
Once the Pods tables were built, the next step was pulling data from Eventbrite into the OpenCamp database. Once again, we turned to Pods CMS.
One great feature of Pods CMS is the ability to create Pods Pages. A Pods Page is like your standard WordPress Page — it has a URL you can navigate to, and it can use your theme files to display content. The purpose of a Pods Page is to execute Pods code, usually for display in-line with WP Page content or standalone. In our case, our Pods Page contains the end-to-end code for pulling attendees. Here’s a portion of that setup:
It calls the Eventbrite API, causing Eventbrite to publish XML messages, which is then received, parsed, and stored in those three Pods tables mentioned earlier. New attendees are inserted, while existing attendees are updated with the latest Eventbrite data (in case of post-registration updates). And thanks to the magic of wp-cron utilized within one of Scott’s plugins called Crony Cronjob Manager, this Pods Page executes “automagically” at regular intervals, keeping our database constantly up-to-date. I love it more than bacon!
The final step was to get our fabulous attendees to display on the website. We created a Pods Page and included code to select from the Attendees Pods and display according to their ticket type. To control displaying Business attendees differently than Individual attendees, we turned to two additional Pods CMS features: Helpers and Templates. The Templates are reusable bits of codes with placeholders for data to be plugged in, while Helpers are similar to PHP functions in that they perform specific tasks and can return values after being called. The combination of all this displays attendees in order of ticket type and registration date, adding hyperlinks and icons depending on the answers to the Eventbrite questions. And that’s the basic gist!