Integrating Eventbrite with WordPress using Pods CMS
If I wasn’t so busy putting on a conference, I might have gotten around to this earlier. :)
As part of our partnership with Eventbrite, I wanted to walk you through our site’s integration with their ticketing system. I’m proud of both our work and the individuals who volunteered their time to make it happen. So let’s get started!
The Problem
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. And despite our recent issues with PayPal, we’ve never had a problem with Eventbrite. In fact, they are one of our sponsors this year!
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.
The Solution
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.
What is Pods CMS?
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!
The selling point for using this plugin was the local presence of its principal developer Scott Kingsley Clark. Funny, dedicated, and way too smart for his own good, Scott is a frequent speaker on the WordCamp circuit — including last year’s WordCamp Dallas. I met him at the 2009 event and knew I wanted to work with him down the line. This was the perfect opportunity.
Scott graciously volunteered his time with design, programming, testing, and consumption of vast quantities of Monster Energy Drink. Thank you again for everything, Scott!
So, let’s get into the details of our integration with Eventbrite.
The Execution
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:
Specifically, 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. I think you may know where I’m going with this: yep, another Pods Page. 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.
Wrapup
That’s the basic gist. If anyone is interested in seeing this code in-depth, let me know at OpenCamp and I’ll walk you through it. In the meantime, stay tuned for the next part in this series, where Scott and I walk you through how Pods CMS is used for defining speakers and scheduling sessions.
Twitter Comments
|
|
| Re-Tweet | Reply | View Tweet |
|
|
|
| Re-Tweet | Reply | View Tweet |
|
|
| Re-Tweet | Reply | View Tweet |
|
|
| Re-Tweet | Reply | View Tweet |
|
|
| Re-Tweet | Reply | View Tweet |
|
|
|
| Re-Tweet | Reply | View Tweet |
|
|
| Re-Tweet | Reply | View Tweet |
|
|
| Re-Tweet | Reply | View Tweet |
|
|
| Re-Tweet | Reply | View Tweet |
|
|
| Re-Tweet | Reply | View Tweet |
|
|
| Re-Tweet | Reply | View Tweet |
|
|
| Re-Tweet | Reply | View Tweet |
|
|
| Re-Tweet | Reply | View Tweet |
|
|
|
| Re-Tweet | Reply | View Tweet |
|
|
|
| Re-Tweet | Reply | View Tweet |






































