An ExpressionEngine developer in Drupal - Part III

As I come to the end of the first phase of this Drupal project, I thought this would be a good point to share my thoughts.

As I come to the end of the first phase of this Drupal project, I thought this would be a good point to share my thoughts.

Make no bones about it, Drupal is a very powerful framework to build a website. Like ExpressionEngine, it powers some really high traffic websites like the White House ), Lady Gaga, The Beatles and soon to be, Paul McCartney.

As I’ve touched upon before, working with an experienced developer who knows a platform has been absolutely essential on this project, there’s no way I’d have gotten as far without guidance from Paul. Also, the video series on Drupal front-end development by Drupalize.me was handy as well, detailing the options available when building out a Drupal front-end. 

The Negatives

My biggest bug-bear with Drupal though is what it was when I first looked at it years ago — control over output markup. Don’t get me wrong, I’ve learned how I can control markup better theme overrides but there are still instances that output some truly horrible markup. 

In an ideal world, I’d love to have control over every part of that component but in this instance I don’t. A more problematic instance has been the main and secondary nav menus. 

There was no way I was able to add a unique class to both. I could set one but that involved using a template.php to override the default theme function. I understand in part why Drupal uses blocks and regions but I generally wouldn’t give a client access to alter where a page component will reside on site. All I want my client to be able to do it author/edit the content of their site (and of course reports if it's a commerce tool as well). 

 This is the main reason I love tools like ExpressionEngine, Statamic and Craft. It assumes nothing about the markup. I can build a component outside of the system, drop it into a template and then replace the parts with native tags and parameters that don’t get in the way. 

The Positives

I’ve spoken before about Drupal Features which is pretty neat when you’re making database changes to be shared amongst a team. The other feature I really like about Drupal is a tool called Drush described as: 

a command-line shell and scripting interface for Drupal, a veritable Swiss Army knife designed to make life easier for those who spend their working hours hacking away at the command prompt. 

Now don’t get me wrong, a CLI puts a lot of people off. Even trying to get some people to embrace the Git CLI is a challenge — I hate parts of it myself — but a CLI is a very powerful tool. For example, if I wanted to clear the cache in Drupal, I can do `drush cc all`. 

 The ExpressionEngine users amongst you know how much of a pain upgrades can be. Drupal allows core upgrades (and third-party modules as well) to be done via the CLI `drush pm-update`. You can add users, sync environments, install modules, add fields to content types. You can have an element of this with Statamic, dropping in your flat files but I’d love to see ExpressionEngine and Craft have something like this.