In part one of this series I looked at using ruby-wpdb to access a WordPress database from Ruby. In part two, I gave some examples of how you might achieve some common tasks with ruby-wpdb. Now, in part three, I’m going to look at some plugin-specific functionality that ruby-wpdb provides: integration with Gravity Forms.
Gravity Forms is a hugely popular add-on for WordPress which gives you, in essence, a way to create custom forms, displayed on your website, that store the data submitted to them. But they can be much more powerful than that: they can giving you integration with CRM systems, communicate with payment gateways like PayPal, register users for your site, and more — cutting a lot of the CRUD drudge work out of adding new functionality to your WordPress site.
One of the drawbacks of Gravity Forms’ flexibility, though, is that its database structure has to be very abstract to cope with the infinite variety of form structures you might throw at it.
If you want to look at entries, then, you’re required to construct hefty
database queries containing large numbers of
JOIN statements, one for
each field in your table. For example, to fetch the entries in a typical
contact form, you might have to write the following query:
That’s just for a relatively simple four-field form; already things are getting hairy, and it’s clear that things are only going to get more painful from here on in.
ruby-wpdb approaches this by modelling GravityForms entries as though they were first-class data structures, the sort of thing that normally get their own database tables.
So, it gives you a class for each of your forms, allows you to query for entries based on whatever criteria you like, and allows you to access fields as though they were regular properties.
Let’s take a look at how you can use this.
Accessing your forms
For each of your forms, ruby-wpdb creates a model. Models are named after your form, with non-alphanumeric characters removed, leading numbers removed, and CamelCased. So, some sample transformations would be:
Contact Form => ContactForm Rob's signup form => RobsSignupForm Form #2 => Form2 1. Registration => Registration
…hopefully you get the picture from there!
These classes are within
WPDB::GravityForms, so the “Contact Form”
example above would be accessible as
Just like ruby-wpdb allows you to do with posts, comments, and other objects, you can filter entries to your forms by whatever criteria you like.
So, sticking with our contact form example, you might want to filter
based on who the messages are from. To print all of the messages that
email@example.com, then, you could write:
You can also filter on data attached to the lead itself. For example, to fetch only messages sent in 2013, you’d simply call:
ruby-wpdb will take care of mapping fields to properties for you. You
can see that above; we were able to filter on a property called
ruby-wpdb names these fields according to the labels they have within
GravityForms: so, if your field is called “First name:”, this becomes
first_name; if it’s called “Email” it becomes
So, to completely display the last five entries from our contact form, we could use the following code:
That’s it! You can obviously combine this with the filtering to drill down into your GravityForms data, pulling out only the specific fields from only the specific entries that you want.
Hopefully this illustrates how ruby-wpdb can help make exploring and analysing — or just exporting — your GravityForms data a cinch.
It’s something I find myself doing a lot. I either want a quick insight into data and don’t want to write something and deploy it to the live site; or else I want to examine something in detail, and don’t want to slow down the live site while I’m running it; or else I want to run it regularly on a cron job, and don’t want the overhead of the whole website with it.
In those situations, and lots more I’m sure, ruby-wpdb’s GravityForms functionality can help make your life a little bit easier.