CloudEngine and the Cloudworks website are based on the CodeIgniter PHP framework. However, this wasn’t originally the case. The first version of the Cloudworks site instead used the Drupal Content Management system and we only moved over to CodeIgniter a year or so ago. I have been asked a few times about our reasons for this move, so before I go on maternity leave I thought I should put them down in writing.
Any sort of rewrite is a risky decision to make, but in this case it is one that that I am really pleased with. It took about a month for me to migrate the code over, although that time also included implementing a new design for the design for the site. We lost a tiny bit of functionality in the move – you get lots ‘for free’ with Drupal – but nothing significant.
Before I start, I want to say that I am still a fan of Drupal for certain types of projects. It also has a great community that seems to be doing all the right things in terms of the directions that Drupal is moving forwards. In fact, I have chosen to use Drupal for other projects since. So please don’t take this as an all-out attack on Drupal, rather as some reasons why it wasn’t right for us in this context.
There are three main reasons why we moved and why I am glad that we made the decision to switch to CodeIgniter:
1) Productivity Curve
With Drupal, you can get the majority of a site built very quickly, but those last details can be agonising. Drupal has a lot of built-in functionality that you can effectively just switch on. It is also straightforward to write simple modules of your own. However the flip-side to this is that if Drupal doesn’t do exactly what you want, for example if you want a slightly different user interface or some subtle change in functionality, you often find yourself back at close to square one. If you have a site that you just want to be ‘good enough’ and to get up and running quickly, none of this is a problem, but if those details do matter to you, the time you saved at the start is quickly eclipsed by this time fine-tuning at the end.
Using a framework such as CodeIgniter, you do have to write everything from scratch and it is a little bit more work to get things set up at the start. However, having a framework does speed this up a great deal and writing new functionality with CodeIgniter is, if anything, quicker than writing an equivalent Drupal module. There are also lots of libraries out there that you can use with CodeIgniter, so you often aren’t starting from a completely blank slate. On the other hand, when you write some code in CodeIgniter, you can write it so that it does precisely what you want it to from the start.
Some of this difference comes down to learning curve of course. I’m certainly not a Drupal novice. I’ve written a fair few modules for Drupal and know a certain amount about how to override core behaviour in Drupal for example, but I definitely wouldn’t class myself as an expert either. I readily admit that for somebody with more knowledge than me, the difference in productivity between Drupal and CodeIgniter would be less extreme. Indeed I’d be genuinely curious to know how quickly a Drupal expert could replicate the Cloudworks site. However, any time taken learning more about Drupal is time that would have needed to come out of the time allocated to development of the site. In contrast, you could read all the CodeIgniter documentation in a day and I haven’t yet known a PHP developer who hasn’t been able to pretty much hit the ground running with CodeIgniter.
Aside from learning curve, I suspect that there are some things that are just fundamentally difficult to do in Drupal. I am in two minds about whether to go into specifics here as I don’t want to get dragged down into microissues. If you want a taster, you can see a few examples of my questions on the Drupal forums http://drupal.org/tracker/371512 before I gave up asking there! I know that that some of the issues I had have been fixed in later versions of Drupal, but I also have memories of having problems with dealing with images and configuring the registration form and user profiles quite how I wanted them and I doubt all of these have been resolved.
2) A different way of working
Working with Drupal felt a bit like building a boat by starting with a car and gradually modifying the car until it became a boat, whereas working with CodeIgniter felt like building a boat from scratch. This changes your mindset significantly when you are working on a site. Now if what you are building is very close to the ‘Drupal model’ then this isn’t too tough, but if it’s not then the mental process of figuring out how to twist Drupal to meet your requirements is much more of an uphill struggle.
Theming is a good case in point when it comes to this different way of working in Drupal versus CodeIgniter. If a designer produces some HTML and CSS for you, you can drop this straight into a site using CodeIgniter but with Drupal, you can have a major piece of work on your hands making it into a theme. Working with a designer on a Drupal version of the site was much trickier as I had to try and explain what would make a design feasible to be turned into a Drupal theme. More generally, I found it trickier discussing work on the site with other people on the project when we were using Drupal compared with when we started using CodeIgniter.
There is also has a more subtle effect. Instead of starting out thinking ‘this is what I would really like the site to be like’ you find yourself naturally looking at what modules are out there and whether they might be useful. This is quite a different way to look at building a site and means that you are less open to ideas for which there aren’t easy Drupal solutions.
3) Site structure in the database
The way Drupal works is that in order to be configurable via a nice user interface, lots of the important information about the site sits in the database. So as well as containing the ‘site data’ such as details of all the users, the text of content and so on, it also contains the ‘site structure data’ for example specifying the types of object (nodes in Drupal-speak) for your site and the ‘views’ of the data that you are using on specific pages. It’s exactly this that makes Drupal so easy and flexible to configure for non-developers. On a site using a framework like CodeIgniter, such information would be more ‘hardcoded’ into the structure of the database or the actual code for the specific site in question.
This has a few knock-on effects. First, pushing quite simple changes in functionality to a live Drupal site usually isn’t as simple as just updating the code. This was a little while back so there might be a nice solution to this nowadays (let me know if there is!), but in practice, to update the live Cloudworks site when I was using Drupal, I normally ended up having to write lists of all the actions that I had performed via the Drupal admin interface and repeat these on the live site and hope that I hadn’t made any mistakes and then pray that I didn’t need to rollback for some reason. Secondly, it would have made life much more complicated for making our software open-source in terms of support. It’s easy to be reasonably confident that somebody is using an unmodified version of your code, but it’s harder to be certain that they haven’t changed something vital in the Drupal admin interface. Finally, the Drupal way of having the site structure information in the database means that database queries can easily get thorny. This isn’t a problem too often, but queries that are now only moderately complex using CodeIgniter were often absolutely horrendous in Drupal.
I think the cumulative effect of all these things was that I became a much happier developer when we moved to CodeIgniter. I somehow felt in control of my code again and I spent less time tearing my hair out trying to find some Drupal workaround! As a result, I also felt I had more energy and enthusiasm to put in the site. Overall, although the move could be regarded as slightly controversial and I was nervous about it, I have no doubt that it was the right one for us in our situation.