Gravity Forms and Pro Sites integration

Alright, let’s do this thing.

I’ve seen a lot of comments on Gravity Forms and Pro Sites integration on these forums; alas, no solution has been provided.

I feel this is an important feature to have since this integration can be bound to many other products for future integration. Just like Zapier has done with many products, this also can be recreated for different subjects.

Unfortunately, no documentation is to be found regarding this subject. So let’s make our own here.

All related topics are over a year old so they can be rendered irrelevant.

Any comments regarding this integration will be highly appreciated, especially from the WPMU staff to confirm my way of thinking to help with this integration. I do not expect the WPMU staff to give values and code because they’re as they call it: support – and not 24/7 code dummies.

So, before I digress any further, here are the problems, the order is not important:

1. Pro Sites has bound to its own payment systems, like Credit Card, Stripe and PayPal (pro/express). In many countries outside of the USA the Credit Card isn’t well accepted and we have other means of payment. I myself use the Pronamic iDeal plugin for payments which works great for my target customers: Dutch people.

2. The Pro Sites gateway is too complex to alter, therefor we must find other means for integration, see 3. for elaboration.

3. WHMCS Provisioning is a great tool, unfortunately, you’ll be bound to the restricted WHMCS API which requires a WHMCS license and installation, which both will be far too complex to work with. Also, you’ll be working with 2 different account systems which both have their own way of password handling, therefor this will be too complex for our users and we do not want to work with WHMCS.

4. Pro Sites has undocumented values for the WPMUdev developers to work with, and we have to figure out what they do and when to call them. Luckily the Database entries are easy to understand.

5. Gravity Forms is a great tool, unfortunately, their documentation is also limited and complex.

6. Customization is awesome: Having your own workflow and user interaction/engagement is extremely important. Therefor, having your own forms are needed. Gravity Forms provide a lot of customization and integration and this is exactly what we need.

Many more points can be written down here as a problem but I think you’ll get the picture.

To tackle this problem, let us “steal” the code from integration services provided by the WPMUdev team, yes, I’m looking at you WHMCS Provisioning.

From whmcs-mrp.php:

$ch_blog = $wpdb->get_row("SELECT blog_ID FROM " . $wpdb->base_prefix . "pro_sites WHERE blog_ID=$id LIMIT 1");


$wpdb->query($wpdb->prepare("UPDATE " . $wpdb->base_prefix . "pro_sites SET level=%d WHERE blog_ID=%s", $level_id, $id));

$psts->record_stat($id, 'upgrade');

} else {

$wpdb->query($wpdb->prepare("INSERT INTO " . $wpdb->base_prefix . "pro_sites (blog_ID, expire, level, gateway, term) VALUES (%d, '9999999999', %s, 'WHMCS', 'Permanent')", $id, $level_id));

$psts->record_stat($id, 'signup');


What we can read from this code is that wp_pro_sites gets new values, those values are:

1. blog_ID (Binds to signup blog ID)

2. level (Binds to predefined level)

3. expire (UNIX timestamp)

4. gateway (How did the user get its term? We could define these in terms like GFregister and GFextend for support reference, these terms aren’t “important” to function)

5. term (I think this has to do with extending, but we’re focusing on registration now)

6. amount (let’s just leave this blank for now)

The problem is, that when a user registers (and pays) the blog_ID isn’t defined yet. This is still under testing for confirmation and I will tackle this further.

HOWEVER, we can take the blog_ID from the Gravity Forms registration code and let Gravity Forms handle the process of putting everything in the database. In other words: We put everything in one nice packet so when the registration is complete, the values will be the same.

When the code is completed, we’ll tackle this when bugs occur.

Another problem might be updates, shall we put this in a new .php file or integrate this into the Gravity Forms code? I’ll leave this question unanswered for now, however it might be best to save the integration code elsewhere if an update might occur.

OK, now let’s look at userregistration.php from Gravity Forms.

We have this little code right here (line 4067):

$blog_id = wpmu_create_blog($site_data['domain'], $site_data['path'], $site_data['title'], $user_id, $meta, $current_site->id);

Somehow, we need to implement the Pro Sites code into this.

We could solve this in a few different ways, but what is most important is that Gravity Forms can act upon the Pro Sites code.

What we need is the following in Gravity Forms:

1. Subscription choice: Be it Free (0), Basic (1), Pro (2), Business (3), etc. (4+)

That will be like this, (it’s Dutch, where Waarde = Value):

1.a) A function to call those values (I’m still fuzzy on this one).

2. The period (experation date), and alter it to UNIX timestamp format:

We need to get those values, and bind it to a query that fires together with the blog creation. Where the blog_ID and everything thereafter will be put into the wp_pro_sites database.

Note that for correct pricing per Pro Sites level, you’ll need conditional forms with those options and price per period (month/3months/year/etc).

Luckily, we do not need to duplicate the “time values” so you’ll probably just put in ‘month’, ‘3months’ and ‘year’ for each time period with their own pricing per Pro Site level.

And then we’re done. It’s not that hard. We just need to find the right way to implement this.

I will continue on this project for the upcoming days, for now, I have an appointment. Any input will be extremely appreciated.