For 5 years, I worked on ExpressionEngine (EE) Content Management System (CMS), building and maintaining websites for The University of Texas (UT) Division of Continuing and Innovative Education (CIE). Is that enough parentheticals for you? Anyhow, EE is a wonderful tool. Perhaps it’s greatest strength is that you have complete (and I mean complete control over each aspect of display and output on a page. EE is a coder’s CMS, in that you work in the Template code itself. And when you need to dig deeper, you break out your PHP skills and go hog wild.
It wasn’t until CIE’s websites started experiencing severe caching issues on UT’s central web servers that the honeymoon ended. “Web Central” is a shared server, so it’s kept more secure than what you’d probably have running on your personal server space. The EE killer, as it turned out, was that this server runs with PHP Safe Mode ON. For those in the know, this prevents EE from being able to properly cache…and without cached pages, you’re doing a ton of unnecessary work on each and every page load.
So, there’s that.
Then there’s Drupal: a non-coder’s delight! Drupal (7, at least) is a dream! Pretty control panel interface. But really, to me, it comes down to themes. Oh, themes! In my opinion, themes are Drupal’s best quality. Without worrying a bit about any HTML and CSS, anyone can have a great looking website with relative ease. When it comes to data, relating data elements and building templates is handled very differently in Drupal & EE, but you can get most jobs done in either.
Where my personal conflict comes in is with with Drupal’s themes vs. EE’s lack of them. After building 20+ websites for CIE, there is boatloads of HTML & CSS that requires maintenance. Converting all those sites to be responsive, “by hand”? Yeah, right. No such resources. Had CIE gone with Drupal in the beginning, there’d be much less worry about HTML & CSS. On the flipside, if CIE had managed 20+ sites in Drupal and implemented similar client customization requests in Drupal sub-themes, there would also be headaches when the time came to update the look-and feel. It’d just be involved with theme-ing, instead of working purely in the code. Either way, big challenges lie ahead.
It seems Drupal gives you freedom from messing with so much display code. But when it comes to implementing the nitty gritty client requests that involve customization, is there that much benefit to creating a Drupal sub-theme vs. just editing a CSS file with EE? Your answer likely depends upon your personal preference.
