WordPress in the Enterprise

We ran a panel discussion on WordPress in the Enterprise at the start of WordCamp UK. Thanks to Kimb Jones, John Read, Dave Coveney and Martin Beeby for their great contributions to the discussion.

The slides from this session are on slideshare:

The discussion covered three themes:

  1. How do people use WordPress within organisations?
  2. What are the challenges of deploying WordPress within an organisation?
  3. How can WordPress evolve to be more effective for internal use?

This is a short summary of the discussion at the session (as far as I remember it) and further discussions throughout the weekend. Do feel free to add your own notes in the comments.

How is WordPress used within organisations?
We reviewed a number of cases where WordPress has been used within organisations. For example I have some experience of using WordPress within a large organisation, particularly to try to foster internal discussion around technology issues. WordPress is a great choice to manage this as it has inbuilt commenting, ready-made themes and is relatively easy to set up and manage.

We also discussed the WordPress-SharePoint interface, and how organisations need to work out how they can use both applications in a complementary way.

What are the challenges of deploying WordPress within an organisation?
The choice of architecture is key. Externally hosted WordPress sites generally run on a full LAMP stack (Linux, Apache, PHP, MySQL), but introducing this within a Microsoft-based organisation means that the IT operations staff may not have the skills, experience or confidence to support (“What if it falls over at 3am on a Sunday?”). One possible solution we discussed (and was elaborated on in a later session by Andy Robb) was how WordPress could be run on a Windows environment. There are a number of options for this, including the use of the XAMPP distribution (good for development servers) or the Microsoft Web Platform Installer.

Another crucial challenge is user authentication. The common model used by Active Directory plugins is to generate a new WordPress user for each person logging into the WordPress site. This may give rise to maintenance issues when users change role or leave the organisation and their records (including created content) is not cleaned up. There are various theoretical solutions for this, but not many concrete plugins. We therefore wrote a small plugin to identify users from their Apache REMOTE_USER property (linking Apache to our Active Directory domain and groups through directives in the httpd.conf) and this enabled us to recognise people from their Windows logon. This is an area for further work.

Multi-site or single instances. The consensus was that a multi-site instance would be useful for a family of similar sites, although single instances can provide an opportunity to provide a different experience from this standard.

Some plugins are hard-wired to operate within an Apache server environment. We need to build a community of trusted and tested plugins that solve enterprise problems.

Although WordPress 3.2 stopped support for IE6, it is still used by a large number of public sector organisations in the UK (according to The National Archives, 54% of government users in the UK compared with 1% of the general public).  .

Environments. In order to maintain a well-controlled and stable live service, enterprises use separate Development, Test and Live environments, and this is good practice for any WordPress installation. However, as content and configuration are not physically separated within the database, this adds some additional work. A plugin such as WP Twin (mentioned in a later session), or a more rigorous approach to source code control of the plugins and themes directory may help in this area.

WordPress core has regular patch releases but these are too frequent for many enterprises to cope with. Although some enterprises operate a continuous integration model for their own software builds, regression and integration testing of external packages takes time and effort, and most organisations could only cope with a major upgrade every 18 months or so. Could this be alleviated by splitting functional and security releases?

What needs to change?
We discussed that there were three areas where change is needed:

How could WordPress change?
As discussed above, a different approach to releases, maybe separating critical security patches from functional upgrades.
How could the enterprise change?
Be less nervous about adopting open source packages such as WordPress; mitigate risks by using architectural approaches that match the internal infrastructure and applying enterprise disciplines to WordPress adoption.
What about the supplier ecosystem?
There are only a few suppliers offering services directly to enterprises, and there is certainly no “sales support network” that comes with major proprietary software packages. Should suppliers develop this ecosystem offering a relevant level of support to enterprise customers (a bit like the Red Hat model)? Such suppliers could also invest in the support and training materials needed to help customers adopt WordPress.

Follow-up from WordCamp UK
Since the session at WordCamp UK, the conversation continued throughout the weekend. Gareth Thompson has now created a site to help us manage that ongoing conversation.

Ben Balter is also working on a Google Summer of Code project to develop a document management plugin for WordPress. This introduces versioning and checkin/checkout functionality to document management using custom post types. Worth keeping an eye on.

Categories: Enterprise Architecture, WordPress. Tags: , , . Permalink. Post a comment or leave a trackback: Trackback URL.

Post a Comment

Your email is never published nor shared. Required fields are marked *

*
*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre lang="" line="" escaped="">