Shepherd Interactive

Several months ago Shepherd Interactive had a website implementation project where we had to support dynamic features on a medium sized site whose content management system did not support (with the purchased options) any dynamic features, it publishes static files only.  It was a fun and rewarding challenge.

Here’s the short list of required dynamic features:

• User accounts (with an open registration process)
• Blog (we chose WordPress), with commenting only available to people with user accounts
• Ability for users to assemble a “briefcase” of documents and resources for downloading as a zip. Any page on the site (including a blog post) may be a resource which can be added to the briefcase, any page may link to other resources which can be added to the briefcase (eg: whitepapers, customer videos, documentation)
• On the fly conversion from HTML to PDF for dynamic content downloads
• “Premium” downloads limited to visitors with user accounts
• Notifications to the client’s CRM/SFA tool as to who has downloaded what premium content
• Ability for users to send their briefcase to another person so they could quickly download the prepared content

General Principals

While the CMS had no dynamic features it could publish files with arbitrary content, and in our case we had the CMS publish what were fundamentally HTML files with a little slug of PHP at the top of every file to include the code tree:

<?php
include($_SERVER["DOCUMENT_ROOT"] . "/includes/stdInclude.php");
?>

Once a page had the site’s runtime instantiated it allowed us to add more PHP to the basic templates to do things like display the user’s name if logged in, indicate their briefcase status, indicate the premium or non-premium status of various downloadable and viewable resources, creating a fully dynamic page with a static file publishing CMS.

To maintain maximum flexibility of the back-end services (user management, blog, single sign on) a pre-feature-hook and post-feature-hook paradigm was chosen, something like the following:

<?php
class fubar
{
  private $errors = array();

  function foo($bar)
  {
    if (!($baz = $this->_preFoo($bar)))
    {
      return $baz;
    }

    // do foo
    // set errors on foo task here before returning
    return $this->_postFoo($bar);
  }

  function _preFoo($bar)
  {
    // do something before executing foo
    // set errors here (if any) before returning
  }

  function _postFoo($bar)
  {
    // do something after executing foo
    // set errors here (if any) before returning
  }

  function getErrors()
  {
    return $this->errors;
  }
}
?>

Being able to tie into any method pre- or post- action turned out to be invaluable to support features of the site which changed or were added at the last minute.

To accommodate arbitrary forms on any page that are created within the CMS we intercept all form POSTs on the server, sniff the payload and the referer to figure out from where the post comes from, what should happen, and where it should go.

Finally, where possible we chose external applications to provide functionality such as zipping up a briefase and conversion of HTML pages into PDFs for download, these features made available as PHP modules are not as widely deployed as the external tools are.  Using the external tools proved to be more portable and reliable across the development, staging, and production environments.

User Accounts, Blog Integration

The first task was to allow users to create their own accounts, have them log in, change their passwords, logout, and have the site determine whether a user was logged in or not – normal user-type things – and all of this had to tie into the WordPress blog infrastructure at the same time so once a user was logged into the site they’d also be logged into WordPress to enable commenting.

Why not just use WordPress to manage all of that?  We felt that the other site requirements related to the briefcase made that option unfeasable and it allowed the client to move to the CMS vendors blog module at a later date if they wished without having to re-do the whole resource download/briefcase infrastructure.

The user module was created with pre- and post- hook on every feature, into these pre- and post- hooks we tied in our single-sign-on features.  By leveraging WordPress’ relatively rich API we were able to link our user system into the WordPress system seamlessly, any user account interaction semantics (login, logout, add user, update information, etc.) are fully integrated with WordPress.  And since the single sign-on module uses the published WordPress API the module will (theoretically) survive WordPress upgrades.  To ensure the constancy of the user interaction all user login/logout/account edits were directed to the main site’s version of those pages with some simple editing of the theme files.

Briefcase

Once a user has created an account and logged in the “briefcase” feature is available to them – in this case a briefcase is somewhat like a shopping cart except you fill it with documents and resources (case studies, white papers, customer testimonial videos, blog posts, webcasts, flash demos, brochures, etc) for sharing with others or to download bundled in a zip.

Because downloading an HTML document isn’t very useful to the average user we used the Prince XML tool to take the HTML documents and the print stylesheet we had already developed and turn them into a PDF which will print well but also maintains any hyperlinks contained in the page for people that read it on screen.

Conclusion

Adding dynamic features to a site published by a static publishing platform is quite possible and proved to be rewarding task when certain programming techniques were followed.

Tags: PHP, WordPress