Gravity Forms as a Platform – An Introductory Tutorial

It’s easy to see how powerful Gravity Forms is out of the box for creating forms, surveys, polls and quizzes on WordPress and analysing the results. What’s not so immediately clear is how extensible it is under the hood. This introduction to the Gravity Forms developer platform demonstrates some best practices for creating add-ons for Gravity Forms and helps prepare developers to build form-based applications on WordPress.

Gravity Forms is evolving. Since the release of version 1.0 in August 2009 it quickly became the leading commercial form-building plugin for WordPress. Now, according to analysis by Datanyze, it’s being used on more sites in the Alexa top 1M than all the other form-builder tools in its list put together.

gravityformsmarketshare

 

Comparisons like these, of course, can be a bit misleading, not least because there’s an important difference between Gravity Forms and the other technologies on their list. Gravity Forms is installed and runs entirely on the host server, whereas the others embed the form on the page in a relatively superficial way so the processing and storage has to be performed externally. This means that Gravity Forms can be customised, extended and integrated in ways the others can’t and perhaps this advantage puts it into a different category altogether.

With over one million WordPress sites running Gravity Forms, there’s already a sizeable install base and a healthy ecosystem is emerging of third-party developers providing high-quality add-ons, themes, mobile apps and custom line-of-business solutions. If the feature requests from customers are anything to go by there’s plenty of room for new ideas and growth.

In response to this dramatic growth, at Rocketgenius, the company behind Gravity Forms, we’ve been working very hard over the last couple of years to consolidate on this early success with a laser-like focus on stability, scalability and extensibility. The tools we’ve been building provide the common foundation for the development of all our 17+ add-ons and simplify their maintenance. Essentially what we’ve built is an application framework for WordPress and now we’re engaging with third-party developers and end-customer IT departments and helping them use Gravity Forms as a platform for their own projects.

Since the release of version 1.8, Gravity Forms now has the following tools as part of the developer platform:
Actions and Filters
- A Framework for Add-On development
- API Functions which provide programmatic access to the Forms and Entries on the local Gravity Forms installation.
- Web API (and the Web API PHP Wrapper) providing secure remote access to Gravity Forms

gf_app_platform

 

In this introduction, I’ll be bringing together all these tools into a single tutorial - the development of an add-on – primarily to give a sense of what can be done and the best way to approach it. I’ll be assuming at least a little experience with Gravity Forms and reasonable familiarity with PHP. The inline comments in the code are intended to be read as part of the tutorial.

Some preliminary analysis

Let’s briefly run through the analysis phase and list some requirements for the add-on.

Use Case A

A marketing analyst in the head-office of a national organisation is responsible for analysing the all submissions of the same customer satisfaction survey installed on multiple regional sales sites. The analyst needs the aggregate results in real-time. However, the regional representatives only need access to the local entries and results on the site for which they are responsible.

Use Case B

A database Backup is scheduled nightly but there have been some availability issues recently with the backup service. Form submissions must be backed up to a server at a different location which is kept ready to be promoted should the production site fail.

Use Case C

The form submissions from a quiz evaluating patients’ mental health contain sensitive information and must not be collected on the public site – all information must be stored and analysed on an internal server which follows strict legal procedures and has a high level of security. The firewall is configured to allow the public site to communicate with the internal site.

Use Case D

The staging site data needs to be kept in sync with the production site.

Requirements

Now we know what the solution should involve we can list some basic requirements for the add-on.

  • Form submissions (entries) should be sent to a remote Gravity Forms installation for storage (aggregation)
  • Aggregation will be activated by the local administrator on a form-by-form basis.
  • Entries will be optionally deleted after sending to the remote site.
  • If the form doesn’t exist on the remote site the add-on will create it.
  • The add-on will allow the central site admin to activate a results page and the results page should allow results to be filtered by site

So we’ll need to extend Gravity Forms in the following steps:

  1. Create an add-on that uses the Add-On Framework
  2. Add a tab in the Gravity Forms Settings page to collect the API credentials for the remote site and activate the results page
  3. Add a Results Page
  4. Add a tab in the Form Settings with options to activate aggregation and delete entries.
  5. Add a custom Entry Meta field to the Entry Object and store a site identifier so the results page can filter the entries by site
  6. During Initialisation, hook into the appropriate action to execute our code after the form has been submitted
  7. Use the Web API to store the entry on the remote site
  8. Use the API Functions to delete the local entry

Step 1: Extending the Add-On Framework

The first thing we need to do is create an empty class for the add-on. We could of course create an independent class of our own but by using the Add-On Framework we get a big help with the following:

  • Add-On Initialisation and executing code at the right points
  • Enforcing a Gravity Forms minimum version requirement. Gravity Forms, in turn, enforces a minimum version requirement for WordPress.
  • Creating settings pages (add-on and form settings) with a complete Settings API
  • Granular, role-based, permissions and integration with the Members plugin
  • Conditional script enqueuing including automatic support for the no-conflict mode in Gravity Forms which helps prevent conflicts with other plugins installed on the server
  • Adding custom meta fields to the entry object
  • Creating form feeds – A feed is a user-configurable action that gets conditionally processed after a form is submitted.
  • Displaying charts and filtering results
  • Integration with the Gravity Forms Locking API (using the WordPress Heartbeat API to handle control requests between concurrent users)
  • Standardisation of UI elements and styles
  • Automatic clean uninstall (all form settings, add-on settings and entry meta are removed automatically)

To use the Framework and get access to all these features we need to create WordPress plugin file and add a class that extends GFAddOn. If you’ve not built a WordPress plugin before, please take a quick look at the section on “Creating a Plugin” on the WordPress Codex.

The Add-On Framework requires some class variables to be configured.

Step 2: Add-On Settings

We need to add a settings page for the add-on that will allow the administrator to do three things:

  1. Activate and deactivate the results page
  2. Configure the connection details for the central server: URL, API Key and Private Key.
  3. Specify a custom string that will be used to identify the site on the results page on the central server

To create a settings page for an add-on override GFAddOn::plugin_settings_fields() and return an array with the configuration of the fields. The Add-On Framework will handle the rendering of the fields and also the storing and retrieval of the settings. The Settings API is fairly extensive so for further details of all the available options please check out the Settings API section of the documentation for GFAddOn.

The above code will generate the following settings page:

aggregator-settings

Add-On Settings

Step 3: The Results Page

A results page can be added in Gravity Forms with just a couple of lines of code. Override GFAddOn::get_results_page_config() and return the configuration array for the results page. In this case, we just need to set the title.

This will display the results page in the menu:

aggregator-results

Results Page

On the central site, the results page will be able to filter entries by site. Here are the entries from SiteA and SiteB respectively.

aggregator-site-a

aggregator-site-b

Step 4: Form Settings

Next let’s add some form settings so the administrator can activate remote aggregation on a form-by-form basis. Again, the Add-On Framework will handle the rendering of the page and the storing of the settings and the full details of all the available options can be found in the documentation for the Settings API.

This produces Form Settings for our add-on like this:

Aggregator_‹_Forms_‹_WP2_—_WordPress_—_WordPress

 

Step 5: Entry Meta

We’ll also need a way to identify the entries from each site so let’s add a custom property to the Entry object called gf_aggregator_id and update it with the value specified in the Site ID add-on setting. Entry Meta fields are added either by hooking into the gform_entry_meta filter or alternatively, by activating the Entry Meta feature of the Add-On Framework, and overriding GFAddOn::get_entry_meta().

This will allow the entries to be sorted on the entry list by the Site ID and filtered on the results page.

Step 6: Add-On Initialisation

The Add-On Framework contains a few methods we can use to execute code in the appropriate places during the loading of the page:

  • pre_init()
    - Override this function to perform any tasks that need to be done before the WordPress action “init” fires.
  • init()
    - Override this function to perform tasks during WordPress initialisation. e.g. adding hooks.
  • init_admin()
    - Override this function to perform tasks only in the admin area
  • init_frontend()
    Override this function to perform tasks only in the front-end
  • - init_ajax()
    Override this function to perform tasks only while processing ajax requests

For this add-on we’ll be using init_frontend() to hook into the gform_after_submission action.

Notice that, as the framework method is being overridden the parent method needs to be called to make sure the rest of the framework continues to load as expected.

Step 7: Web API – Storing the entries on the remote site

Every Gravity Forms installation comes with a Web API. It’s disabled by default so you’ll need to make sure you enable it on the settings page of the central server.

Rather than constructing all the URLs for the requests and handling the authentication signatures we can make life easier by using the Gravity Forms Web API Wrapper. Download it from from the GitHub repository
and add it to a folder called “includes” inside the plugin folder. The Web API Wrapper will handle the construction of the request and the authentication so we don’t have to.

The methods we’ll be needing for this project are create_form() and create_entry() but there are many more documented in the wrapper. For a more complete example of using the Web API wrapper check out the Web API Client.

We’ll be doing all the work for our add-on inside our after_submission() method:
A. Check the form settings to make sure this form is configured for remote aggregation
B. If the Form ID is empty in the settings then create the Form on the remote site. The remote Form ID is then saved in the settings.
C. Create the entry on the remote site making sure to identify the current site in the Entry Object

As a side note, a smarter approach would be to spin steps B and C off into a wp_cron task so that slow responses and timeouts can be handled gracefully without making the user wait, but of course that’s slightly out of scope for this introduction.

Step 8: API Functions – Deleting the local entries

There’s one final piece left to implement. That’s to delete the local Entry if permitted by the form settings.

The GFAPI class is used to interact with the local Gravity Forms installation and supports CRUD operations on both Forms and Entries.

In this case we’ll only be needing the delete_entry() function.

Complete Code Listing

The complete add-on is available for forking in the Github repository for Gravity Forms Aggregator.

View the complete listing: aggregator.php

Download the complete zip file of the add-on: gravityformsaggregator_0.1

Next Steps

Although this add-on is very simple, it’s not intended to be used in a production environment. It’s intended to be used primarily as a learning tool. I’m not intending to support this add-on or develop it further so if you do decide to use it in a production environment, please ensure that you do sufficient testing and that the security issues surrounding the API private key are taken into consideration.

  • Form synchronisation: how will you handle changes to the form? If a field is added how will you propagate this change across all the sites?
  • Security: at minimum use SSL in the WordPress admin

Conclusion

The Gravity Forms developer platform, consisting of the Add-On Framework, Actions and Filters, Web API and API functions stands on top of the giant’s shoulders that is WordPress and together they provide a highly extensible platform for the rapid development of form-based applications. The example project is simple one but it touches on each of the tools and demonstrates some best practices for working with Gravity Forms showing how the platform could be leveraged in the development of more complex applications.

I’ll be very happy to answer any questions you have about this tutorial in the comments. Please direct all specific questions about your project to the Gravity Forms technical support team.

 

********

Legal bits:

  • The views expressed here are my own and do not necessarily reflect those of Rocketgenius.
  • Gravity Forms is a trademark of Rocketgenius
  • WordPress is a trademark of The WordPress Foundation

 

 

WordPress has dominated content management – what next?

WordPress is rapidly emerging as a de facto standard in Web content management. So what can we expect down the road, and what will it mean for the idustry?

Take a look at this snapshot comparing search volume trends for WordPress to its longstanding competitors Joomla and Drupal.

WordPress vs Joomla vs Drupal

WordPress vs Joomla vs Drupal

It’s difficult to generalise from a single chart but when you combine it with the data below from builtwith.com you get a pretty good insight into what’s going on in the content management space today.

Of the top 10,000 websites that use a content management system (CMS), over half are using using WordPress.

WordPress installations

WordPress installations: top 10k sites. Source: builtwith.com

This dominance increases to 63% for the top 1 million sites.

 

WordPress installations: top 1 million sites

WordPress installations: top 1 million sites. Source: builtwith.com

 

Regardless of how much room you leave for interpretation it’s clear that WordPress is crushing its competitors at an alarming rate – at least in terms of market share – and it’s not showing signs of slowing down any time soon.

So what happened? How did Automattic, the creators of WordPress, manage to achieve so much success in such a relatively short period of time?  Can the growth be maintained? And what does all this mean for online tech decision makers?

WordPress (r)evolution

First, although WordPress started as an open source blogging platform back in 2003, any discussion of whether it’s evolved into a real CMS petered out probably around this time last year. In fact, even this time last year, only 8% of WordPress installations were just blogs.

Users seem to love it because they find it easy to update content, add functionality and tweak the design. Small companies have jumped at it because the associated costs of building and maintaining an entire site, or portfolio of sites, can scale dynamically with the business.

Even larger companies, perhaps at the insistence of their users, have started to accept its role in enterprise content management. Or perhaps it’s because it costs a fraction of their proprietary or inflexible ‘enterprise’ CMS. Whatever the reason, Automattic’s official enterprise offering  is certainly helping to smooth the way.

By making it a relatively trivial task to add custom post types and custom taxonomies, the platform has capitalised on its early success and opened itself up to manage any kind of content, not just pages and blog posts.

For instance, WordPress can be used as a perfectly capable e-commerce platform and there’s no shortage of plugin and theme vendors to help extend the functionality in that direction.

WordPress currently powers 16.7% of all sites on the Web (source: w3techs.com). That’s an impressive figure, but there there are still 69% of all sites on the Web that are not using any type of CMS at all (source: w3techs.com). So there’s plenty of room for growth without having to compete for market share.

The introduction of native mobile apps for iOS, Android, BlackBerry and Windows Phone is going to play a big part in that sustained growth.

The WordPress ecosystem

Another reason for this popularity is the hugely successful WordPress ecosystem/economy. Matt Mullenweg & co. have spawned an entire global industry of WordPress-specific services including web design, development, writing services, marketing, hosting services and training.

One of the key factors driving this success is perhaps Mullenweg’s controversial, but rather wise insistence that themes and plugins must adhere to the WordPress open source GPL – there are no proprietary WordPress themes or plugins, legally they all fall under the WordPress GPL.

That doesn’t mean that you can’t make money and nor does it mean that you’re legally obliged to share everything you create. An inhouse development team may decide that they’ll retain their competitive advantage by choosing not to share their code. Whereas vendors of the most successful commercial plugins like Gravity Forms make their money from the associated services like support and auto-updates.

This hardline stance on licensing can be difficult to understand at first but it does seem to have worked – especially for customers. It’s very easy to find the right skilled workers to customise the design or extend the functionality of a WordPress site. Right now WordPress skills are significantly cheaper than Drupal skills.

Salaries. WordPress skills vs Drupal vs Joomla

Salaries of WordPress skills vs Drupal vs Joomla. Source:indeed.com

This doesn’t mean that Joomla or Drupal sites are suddenly about to become obsolete – but it does mean that it’s going to become increasingly difficult to find and retain skilled designers and developers over the long term to maintain those sites – at least while WordPress continues to drain talent.

What’s down the road?

At the current ferocious pace of evolution, we’ll soon see WordPress transform even further from its original blogging platform concept towards something resembling a de facto standard application framework, or app-engine, for all kinds of small to medium-sized projects.

By using WordPress as a framework developers already get a lot of things “for free” (e.g. user account management, content management, caching, template engine, extensibility framework, built-in SEO, automatic updates, etc) – perhaps too many things. In fact, for some smaller projects, it may already be perfectly suitable but the lack certain features like a scalable design pattern (e.g. native MVC) may rule it out in favour of a “realframework for some larger projects.

As the WordPress core continues to be refined, however, I’m sure we’ll see a lot more WordPress-based applications popping up at department level and perhaps we’ll even see niche-specific solutions disrupting established markets.

When the workflow features and user rights handling improve we’ll see a surge in enterprise adoption and this in turn will spark growth in demand for more robust third party API integration with legacy systems. We may even see multi-site WordPress encroaching on Sharepoint territory for team collaboration scenarios. Certainly some small businesses are already deploying WordPress as their primary intranet/intra-company platform and this trend looks set to continue.

All of this is great news for users of course. Elements of projects that used to be coded by hand just a few years ago can now be configured in a few minutes using the WordPress admin dashboard. So we’re set to see the inevitable power-shift edge further away from developers and towards business and project owners. And that can only be a Good Thing, right?

Capturing the Scope of the Project

Requirements are the lifeblood of any project. Communication with team members and the customer is key, and must be well thought out, well planned out, and – especially for larger projects – well documented. But good, detailed, and complete requirements are just as important – if not more so – because the amount of re-work that goes into the project later trying to fix work that was performed against poorly documented requirements will kill most projects in terms of budget, timeline or customer satisfaction (and sometimes all three at once).

There is no question that a key task for the project manager is to ensure that requirements are accurately captured for the project. In an ideal world the project client would come to into the engagement with perfect requirements but more often than not requirements are either incomplete or possibly even focused on a symptom of the issue rather than the big picture. That’s where the project manager needs to be ready – along with the  team – to ask the tough questions and spend some extended time extracting the detailed scope of the project and documenting the requirements so the solution can be developed against what the customer’s end users really want and need.

Identify the key success factors

Project objectives and deliverables are sometimes referred to as critical success factors. Critical success factors are those elements that must be completed in order for the project to be considered complete by the customer or even the PM’s executive management.  If your solution doesn’t cover these factors, then the project will never be considered a success. Not all deliverables are necessarily critical success factors, but many of them will fall into this category and should be documented as such.

Include stakeholders, SMEs and end users

Part of the process of collating requirements is going to involve digging a little deeper and reaching out well beyond just the project sponsor and immediate team. If the project manager and team are going to ensure that they successfully document requirements and deliver a workable end solution, then it is imperative that all project stakeholders, customer subject matter experts (SMEs) and end users be involved in the process of gathering, documenting, and finalizing requirements. If the data or processes are critical to the business it may also be necessary to enlist the help of a business process analyst with relevant experience to aid the process especially if you feel that a lack of experience might lead to a disconnect or communication breakdown between the different teams.  The more work that is done upfront in guaranteeing proper requirements have been captured, the less chance that expense rework will need to be performed later in the engagement. Change orders can often cover the cost of necessary rework, but change orders make customers less than excited about what you’re doing for them, so keeping extra customer costs to a minimum is always best. And of course, once the requirements have been captured in detail, be sure to have the project customer official signoff and approve of those requirements. Trust me, any questions that arise regarding project scope and requirements will be easier to handle if both sides have an agreed upon baseline to work from.

Things to remember

The bottom line is we need to work hard at the start of the project to ensure that what is being captured is as thorough as possible. And the key things to keep in mind are these:

  • Don’t take the customer’s original requirements at face value… be ready to dig deeper
  • Don’t be afraid to ask the tough questions
  • Involve SMEs, other stakeholders and customer end users and try to involve business process analysts if you need to
  • Document captured requirements well, get signoff and form a project scope baseline

And remember, that last one is imperative. Once you have the consensus that the scope has been captured, get it in writing and get it signed off. If you find out later that requirements were incomplete or have changed – going back to that sign-off will make the implementation of change orders much easier for everyone involved so that you can get back to the real work of implementing the right solution for your project client.

Are PM Best Practices Any Different for Web Development Projects?

Web projects can be their own animals sometimes.  Their own process.  Customers tends to come at them differently, the urgency can be different – sometimes much greater with a shorter timeframe expectation than a typical enterprise application development or implementation project.  The projects can range from simple corporate websites to mission-critical intranet applications or, in the case of an Internet startup, the project can be the product itself. And, of course, there are always the me-too requests – “I want it to look like ‘x’ site or be the next big ‘y’ site.”.

So I’m often asked… do we do anything different – from a project management standpoint – for Web development projects over, say, an enterprise CRM implementation?  Do we plan differently, do we manage the project a different way, do we engage the customer differently?  The answers should be “no,” “no,” and “no.”

First let’s review what best practices for project management really are.  There can be many different interpretations and versions of what best practices are – it can often mean something different to each organization, to each PMO director, to each Web developer, to each customer.  But there are some core practices or thought processes… or perhaps actions… that are critical for successful project management.  And yes, these are relevant to Web development projects as well – the amount of effort we spend on each of these and the detail that goes in will often depend more on the budget and the customer than the type of industry or type of development that is being performed.  I’m sure there can be hundreds of items on this list, but these are my basic six…

Start with a formal kick-off

This can be a 15 minute meeting or a two-day event.  I’ve done both.  But formally choose a kickoff point and use that event to review the statement of work with the project client, set expectations, confirm milestones, and set the tone for how the engagement will be run and managed.

Conduct regular status checks

No matter how crazy the project is during any given week or how slow it is moving at the moment, make time to have regularly scheduled status checks with the stakeholders – at least weekly – and keep the documentation up to date.  During a crunch time that may need to be daily.  If you start to skip it, then skipping it can become habitual and eventually you’ll run into some satisfaction or frustration issues with your project client.

Manage the project with a project schedule

Even for small projects, put together a schedule and use it to drive the weekly status calls with the customer.  Keep it up to date and review accomplishments, the current status of live tasks, upcoming tasks and who’s assigned to what and use it to manage risks. The schedule can be a traditional waterfall approach using MS Project or a more Agile, fluid approach using user stories and a planning tool like Pivotal Tracker … or a mix of both.

Monitor the budget closely

A 10% budget overrun is easier to correct than a 50% overrun.  That’s common sense, of course, but if you’re on top of the project budget every week and revising the forecast then you’ll likely never hit that 50%…you’ll take corrective action at the 10% mark.

Pay attention to testing

User acceptance testing (UAT) is necessary and it should involve the customer as far as possible in order to avoid any bias testing on your part.  But customers are often ill prepared for UAT – be ready to ‘train’ them on how to test the product… facilitate wherever possible.

Provide post deployment support

Finally, make sure you provide some post deployment support.  Don’t just deploy and move on.  You never know when they’re going to come back for more work or to whom they might be referring you.  This point of the project is where you can sometimes win back a customer who was previously frustrated during earlier parts of the engagement.

 

—-

Microsoft’s Y2K-Style Azure Outage

Office365” states it very clearly – it would appear that the Microsoft SLA doesn’t take into account leap years, as we discovered last Wednesday. Customers lost access to Azure at 1:45 a.m GMT, February 28 due to an outage that lasted for the following 36 hours, apparently caused by a bug that has been traced back to “cert issue” in a Microsoft datacenter in Dublin. The details themselves are rather notable from a historical point of view:

“While final root cause analysis is in progress, this issue appears to be due to a time calculation that was incorrect for the leap year,” Bill Laing, a Microsoft exec, wrote on the Azure blog. “Once we discovered the issue we immediately took steps to protect customer services that were already up and running, and began creating a fix for the issue.”

The issue was eventually resolved, and it is far from being the first one to bring a major PaaS service to a complete halt. Competitor AWS also had its fair share of unscheduled shutdowns throughout the past few years; the most recent of which was in late April last year. (It’s interesting that this particular incident didn’t technically infringe Amazon’s 99.95% uptime SLA, because – as this ZDNet piece pointed out at the time – while EC2 was covered by the agreement,  the two other services that were the very cause of the downtime were not.)

Generally speaking, cloud platforms such as Azure can guarantee considerably higher uptime than traditional on-premise infrastructure, not to mention the much better performance and utilization rate. This is not surprising considering Microsoft is probably using better components on both ends of the stack, but it’s this level of service – and the demand it rightfully earns – that leads to all the problems in the first place.

The aftermath

It’s all about the ‘public’ in public cloud. As one of the most widely-used PaaS offerings out there, Azure is being leveraged by thousands of organizations and independent developers worldwide – all of whom have temporarily lost access to their data and apps during the blackout. One good example is CloudStore, a UK-based cloud service storefront that recently exited stealth and received a nice bit of coverage from The Guardian  following the outage. The bad PR for Azure however resonated across more than just one publication.

Cloud adoption is increasing in the enterprise space, a trend bolstered by the whole list of supporting predictions, forecasts, infographics and analyst quotes that make their entry into the blogosphere on a daily basis. And by default, this movement leads to increased dependency within these consolidated environments, which undoubtedly couple many advantages with the shortcomings to match.

The gap between traditional data center operators and tomorrow is steadily narrowing as the market shifts, but the bridge is still and will most likely always remain a work-in-progress.