In a previous article I did a bit of griping about ExpressionEngine. After spending time building a full site with the commercial CMS, I was left impressed with some of its features and quite unimpressed by it’s lack of others. As I promised in that article, I’m going to cover some of what I did like about ExpressionEngine here, as well as let you my final opinion and whether I plan to continue using the CMS.

Now, on to the good parts of EE…

Solid Support Forum, Documentation

I’ve become quite convinced of the idea that no CMS can succeed without excellent support in one form or another. EllisLab obviously understands this… the documentation is good, laid out clearly, and the search function works very well, which is a big help for those times when you can’t quite figure out where to look for the information you need. The docs get another point for the comments, which users can contribute to, at the end of each page; this was a great help for understanding some of the system’s intricacies.

Anything I couldn’t find in the documentation I was able to find in the support forum. They’ve built up quite a support community and, although the employee moderators’ SEO knowledge leaves something to be desired, I found most of the community to be knowledgeable and more than willing to provide helpful advice.

Impressive 3rd Party Contributions

I have to say, I was impressed by the quantity and quality of 3rd party addons for EE. Ellis Lab has managed to build up a community of developers and passionate enthusiasts that any commercial CMS developer would envy.

Easy-to-navigate admin UI

Although it might take a bit to get familiar with the administration UI, once you do, it’s very nice and easy to navigate. Most of the frequently-accessed pages are linked to directly through a tab at the top of the screen. The more advanced, perhaps less frequently-accessed pages are buried a bit and, while that may seem frustrating at first, it’s nice to not have the main interface cluterred with information you rarely need to access.

I said “most of the frequently-accessed pages are linked to directly” because some aren’t. The good news is EE lets you add a new tab in just two clicks, so you won’t have to hunt around for those burried sections of the admin that you find you need to access frequently.

Development Mode

EE has a great feature that, when active, prints out a long list of useful program information at the bottom of every page for the super admin for debugging. This is something I inevitably create at one point or another for most projects, so it was nice to have it already done for me when I needed some pertinent program info.

Final thoughts

One thing you’ll probably notice is that only the admin structure and development mode are not, by default, something WordPress has. You’ll also notice that my complaints about EE were a bit more serious than my praises. That’s because after spending quite a bit of time with EE I’ve concluded that it doesn’t do anything that another CMS can’t do easier, better or faster. In fact, a few of it’s key features are strangely under-developed – I mean, come on, I can’t duplicate custom fields across sections? Custom fields are the foundation of a general-purpose CMS. That issue, among others, needs some serious attention in the next major release.

Will I use ExpressionEngine in the future? Unlikely, unless I absolutely have to. It was a good learning experience, but other than that, my time with EE only served to remind me what I like about WordPress.

Okay, so I’ve been playing with ExpressionEngine for a few days now and, after building a site with it, I’ve got a few frustrations I need to get out there. I don’t mean this as an attack on the system and, in fact, I’ll review what I did like about it in the next post, but here are some of my gripes after my two-day foray into the world of the commercial CMS from Ellis Lab.

Issue 1: Custom fields and lots of rework

For those used to WordPress, you know the “Write post” page has a title field, a body field, an excerpt field, etc. These are all conducive to blogging, but ExpressionEngine is designed as a general purpose CMS and, as such, you define your own fields, such as title, body, thumbnail image, full-size image, etc. Then, you assign those custom fields to a section of the site and, when adding an entry to that section, the assigned fields appear.

Since custom fields are such an integral part of the application, I’m baffled by the inability to copy/duplicate custom fields from one site section to another. I can’t help but wonder what the hell were they thinking with this one? Most sections of your site will have their own sets of custom fields, but if you’ve got two sections that use a thumbnail field, for instance, you have to create that thumbnail field in both sections, you can’t just duplicate it from one section to another. Which means there’s a massive amount of rework duplicating fields that are to be used in multiple sections, and I hate rework.

That said, there’s a great plugin called Gypsy to help manage these fields, but I don’t like the idea of relying on a third party developer for something so basic.

Issue 2: Template management is all out of whack

Template management in ExpressionEngine is very strange. First of all, you have to create page templates from within the backend…you can’t just add a file and have ExpressionEngine see it like you can with WordPress. This is just a flat out hassle to have to deal with.

Second, let’s say I create 10 empty templates that I want to edit in dreamweaver…I can’t just create the templates and have them instantly accessible via dreamweaver. In order to edit templates as a file, I have to first open each individual template in the EE backend, check a box that says “Save as file,” and then save it…if I have 10 templates, I have to repeat this process for 10 separate files. That’s a huge waste of time and I’m not sure why a $300 piece of software doesn’t have something as basic as saving those template files in bulk, or just automatically creating the actual files when a new template is created through the backend.

Again, there is a great plugin that allows you to save templates to the file system in bulk, but I’ll reiterate, when I pay $300 for software, I don’t want to have to rely on 3rd party developers for such basic functionality.

Issue 3: Again with the templates

Another templating issue… When saving templates as flat files, they can only be saved with a .php extension. That means you have to save your CSS files with a .php extension. So, when you open your CSS files to edit in your favorite editor, the color-coding is off because the editor thinks it’s editing a php file. I managed to hack a solution by using PHP’s include() statement to import my real CSS files into the ExpressionEngine CSS templates, but this just adds another layer of complexity and time to site development and makes me feel like I’m hacking together a solution.

Now, don’t get me wrong, at WordPress Hacker I love to hack together solutions, but I’ll reiterate once more, when I pay $300 for a CMS I expect to not have to spend time hacking together such basic features.

Issue 4: URLs and duplicate content galore

Finally, URL handling is abysmal. When setting up your site in EE, you create what are called “template groups” to organize the different templates and setup the URL structure of the site. So, if I want a blog, I could create a template group called blog, and within that template group would be the blog index file. The URL to that index file would then, by default, be http://mydomain.com/index.php/blog/. Not too bad, but I don’t like that index.php in there and, although it’s removable via some htaccess magic, EE advises against it in a number of places, even though they appear to be doing it themselves.

Things take a turn for the strange however when you see how the urls for individual blog posts (or any other section of the site for that matter) turn out. If I use a template called single.php to display individual blog posts (similar to wordpress), your blog post urls turn out like this: http://mydomain.com/index.php/blog/single/blog-post-name/. What’s happening is EE uses the URL to decide which template to use for that page, in this case “single.” I have two problems with this…first of all, it adds unnecessary complexity to the URL structure, and secondly, that individual blog post is accessible via any template in that group, so if I have a “page” template in the blog group, I could also access that blog post above via http://mydomain.com/index.php/blog/page/blog-post-name/. All these URL problems can be fixed via htaccess if you really know what you’re doing, but come on, this is a $300 CMS…I expect to not have to rack my brain writing complex htaccess rules for something so basic as preventing the exact same content being served through 2 (and perhaps more) separate URLs.

I’ve been playing around with ExpressionEngine for a few days now, so those are all my gripes to date. However, now that I’ve vented my frustrations with the platform, I should say that, overall, I’ve found ExpressionEngine to be a pretty solid piece of software for my own purposes. Is it worth the $300 when there are so many free alternatives out there? The jury’s still out on that one….give me a few more days and maybe I’ll have an answer. And to be fair, I’ll cover what I liked about the software in another post (Update: You can find out what I liked about EE here). Until then, happy hacking.

ExpressionEngine