The Drupal Dilemma

September 29, 2011 – tagged Drupal, vismath, IT Security

At vismath, we're using Drupal to run our website. While we're also selling products from our website, we're not a “classical” web shop, in the sense of a mere collection of products that can be put into a shopping cart. Our goal is to have a platform about content, where these contents can also be purchased in one way or another. Because this needs the shop system to be tightly integrated into the actual CMS, we chose Drupal with Ubercart.

On one hand, this choice is an amazing success story: We can compose our content types using CCK fields (this is pretty much like OO design; well, more like struct design...), link those contents to product types, do all that in the web interface and in theory, one would have to write close-to-zero PHP code for all that. There's a module for virtually every CMS and shop functionality one might think of, like image display in various sizes (Imagecache), image slideshows (views_slideshow) fulltext search (apachesolr), content submission workflows (Rules), discount coupons (uc_coupon), selling file downloads (uc_file), landing pages (Taxonomy), exporting product listings as feeds, e.g. for Google Merchants (views_bonus), newsletters (Simplenews), LDAP integration (ldap_provisioning), a very flexible arrangement of contents (panels), and much more.

So what's the problem then? It's... well, let's look at the issues separately.

  1. It's PHP. PHP is slow, dynamically-typed, and by default very vulnerable to all kind of attacks. Of course it is possible to write well-performing, stable, and secure code (at least I've heard of that), but most people don't. In general, the use of PHP attracts all kind of people, in particular such that are not very familiar to any kind of programming techniques. Nothing against those people, it's fine to know a bit of PHP, and using PHP definitely opens Drupal development to a broad community, but the code quality often suffers from that.

  2. MySQL. In theory, Drupal 6 supports multiple DB backends, including PostgreSQL, which is what we are using. The core works ok with that (although performance on /admin pages is sometimes really horrible, like waiting for pages for minutes...), but custom modules... I guess many authors couldn't even say what the difference is between MySQL and PostgreSQL, but I'm pretty sure that most authors do not test their code against multiple DB backends. Double quotes are used as string delimiters, reserved words are used as column names, and other MySQL-specific queries all over the code.

  3. VAT. Ubercart is quite a powerful shop module, but it's obvious that it wasn't designed with German VAT rules in mind. These rules themselves are sometimes quite obscure and hard to understand, but they are there and need to be followed. Of course, it's not really the developers' fault; from a developer point of view, I would also avoid dealing with VAT if it didn't affect me. But still, it can be seen at many places that VAT is a concept that was added as a module and does not exist in Ubercart core, which often makes business harder.

  4. Deployment. Most Drupal configuration is stored in the database, not in code. Actually, the functionality is written in PHP and lives in modules, but the settings that trigger a certain functionality live in the database. As in addition, the Drupal database dumps are close to unusable for anything but dump and restore (because of the many serialized PHP structures in the database), it is hardly possible to have a professional deployment workflow. The Features module allows to put some combination of configuration and functionality in custom modules that live in code (so-called “features”) and thus to deploy them using some version control system, but still there are some problems that cannot be solved even when using features.
    Example: Moving an item in some list, e.g. the order of CCK fields, changes a certain “weight” in each field that can be exported into a feature. However, deploying that feature to a different installation may lead to unexpected results, as the “weight” may also influence the total order, not just the field that changed.

So we arrive at something that I call the “Drupal Dilemma”: On one hand, “there's a module for everything” and in theory, there's only very few code to be written. On the other hand, modules are often not working well with our setup and in some areas, the combination of some modules is so fragile that it is hard to anticipate the effects of adding another module. Will changing to a different CMS/framework solve the problems of Drupal while still providing a feature-rich set of add-on functionality for standard tasks? And if so, what CMS/framework will that be?

A list of must-have features would be:

  • No PHP.
  • Runs fine with PostgreSQL. (Database-independent would be great, but I guess that “true” database independence is a myth.)
  • Feature-rich shop module with support for VAT, file downloads, discount coupons, bulk prices, product variants, prices per user group.
  • Easy and robust deployment workflow.
  • LDAP support for authentication and user groups.
  • Content Management functionality.

I've been looking (very superficially) at a number of candidates that could replace Drupal for us. In particular, I was considering:

  • Django + Satchmo
  • Django + Django-Shop
  • LFS (Lightning Fast Shop), maybe with LFC (Lightning Fast CMS)
  • Plone + EasyShop
  • Also, I would like to do have a look at Lift, but I guess there's no production-ready shop solution available for that.

Django seems to be a good framework that's used by a lot of people. It just needs to be checked whether the existing shop solutions actually provide solutions for the problems we're facing now.

I'd like to know what you think about the Drupal Dilemma and whether there are other CMS/webshop combinations that I should have a look at. Please comment and let me know – thanks!