more about WordPress
In part one of this post I offered some advice on how you might go about choosing the right CMS for your business. In this part two, working on the premise that WordPress is often quicker and easier to work with and where resources, assets and support are more readily available I look at what else you can do to leverage that to make WordPress development cheaper still. In part three I’ll go over what other options are available other than WordPress or Drupal, before finally closing on how we chose the right solution between the two.
if WordPress is quicker and easier and thus more cost effective, how can we make it cheaper still?
I think we make WordPress even more cost-effective by exploiting what it's good at.
From a design perspective there are a huge amount of production-ready, sector specific (i.e. travel, news) themes which can be used for the front end of the WordPress site. Any one of these can be made unique with a limited amount of designer or front end developer time, significantly cutting down on design and front-end coding costs.
I've always seen Drupal modules as being independent building bricks, used in combination with each other and the rest of the Drupal ecosystem to create a piece of functionality.
WordPress’s broad equivalent are plug-ins, which, by comparison, in general provide a complete piece of functionality, like an image gallery. It’s not uncommon for there to be a huge number of plug-ins which do almost the same thing. Chances are one will give you pretty much what you want out the box, with the gap being filled by a tweak or a trade-off. Using plug-ins to get up and running with the most common CMS features is pretty quick and won’t require lots of site building or development time.
maintenance: managing security updates
WordPress has a well established auto-update feature for applying updates when a security or minor release is available. For major releases, you have to initiate the update yourself. You also have to install plug-in and theme updates yourself, although there are ways by which you can automate the update of all plug-ins (via a code change), or selected plug-ins (via a plug-in!). Of course, depending on whatever else you have installed on your WordPress site there’s no guarantee that the updates won’t break it – so some level of regression testing is still a good idea. But that notwithstanding, on-going support costs, especially if the functionality rarely changes, should in theory be a lot lower. The one downside of auto-update is that it doesn’t, as yet, work with code that is version controlled (VC). There are also some security considerations, but these can be effectively mitigated.
There are ways in which Drupal can also auto-update, but it’s more complicated and costly to put in place and manage, because it is predicated on code being version controlled.
maintenance: managing rolling out new functionality
The way in which new functionality can be rolled out depends in the first instance on whether the code is VC. A lack of VC means that any updates you make will require the site to go into maintenance mode for a period of time. Managing sites via VC requires certain processes to be in place, which are generally reflected in costs. However, if you don’t mind the odd period of your site being in maintenance mode (like at 2am for three hours on a Sunday) for updates those cost savings may be worth considering.
VC is the starting point in reaching a nirvana where updates can be rolled out without the need for a maintenance page. This is because it opens the door to code driven development (CDD), where changes to the structure of the data model are triggered by code, in an environment where code managed by multiple developers is continually merged together into iterative rebuilds of the site, a process known as continuous integration (CI).
It’s possible to manage VC/CDD/CI in WordPress, but we’d argue that the processes to do so in Drupal are more wide-ranging and flexible. In any case we have processes and learning built around Drupal and neither see the need, nor have the scale, to diversify.
Returning to our point on WordPress being easier for individuals, a system which is managed by one person has less need for VC because no one else touches the code, whereas a team of developers cannot work on a solution without significant pain without VC. In the right circumstances a lack of VC will save costs if you’re prepared to run or mitigated the associated risks we’ve described.
If you’re not versioning your code then it’s less likely you need multiple environments (like a dev site and a staging site) and the build scripts to move code, databases and web site assets (images, documents) between those. Not only will that save on hosting costs, it’ll open you up to more hosting suppliers, thus providing more competitive pricing.
In part three I’ll go over what other options are available other than WordPress or Drupal, before finally closing on how we chose the right solution between the two.
If you want to take back control of your web sites and applications then get in touch with miggle to see how we can deliver operational freedom for you in Drupal.