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
- Akismet for Expression Engine to block comment spam
- Metaweblog API allows me to use MarsEdit when needed
- Pages
- Search
Plugins
- 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
Compromises
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:
/articles/YYYY/MM/DD/short-entry-name
Tag URLs looked like this:
/tags/name-of-tag
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:
/articles/view/short-entry-name
Category URLs look like this:
/articles/page/category/short-category-name
[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.






PXLated
24 April 2009 at 9:01 am
Looks like a nice, clean, fairly standard install. That’s what I like about EE.
Just to clarify for those not familiar with EE - Other than the Askiment module, the other modules are part of a standard EE install. It seems to confuse some that are used to systems where almost every function requires a third-party add.
Pedro
24 April 2009 at 11:39 am
Looking through your list, and based on what I know of Movable Type, I’m pretty sure MT could have handled all of your requests except for the optional feature of Entry Versioning (though some of the Caching might also need some attention). I know there is a solid debate between Movable Type and Expression Engine, since both seem to be the truly solid players in the pro/consumer CMS market. I noticed on your previous entry that MT was listed first in the other systems… possibly indicating that it came in second place overall. I can’t fault you for your choice, since you obviously did your homework. It’s interesting to see what criteria others have for their CMS.
Marcus Neto
24 April 2009 at 1:14 pm
Very nicely done. And I think what is so great about working online at this point in time is that there are a number of systems that could have handled the requirements that you listed. While I am kinda partial to EE I also use the others. I think the real testimony is just how few plugins you had to use to complete the site. ExpressionEngine rocks! ;-)
roger wilco
24 April 2009 at 1:22 pm
I do love ExpressionEngine. I wish the back end didn’t always make me feel like I was updating a corporate accounts payable spreadsheet. Compared to super-friendly and personal admin sections like Wordpress and Tumblr, it’s a little imposing and cold.
Tony Djukic
24 April 2009 at 3:11 pm
Maybe someone on here can answer a question for me that no one else seems willing to take on; I’ve got a client that needs a CMS installation that will allow users to sign up and essentially get their own blog - the trick is that isn’t really a blog. It’s a simple 2 page profile piece (1st page is text and a photo or two - second page is a photo gallery)... ...I’ve tested with MT and their sales dept. was unable to answer very many questions for me. Telling me that you ‘believe’ it can be done using MT doesn’t really put me in a better position than I was in previously as I had, obviously, contacted them because I too felt MT would most likely be able to handle the concept.
So now I’m wondering if EE might have a more straight forward approach to what I’m looking for?
To outline it in a step by step process it would work as follows:
1. User registers for account
2. User is given access to account (automated) and can begin inputting content and photos.
3. User can select their choice of themes.
4. Different accounts are searchable by region/name/other variables…
Seems straight forward right?
But it isn’t. I’d like to take a second now to explain that I am, by no stretch of the imagination, a developer. I’m a designer that implements other people’s developments (both Open Source and Fee based) into my designs. So please, be gentle and no ‘guffawing’ at how silly this question is.
Thanks guys,
Tony
Judd Lyon
24 April 2009 at 10:09 pm
Love the quote about preferences.
Nice rundown of EE, it really is nice software.
In addition to Structure, the Pages module gives you carte blanche with URLs as well. Doesn’t cure the category BS though.
I’m crossing my fingers that you cook up a few extensions at some point. ;)
Raymond Brigleb
25 April 2009 at 8:24 pm
Nice post. We’ve come to similar conclusions at Needmore. We end up using EE more often than not for basic client sites, it really does work well and it’s fast. I do have some major issues - mainly with image handling - but for the most part it’s a really solid system.
Steve
27 April 2009 at 6:55 am
Tony:
You might want to post this in the EE forums but from my own experience, this most likely won’t be possible with EE. I used EE to create a directory (http://greenindex.ca) and it works fine for that but your biggest stumbling block will likely be legal, not technical. Your requirement of allowing users to select their own theme means you have to assign them their own weblog. This will likely violate the EE license (details here: http://expressionengine.com/knowledge_base/article/myspace_blogservice/).
If, however, you only give pages or posts from a single weblog to the user, you won’t be able to assign a theme to them (as far as I know).
Hope that helps. Again, you will probably get more definitive answers in the EE forum.
Kirk Franklin
27 April 2009 at 12:31 pm
/articles/YYYY/MM/DD/short-entry-name
You can do URLs like that in ExpressionEngine if you use the index template in the articles template group, which works the same way as an index.html or index.php file would. Then you can leave “index” out of the URL.
User can select their choice of themes.
You should be able to do this in ExpressionEngine with a custom profile field in
http://expressionengine.com/docs/cp/admin/members_and_groups/custom_profile_fields.html
The field could be a dropdown list of stylesheets that match the different themes.
Different accounts are searchable by region/name/other variables…
Solspace’s User module can search custom profile fields.
http://www.solspace.com/software/detail/user/
Isko
28 April 2009 at 4:57 am
It’s actually pretty easy to create the URL structure like this:
http://yourdomain.com/YYYY/MM/DD/entry-name
It’s described in more detail here: http://www.engaging.net/articles/converting-subtraction
coskunlar vinc
28 April 2009 at 2:35 pm
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.
http://www.coskunlarvinc.com
Anil
29 April 2009 at 6:29 pm
Interesting writeup. N.B. you may be interested in TypePad AntiSpam in lieu of Akismet: 100% API compatible, fewer false positives, doesn’t cost money no matter how you use it, and fully supported by the EE module you’re already using. Just a tip.
Christian Dalsvaag
30 May 2009 at 7:29 am
Really nice article. I like the way you present material, so pleasant to “listen to”. Thanks!
Scott Johnson
31 August 2009 at 12:56 am
The URL for this page doesn’t seem to match up to the schemes that you mentioned above in this article. What was your solution for getting the URLs you have now?
Brandon Klapholz
07 November 2009 at 4:14 pm
Ever consider Java based CMS’s (e.g. Magnolia [http://magnolia-cms.com])?