UPDATE: Okay, so perhaps using WordPress as a software delivery platform IS in fact something I’ve done before! A root through some old posts has reminded me I powered the ePetitions system at the City of Lincoln Council with WordPress back in 2011. So… there’s that! I guess… Still, the ePortfolios is a lot more complex and better done. Sniff.

So here’s a thing that I don’t think I’ve talked about before. Strap in – this is a long one…

Way back when I was self employed I took on a contract with the University of Lincoln School of Social Science to work on an ePortfolio system for them. The loose brief was that all placement portfolios for their students were handled using printed pro-forma’s and ring binders. This method was becoming combersome, hard for the students to carry around with them in the digital age and hard to get marked on time, as the document had to physically be handed to markers. A digital system would be the best solution, existing nebulously on a server somewhere and being accessible on any device the student needed it on; laptops, PC’s, mobile phones, tablets.

One of the first hurdles to overcome was, as always, understanding how the existing solution would scale to digital. The tl;dr answer is – it wouldn’t! The methods in place and the proformas that needed completing were overly convoluted through the requirements of a physical document that needed to be passed to multiple people. So, the first step was to prototype a new system. This was a surprisingly lengthy process but it gave me time to consider how I was going to deploy this system. I decided it was time to try out a theory I’d been carrying for a number of months – using WordPress as a software delivery platform.

It was something I’d not tried before – not using WordPress strictly as a blogging tool, but as a system that would deliver a service to a number of users, that they could interact with in a different way but still use the core functionality of WordPress to our advantage. The basic concept was this:

  • A WordPress multisite install would be set up
  • Users would be registered to the network using an LDAP plugin to link them to their university accounts, BUT we could also register external users with local usernames and passwords – this would be essential for the portfolios.
  • Access to the system would be locked down to only registered users.
  • Using the multisite system, each student would get their own “portfolio”
  • Each portfolio would provide a number of pages containing pre-formed text areas that could be completed by the student, saved to the portfolio and ultimately signed off by tutors and supervisors.
  • At the end of the placement, the student would “hand in” their portfolio for marking and ultimately revisit the system to retrieve their marks.

I decided to build up most of the functionality using pre-existing plugins to save time and built up a suite of tools for installing, the core ones being:

  • Blog copier – the basic portfolio was set up as a template and blog copier was used to duplicate that template for each student, saving admin time.
  • Blogs directory – for admin use only to provide a searchable list of all the portfolios
  • More privacy options – to help lock the system down
  • Types – this allowed us to define custom fields for pages to actviate certain functionality for the signing off of forms
  • User access manager – to allow specific user types to have certain levels of access
  • User role manager – to define custom user types
  • WPMU LDAP authentication – to handle the LDAP login

All of the above let us set up a system to handle the creation and distribution of the portfolios, using a custom theme to control finer aspects and define bespoke functionality such as a sign off system which was defined through custom fields on pages. Certain user types are then able to digitally sign those pages. This in turn generates a grid of which pages require signing and which pages are signed. When the grid is complete, the student can hand in their work.

The one core function we could not replicate was the forms themselves. The basic idea was to present a HTML form on the actual page which would allow logged in users with access the ability to edit content on the page without having to go into the back end of the system. This would mean that specific questions could be posed and areas could be provided for free text entry.

As there was nothing to allow us to do this, I wrote a custom plugin which uses a series of shortcodes to allow sys-admins to build up forms for completion, decide what user types need to complete those fields and, ultimately, tie this into the sign off system to ensure that signed off pages cannot be further edited. I’m planning on releasing a general use version of this plugin so I’ll go into it in more detail in a future post.

Once the system was set up and tested, we rolled it out for one group of students in summer of 2014. This lighter touch approach which still used paper forms as a back up allowed us to guague user feedback, add quality of life updates and fix bugs that we’d not noticed during testing. Overall, the system was a success and was subsequently rolled out to all courses that required it. It’s still being used and tweaked to this day.

My main takeaway from this project is that yes, WordPress is totally a viable solution for delivering software that isn’t necessarily a website. Following the ePortfolio project I’ve used it multiple times to prototype different systems, most prominently a data warehouse concept that allowed multiple data sources to be combined and reported on using common keys. This is a concept I’m particularly keen to keep investigating going forwards.

Ultimately, WordPress provides all the tools to make it a viable software delivery platform. Custom plugins can be written using standard PHP, the MySQL API allows for custom database calls to be made and there is a whole suite of plugins for managing users and display that will allow developers to focus on the core functionality of the software.