WordPress beyond an App Engine

WordPress is evolving but into what?
And how will this affect developers?

 
This afternoon at WordCamp Europe 2014, Matt Mullenweg again highlighted the progression of WordPress from a blogging platform, through CMS, to an App Engine and in the future he said, who knows what it might become. This my thought-experiment attempt at answering Matt’s rhetorical question.

WordPress has constantly lowered barriers. First, as a blogging platform, it made web publishing easy for absolutely anyone. Then, as a CMS it put the look and feel of whole websites in the hands of the people with the vision and ideas. Now as an App Engine or framework it’s providing the development platform for dedicated vertical applications for example, for the real estate industry.

Following the pattern, very soon WordPress users are going see that they can build and configure any kind of application they like – any application at all. Sites will become an increasingly sophisticated, extensible and integral part of their business and the same time just as easily customisable as the look and feel.

The platform might therefore be thought of not just as a Content Management System, and not just as an App Engine; but perhaps as more of an ‘App Management System’.

Plugins like WooCommerce and Gravity Forms of course already do this to some extent but I think this is a trend we’ll see increasing rapidly as a new generation of app users flock to WordPress demanding more from their sites.

What does this mean for us developers? Just another wave of reinvention.

Back in 1996 I would build static web pages for my clients. It soon became clear that what people needed was a CMS so I adapted my skills to building CMSs. That continued for a few years until it was clear that a winner was emerging and that I would have to throw my lovingly crafted CMSs away, adapt again and start using WordPress to build websites. I was still developing, still building sites but by adapting I was able to deliver more value to the customer.

Now, as developers, perhaps it’s time for us to adapt again and prepare for the next shift in demand as our customers stop seeing their sites as a websites and start seeing them more as apps.

Gravity Forms API Tutorial: Approval Workflow

Entry Approved

Entry Approved

Note: this is the second in a series of tutorials helping developers to extend Gravity Forms.

In the first tutorial, I gave an introduction to the Gravity Forms developer platform and demonstrated how each of the tools could be used to build a simple add-on. In this second tutorial, I’m going to be delving a little deeper by using the Gravity Forms Feed Add-On Framework to demonstrate how Gravity Forms and WordPress can be extended further to build a fairly sophisticated workflow application.

There’s no shortage of use cases for a form-based approval workflow. Let’s take a look at a few to get some context for our solution:

A manager in the Human Resources department wants to create a collection forms including vacation requests for employees to complete company-wide. These forms must be approved or rejected by the employee’s department director. Pending approvals must be displayed in a personalised list for each Director. The data from approved forms will be sent to a Google Spreadsheet.

The CFO has asked you to implement a system to handle the approval of all the incoming invoices arriving each day. The receptionist is currently making a note of each bill and then sends them over to the appropriate department head for approval. Invoices over $9,999 must also have the approval of the Finance Director before the data is sent to OpenERP.

A new Mum has set up a membership site documenting the first few years of her new-born for her family and friends by following a great tutorial explaining how to set up WordPress as a membership site. She wants users to activate their own accounts but she wants to approve the WordPress account requests before they are created and before the activation emails are sent to the users. Both Mum and Dad must approve the new accounts.

Requirements

  • Flexible configuration by non-technical users; no hard-coded workflows.
  • Each Form will have different rules for approval and different users as approvers.
  • The rules for approval will depend on conditional logic for field values (e.g. invoice amount, approval status).
  • Notifications must be sent in response to approval and rejection and must be flexible enough to send multiple notifications each with a different conditional logic.
  • Notifications to approvers must contain a deep link to the form with immediate access to the approve and reject buttons.
  • When approval is required for a form, delay actions performed by the User Registration Add-On and the Zapier Add-On until the form has been approved by all approvers.
  • Pending approvals for each approver must appear in a personalised list on the WordPress Dashboard.
  • Approved or rejected forms cannot be edited.
  • Approvers can’t change their approval status once committed.

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

  1. Create an Add-On that uses the Feed Add-On Framework. One feed will be created for each approver and will support conditional logic.
  2. Add custom Entry Meta fields to store the approval status for each approver.
  3. Add a Feed Settings tab to the Form Settings UI that will list approvers and allow admins to add new approvers to a form.
  4. Add a box on the Entry detail page to show the current approval status and approval buttons to approvers.
  5. Add a WordPress Dashboard widget and display a list of pending approvals for the currently logged in user.
  6. Integrate with the User Registration Add-On and the Zapier Add-On so that form approval triggers WordPress user account creation and the sending of data to third party services e.g. Google Sheets, Freshbooks, OpenERP…
  7. Add a notification event ‘form is approved or rejected’ to the Notifications UI.

Step 1: Extending the Feed Add-On Framework

A feed is a user-defined action that gets processed conditionally after a form has been submitted. Feeds are used in a number of Gravity Forms Add-Ons including the Paypal Add-Ons, Coupons Add-On, User Registration Add-On, MailChimp Add-On, Zapier Add-On and the AWeber Add-On to allow multiple actions to be triggered after a form has been submitted. In this case, we’re going to use feeds to assign approvers to each form. Feeds support conditional logic so approvers can be assigned to entries based on the value of a field. For example, in the case of incoming invoices our admins can configure an approval feed for the Finance Director when the invoice amount exceeds $9,999.

Step 2: Entry Meta

Entry Meta fields are like form fields except they don’t appear either on the front-end form or the entry editor and they can only be updated via code. This makes them ideal for storing meta data such as approval status. Users will be able to filter the entries by approver and by approval status on the entry list and we’ll be able to use the Gravity Forms API to display the personalised list of pending approvals on the WordPress Dashboard.

To configure the Entry Meta fields we just override GFAddOn::get_entry_meta() and return the configuration for the approval status of each approver and the overall approval status.

Notice that we register a callback for the overall approval status update event, but not for the individual approval status for each approver. This is because we don’t need to set the entry meta for the approvers when the entry is updated – we only need to set the overall approval status. We’ll assign the approvers conditionally using the the GFFeedAddOn::process_feed() in the next step.

Step 3: Feed Settings

GFFeedAddOn extends the Add-On Framework so we get everything that comes with GFAddOn except in place of the Form Settings UI we get the Feeds UI.

The Feed Settings UI is going to provide a way for admins to assign approvers conditionally to forms. So instead of overriding GFAddOn::form_settings_fields() as we did in the previous tutorial we’ll need to override GFFeedAddOn::feed_settings_fields() and return the array with the configuration of the fields.

We’ll need to override GFFeedAddOn::feed_list_columns() so our fields are added as columns to the feed list page, and GFFeedAddOn::process_feed() to handle the form submission event. The processing of the feed, in our case, just means assigning the approver to the entry. We don’t need to hardcode any conditional logic because this method will only run if the conditions are met – the logic is handled behind the scenes by the framework.

See the Settings API for further details on how to create settings pages.

This will produce a list of feeds and an edit page that looks like this:

Approval Feed Marketing Director

Approval Feed Marketing Director

 

Step 4: WordPress Dashboard Widget

The personalised inbox of pending approvals will be displayed using the WordPress Dashboard API.

Dashboard Inbox

Dashboard Inbox

For this we’ll need GFAPI::get_entries() to search the entries with a couple of search criteria to ensure we only get the entries pending approval for the current user.

Notice the three different links:

  • All entries pending the approval of the current user
  • All entries submitted by the requester
  • Direct link to the entry

Step 5: Add a custom event to the Notifications UI

Notifications in Gravity Forms are user-defined emails that can be triggered conditionally, routed to different email addresses and contain field values. By default, notifications are processed on form submission.

The Notifications UI page contains a filter called gform_notification_events which allows us to add custom events. This provides us with a way to separate notifications sent on form submission from the notifications we’ll need to send when a form is approved or rejected. So for example, in the case of the incoming invoices, we don’t want to notify the Finance Director until the invoice has been approved by the department Director. We’ll still need to write the code to handle the event and send the notifications at the appropriate time but this is a handy way to reuse some existing admin functionality in Gravity Forms.

Custom Notification Event

Custom Notification Event

Step 6:  Integration with the User Registration and Zapier Add-Ons

The Zapier Add-On providers users with point-and-click integration of Gravity Forms with literally hundreds of different Web Services, for example Freshbooks, QuickBooks, Trello and Salesforce. In our use cases, we can use the Zapier Add-On to send form data to Google Sheets and OpenERP.

The User Registration Add-On handles the creation and updating of WordPress user accounts. It’s very flexible and allows conditional registration and will map form field to user profile fields and custom fields.

For our solution, we’ll need to make sure that the Zapier and User Registration Add-Ons don’t trigger their actions immediately on form submission so our Approvals Add-on can trigger them once the entry has been approved. The User Registration Add-On has the  gform_disable_registration filter we can use but Zapier currently doesn’t have an equivalent hook so we’ll need to get a little creative and make sure its registered action hook is removed before it can be triggered.

Step 7: Entry Detail Approvals Meta Box

Finally, this is the code that brings everything together. It’s the UI that approvers use to approve or reject entries. It also contains the code that triggers the notifications registered with our custom notification event, user account creation, and sending data to Zapier.

Entry Approval Pending

Entry Pending Approval

Entry Approved

Entry Approved

 

Complete Code Listing

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

View the complete listing: approvals.php

Download the complete zip file of the add-on: gravityformsapprovals.zip

Configuration

Now we’ve got Gravity Forms to support approvals we need to set up the forms and configure the business logic for each workflow. If you’re already familiar with Gravity Forms then this section is perhaps unnecessary but I’ve included it here for for completeness and for readers who are not so familiar.

Vacation Request

In the use cases described above, the HR dept needs only one approval feed per form and per department. The example vacation request form contains the following fields. Some of these fields can be set automatically by specifying the appropriate merge tags in the default value settings.

Vacation Request Form

Vacation Request Form

So for each form we need to add one approver per department. Each approval feed will look something like this.

Approval Feed Marketing Director

Approval Feed Marketing Director

Notifications are configured separately on the Notifications tab. In this case we’d need one notification for the approvers – something like this:

Notification Vacation Request

Notification: Conditional Routing

Incoming invoices

In the case of the incoming invoices form, we’ll need a form that looks something like this:

Incoming Invoices form

Incoming Invoices Form

The approval feed for each department might like this:

Approval Feed - Incoming Invoices

Approval Feed – Incoming Invoices

We also need an additional feed for the Finance Director in the case of high value invoices.

Approval Feed Finance Director

Approval Feed – Finance Director

We’ll need to configure a notification with conditional routing like the vacation request form and an additional notification for the Finance Director for forms that need her approval. Notice the conditional logic ensuring that the form has not previously been rejected by a colleague.

Notification - FInance Director

Notification – FInance Director

Next Steps

Although this add-on is very simple, it’s not intended to be used in a production environment and it hasn’t been tested in a multi-site installation. It’s intended to be used primarily as a learning tool. If you do decide to use it in a production environment, please ensure that you do sufficient testing and that security issues are taken into consideration. At minimum use SSL in the WordPress admin.

There are many ways this idea could be developed further or adapted to fit different scenarios. Here are some ideas for next steps:

  • Integrate the forms with internal systems
  • LDAP integration
  • Create the default notifications automatically when each feed is saved
  • Install the Members plugin or similar and configure appropriate permissions
  • Add entry meta for approval comments, timestamp and previous status
  • Add support for approval steps
  • Add a visual workflow designer
  • A desktop widget displaying pending approvals

If you decide to implement any of these, please do let me know.

Conclusion

With relatively little code (under 100 logical SLOC) it’s possible to turn Gravity Forms + WordPress into a sophisticated custom workflow application. Granted there are excellent dedicated solutions on the market with advanced features and visual workflow designers, so this approach is not going to be the most suitable for every situation, but if you’re aware of the possibilities it’ll help you make the right choice. Were you aware you could do this with Gravity Forms? I’m sure there are many additional use cases and adaptations for this application. If you come up with any, please let me know either in in a private message or in the comments below.

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

 

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.