ExpressionEngine: The Details

In the process of switching from my own Ruby on Rails publishing system to using a third-party system (I decided on ExpressionEngine, as detailed here), I recalled a passage from the writings of Jianzhi Sengcan, an ancient patriarch of Chinese Chán (Zen) Buddhism.

The Path is not difficult for those who have no preferences.

The quote refers to the challenge of seeing things as they really are, making the attempt to become aware of how our minds unconsciously integrate our likes and dislikes into our experience, and how they affect our perception of the world.

Pretty deep stuff for an article about blogging tools, but I found that a little bit of reflection on this ancient wisdom went a long way as I evaluated software, doing my best to tease apart the pre-conceived notions I had about the way publishing tools should work, and be as open-minded as possible to a new way of doing things.

In my previous article, I didn’t want to go into too many technical details there at the risk of boring you with the technical details, but based on the comments, it seems that at least a few people are interested in the kind of thing.

What follows is a more detailed breakdown including the list of feature requirements, plugins and modules, and some of the compromises I made as a part of this switch.

I’ve been writing my own content management software, publishing tools, and blogging software for more than 10 years, and the prospect of switching third-party software to manage this site was an interesting internal challenge.

Abandoning the things I thought I needed — holdovers from software I’d written, previous system requirements, etc. — liberated me from feeling like the system had to be like something I’d built. Different was OK. It wasn’t the software that needed to be a certain way, I realized, as much as it was the man using it who might need to change.

This opened the door to an open-mindedness toward the process, and allowed me to pare things down to the most basic requirements. The new list of features I needed in order to publish this site was relatively short, and the additional requirements I was looking for were pretty specific.

Feature Requirements

Here’s the final list:

  • Search-engine-friendly URLs
  • Customizable entry fields
  • Anti-spam tools for user comments
  • Search functionality
  • Caching with automatic and manual purging
  • Basic image and file uploading
  • MetaWeblog API support
  • Straight-forward, customizable user interface
  • Multiple weblog support
  • Category (or Tag) support
  • RSS syndication (seems obvious but support is lacking in some systems)
  • Article inter-relationship management
  • Flexible and well documented templating language with conditional operators
  • Ability to embed actual code (e.g., Ruby, PHP) in templates
  • Support for sub-templates and/or dynamic file inclusion
  • Ability to edit templates both within the user interface and as files (handy for SCM)
  • Solid, up-to-date documentation
  • Responsive and accessible developers
  • Community support, forums, wiki

I also had a brief list of things I don’t need today but might down the road:

  • Member management tools
  • Member profile pages
  • Multiple author support
  • Entry Versioning
  • Pagination
  • Customizable form layouts/organization
  • Newsletter integration
  • Custom entry statuses
  • Future and expiring entries

Some of the feature requirements I started out with were holdovers from previous systems I’d built, and others were simply things I thought I’d need based on past experiences trying to mitigate limitations in third-party software.

For example, I anticipated that I’d need to create custom SQL queries in order to work around confines in either the templating language, or to “trick” the system into behaving the way I wanted on the main page. In the end, it turned out that I didn’t need this capability at all (although most systems had this).

After building software for a while, you naturally become inquisitive about the way other developers create software and tackle tricky problems. You look at the features in a system, and you think, “I wonder how they implemented this, I recall that being tricky to build when I tried it.” Good software can surprise you. I was looking for systems that handled those tricky problems with elegant solutions.

Many people might review the list above and think, “Plenty of other systems have all of these features too,” and that’s true. Many do. But ExpressionEngine had the combination of features I was looking for, a nice development community, a mature codebase (written in a programming language I’m fluent in), great feature documentation, a well-documented plugin system, and a user interface that made sense to me, and got out of the way when I needed it to.

At the end of the testing process, having spent several days (and in some cases, weeks) testing the different systems, I went with my gut and picked the system that I felt the most at home using.

Extensions, Plugins, and Modules

I found that it was possible for me to run a fairly stock ExpressionEngine setup (I’m using version 1.6.7, the latest release as of this writing), with only a few additional Modules, Extensions, and Plugins

Additional Modules


  • Textile is “a humane web text generator” (essentially shorthand to generate valid HTML) which I use to format many of my articles
  • TruncHTML provides HTML-aware text truncation, which I use to shorten longer article titles in the sidebar


The primary compromise I made in the switch from my own software was accepting the way ExpressionEngine creates and handles entry URLs.

Previous URLs

In my most recent publishing system, article URLs took this format:


Tag URLs looked like this:


Search engines seemed to like this URL format, and it was easy enough to generate. I’d gone back and forth over the years between embedding vs. omitting dates from the URL, and I didn’t have much of a preference either way.

Current URLs

Once you remove index.php from URLs, ExpressionEngine will create clean URLs in this format:


Category URLs look like this:


[Note that in the examples above, I’m using “articles” as the name of my Template Group]

From my own experiences building software like this, and from digging into EE’s code a bit, I understood why they took this approach. To be honest, I wasn’t thrilled with these URLs — especially the Category URL style. They just felt a bit wrong.

But again, those were “just preferences.” The new URLs were something I could live with. They were “clean” after all, and the search engines seem to like them just as well as my own. They get the job done.

I should mention that the Structure module seems to offer more granular control of URLs, but I haven’t tried it out.

Final Thoughts

I’m hopeful that this information has satisfied those of you who were curious about the details of my current EE installation. As always, please feel free to let me know in the comments section.

More articles in the Archive →