Why we moved from Drupal to CodeIgniter

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.

Finally

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.

 

Advertisements
This entry was posted in Uncategorized. Bookmark the permalink.

18 Responses to Why we moved from Drupal to CodeIgniter

  1. Nick Freear says:

    Hi,
    Thanks for this write-up – a useful, and I thought balanced summary.

    I agree with your basic reasoning. I liken Drupal to a Swiss-army knife — very useful in lot’s of situations, but a bit uncomfortable in others! I have probably got to the same point on the Drupal learning curve. I found some module development quite rewarding, but other stuff (Ajax/AHAH forms!) needlessly fiddly. (I should say, I’m not closing the door on Drupal at all!)

    With my Cloudworks/CloudEngine hat on ;-), I’m happy with the move to CodeIgniter. I like its light-weight approach, and I found it easy to get up to speed.

    Cheers,

    Nick

  2. Mike L says:

    Thanks for this post! I’ve been looking for something like this for a while now, and all I’ve been able to find are overzealous Drupal blogs about how you can do anything and everything in Drupal. I love the boat analogy, as I think it fit’s perfectly! If you have to constantly bend, blur, and break something to get it to do what you want, why are you using it? How much time do you really save in fighting with a Drupal module for a week to do something as simple as posting a form via AJAX, adding in new CSS, importing a new JS file, etc.

  3. Pingback: Weblog of Will Woods

  4. Great post, we as a company have now started to move away from Drupal for all the same reasons that you mentioned plus more.
    Typically when we are really busy we out source some of our development work. Normally I don’t even worry if the developer has any knowledge of Codeigniter – php classes that do the job which I then “Codeignite” them.
    However the straw that broke the camel’s back has been the shift from Drupal 6 to Drupal 7. Apart from the endless updates (which is hard work when you are maintining 100+ sites) we got to a situation where we couldn’t upgrade to Drupal 7 because a lot of the models we use did not have a version for 7. We now have the problem that some models only work on Drupal 6 and some new modules that only work on Drupal 7.

  5. This article has helped me a lot. Thank you!

    I’ve been working with Codeigniter for about 15 months and was thinking about switching to Drupal. My main reason for thinking about the switch was because I think Drupal would enable me to build sites very quickly (I’m a professional website builder). However, having read your article I think I’ll probably best to just stick with CI.

    Many thanks indeed.

    • Klaus says:

      I worked now over three years with drupal and now it is time to switch to a framework.
      I think I try it with CI or Yii.
      The most reasons for switching are write down here in this blog post.
      A very important reason is for me that drupal has a lack with his performance.

      From version to version the performance slow down.

  6. Nick Freear says:

    Hi,
    Thanks for the comments, Mike, Kevin and Parkerandhobbes.
    It’s interesting to that our experiences strike a chord with you.

    You may be interested in this post about why I chose CodeIgniter for another project at The Open University.

    As I say there, in the Institute of Educational Technology we continue to use Drupal for a number of web sites, but it’s obviously about picking the technology for the project.

    Best wishes,

    Nick

  7. glynology says:

    Very nice post Juliette, agree with arguments 100% and my fellow commentators above, I am coming from a slightly different angle in that, as a Visual Studio developer (or now used to be) for many years and I cannot count the number of times during projects I had to dig around and tweek things until they worked if that was what the client wanted.
    I will keep in mind what you have said as I have built a pre-production server for a start-up project currently running two sites (building the server: http://glynology.info/tag/development) and intend to experiment with both Drupal and CI, and now will play with CloudEngine thank you for your insights.

    Cheers,

    Glyn.

    blog: http://glynology.com
    twitter: http://www.twitter.com/glynology

  8. Ryan Cross says:

    Just a small note to say that the issues have you have raised are well known and to some extent have been addressed.

    I would particularly point out the features module, which allows you to take all of the configuration from the database and export it into code so that you can do all your updates via a simple code update.

    • cloudengine says:

      Thanks for the info on the features module, Ryan – will definitely take a look at that next time I work on a Drupal site. Would be very interested in any more info on how these issues have been addressed as I’m not interested in Drupal-bashing here, just working out what it is suitable for and what it is not.

    • Jason Kirst says:

      I’ve tried using features more than once for migrating configurations, and both times have ended up returning to making a list of changes on dev and repeating them upon deployment to production.

      There are two main problems with using the features module: 1) Not all modules, including core modules, support features, which means that you end up having to either patch those modules or keep track of those settings separately anyway, and 2) on a complex site or even simple web app, simply managing and refactoring the features hierarchy and configurations themselves can turn into quite a bit of overhead.

      Don’t get me wrong: I think features is great and the guys responsible for it – developmentseed – are super-cool. But I’ve hardly found it a panacea for the drupal configuration migration problem.

      Furthermore I can certainly relate to the whole “last details are agonizing” issue the author points out! To be fair, those “last details” are typically the toughest for _any_ software project – but the amount of code one has to deconstruct and wade through with drupal can make it especially frustrating.

  9. Franko says:

    Thanks for sharing. Great article!

    Right now, I’m in the situation to tearing my hair out trying to solve some configuration problems in Drupal so I can get what I want. I was building websites in my custom CMS (asp.net) for three years. After that, I spent another two years configuring Drupal websites. And you know what, when I look back – I spent the same amount of time for Drupal website like modifying my own CMS engine to build web sites.

    Tweaking that multilingual options, combining all those modules, patching some of them, staying up to date with new versions… I’m tired of that. Analogy with reshaping a car to get a boat is absolutely beautiful. That is exactly what I’m doing last two years.

    This problem was the reason why I started to search for another approach how to build web sites more easily and faster . I think that taking a small and elegant web application framework (like CodeIgniter) and accept some Drupal approach how to handle content (blocks, menus, regions…), is the way to go.

    And I hope I will enjoy writing code a little bit more then I do now. And finish my project much faster.

    Thanks again.

  10. Amitav Roy says:

    Well I personally feel that Drupal has its own target. Not all sites require CMS. Drupal is very handy when you want to make websites with a very strong back end where the end user is going to do a lot of work. If it is a simple blog with not much to add from functionality point of view, then I guess Drupal will be an overkill. Even wordpress has lot of things which are sometimes not required.

  11. Sorin Tudor says:

    New entities api Drupal module it’s a good alternative to MVC codeigniter programming style Please look at http://www.trellon.com/content/blog/creating-own-entities-entity-api
    On the other hand Bonfire Codeigniter extension implements Drupal like RBAC auth., themes.
    Drupal modules already cover CI extensions facilities.
    CI with his extensions will cover drupal and drupal modules facilities.
    Drupal already shine. CI shine enough. Present is drupal best friend. Future will be ci best friend.

  12. I like this very much.
    “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.”
    This reminds me of Bruce tate’s “Faster, Lighter Java.” Bloated documentation is a big drag on productivity.
    Thanks a lot.

  13. Pingback: Curriculum Design Technical Journeys: Part 1 « JISC Curriculum Design & Delivery

  14. Prem Goyal says:

    Great Post…..Thanks for you valuable directions…

  15. Marco Telles says:

    Hi Juliette,
    I quit to “pure” programming when by indication I used Drupal, but… recently I feel tedious and your post tells exactly what I think.
    I just have to add how is very tedious to become a “installer man”, “configurator man” and “search man” of modules and blocks when we could be writing beautiful lines of code, algorithms, etc.
    Thank you for your (old) post. 🙂

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s