Content Management Systems I’ve Used

In my two decades of developing and managing websites I’ve used quite a few different website content management systems (CMS). I thought I’d take a minute to document each of them, where I’ve used them and which I prefer.

Content Management Systems I’ve Used

These CMS’s I’ve either developed for, used on a production website or both. They’re listed alphabetically.

Big Medium

Used from 2006 – 2010.

This file-based CMS I used for smaller sites for several years until I realized the developer had essentially stopped working on it (this was in late 2008/early 2009). Soon after, he announced its end of life.

Documentum

Used from 2002 – 2006.

I used this while I worked at the U.S. Senate Sergeant at Arms. It was more than we needed and not easy to use. I stopped using it because I changed employers.

DotNetNuke

Used briefly in 2006.

When I left the Senate and started at my new full-time gig I inherited this CMS for our intranet. I immediately dumped it for flat HTML. The backend was clunky, creating templates was difficult and managing users was not intuitive.

ExpressionEngine

Used from 2009 – 2017.

I also absolutely loved ExpressionEngine. When I started using it in 2009 it was a cutting-edge CMS for both membership sites and for creating a website with a unique content model. The user and developer community were actively engaged and its creator, the developer community and the plugin development community were second-to-none for support. The product was rock solid. After several years, open-source and equally capable products like WordPress and Drupal drained interest in a product with a price tag. I ultimately stopped using ExpressionEngine because the plugin community dwindled, the product was slow to provide updates and it was becoming harder and harder to find developers who had used the product.

WordPress

Used from 2008 – present.

I absolutely love WordPress. The backend interface is gorgeous. Those who use it to publish websites find it incredibly easy to use. With the right plugins, it can power a very high-traffic, high profile website. The user community is massive. This is my “go to” CMS for just about every project.

On ExpressionEngine vs. WordPress

Several years ago I decided to take a look at the popular web-based content management systems available, choose two of them and focus my website development efforts around them.

It was time. I had been a strong proponent of Adobe Contribute for years as it made managing websites for non-HTML savvy folks very, very easy. But I saw value in web-based products versus buying an app that needed to be installed on a computer.

The Analysis

So, I looked at Drupal, ExpressionEngine, Joomla! and WordPress. I know there are others, but these are the ones that jumped out and appeared to have a strong, committed developer base.

Truthfully, my review was not scientific, but the biggest factors in my assessment were:

Aesthetics of the product’s website and admin,
The commitment of the teams responsible for updating and upgrading the product,
The apparent size of the product’s developer base,
Availability of documentation,
The price, and
How quickly I felt comfortable creating a site using the product.

The Winners

WordPress was an instant winner. The price tag was right, the commitment of not only its creator but also of the core team made was evident and documentation abounds. Also, the admin area for entering and managing content was—and remains—beautiful. It was a natural choice.

At the same time, I kept hearing of this product called ExpressionEngine. I didn’t know much about it, except that it was used by some high-traffic, high-profile websites. And that impressed me. The product was in transition moving from a very solid version one-dot-something to version two. They had a beta of version two available, so I downloaded it, found a book about it and got busy. Out of the box, EE is powerful and incredibly customizable. I was initially a bit overwhelmed by the granularity of the settings, options and capabilities, but I was impressed by a clean admin interface, a very strong and responsive support forum and the commitment of the community behind the product.

So there were my two winners: WordPress and ExpressionEngine.

The Ones Who Didn’t Win

It’s unfair to call Drupal and Joomla! “losers” because they didn’t lose. To say they “lost” implies that the products did not meet any of my very non-scientific criteria. They both do have strong developer bases and committed teams to improving and updating the products. Documentation abounds and they’re both free. And they each have an incredible global installed base.

But I just did not feel comfortable using them. And that’s the non-scientific part of it, really.

Why brettro.com is WordPress

Shortly after choosing both WordPress and ExpressionEngine, I had a major project where EE was the perfect choice. I still manage that website today, use EE daily and absolutely love it. (I wish I could tell you what that website is, but I am ethically bound not to.)

Because I was already using EE on a daily basis, I felt that I needed to use WordPress on a website that I would also manage daily so that I would become equally as familiar with it. And so I chose WordPress to be the CMS as I began to redo brettro.com.

So there it is. My reasons for choosing and using the web-based content management systems I do.

What CMS’s do you use? And why?

Submitting to Subversion

This is the first in a four-part series about how Brettro integrated Subversion into its workflow. Part two will discuss the products Brettro uses to manage its SVN repositories, part three will discuss how Brettro uses SVN with ExpressionEngine and part four will talk about how Brettro uses SVN with WordPress.

About a year ago I tackled the task of integrating version control into my coding practices. I had spent a frustrating amount of time either recreating my code base as I started on new projects or backtracking and rewriting code when I would get a flash of inspiration to try something new. Also, I have both an iMac and a MacBook Pro and I use them interchangeably and wanted to be able to have the most up-to-date code on both of machine. Plus, it seemed all the pros were doing it—and since I consider myself one—I should join the gang.

Why Subversion?

Usually I do quite a bit of research, compare features and discover the value of one product over another. In choosing SVN, however, all I knew was that the WordPress Core Team used it. That, in and of itself, was a strong enough testimonial for me to dive right in.

Getting Started

When I know nothing about a topic, I buy a book, which is the first thing I did. I picked up Apress’s Practical Subversion, second edition, plopped down and started reading. I read chapters one, two and six completely as they provided an overview of version control in general, a “crash course” in Subversion and best practices in using Subversion. (By the way, Subversion is also known as SVN.)

Although clearly and plainly written, I was still confused as to the best way to get started and the best way to integrate SVN into my current workflow. I asked folks how they used it. I tweeted about my confusion consistently. I read blog entries and articles ad nauseum. I definitely hadn’t had my “ah ha!” moment yet.

Integrating SVN into My Workflow

As it turns out and after some starts, stops and stumbles, I realized that my current workflow wasn’t so much a “workflow” as much as it was a “jumble-of-tasks-that-stumbled-over-themselves” to get a project done. So I began to map out two workflows: one for managing Brettro web properties and one for creating and managing client web properties. This was really helpful as it:

Clarified the basic SVN concepts of trunks, tags and branches, and
Formalized how I create, produce and maintain website code.

Creating a Foundation: My HTML ‘Codebase’

With a better understanding of the basic SVN terminology and process, I decided to start with a fresh series of HTML, CSS and JavaScript files that would serve as the basis of all my website code from hereon out; and I’d call it my “codebase.” This seemed to be a great time to:

Make the switch from HTML 4/XHTML 1.1 to HTML5,
Adopt HTML5Boilerplate, a well-maintained framework established to ensure HTML5 code worked fairly well on legacy browsers (like any version of Internet Explorer before IE9),
Adopt 960.gs, another well-maintained framework established to ensure CSS consistency across browsers, and
Create the Brettro website design style manual.

With my basic HTML5 codebase complete, it was time to venture into the world of SVN. My goals at this point:

Be able to modify my HTML5 codebase as necessary for both my purposes and as both HTML5Boilerplate and 960.gs released improvements,
Create a branch of this codebase for my ExpressionEngine development,
Create a branch of this codebase for my WordPress development.

Repositories, Trunks, Branches, Tags and Working Copies

Let’s get some basic terminology out of the way:

Repository: the “repository” (or “repo”) is the container where your SVN-managed code is kept;
Trunk: the “trunk” is the main codebase of a project where most of your development will occur;
Branch: a “branch” is an offshoot of the trunk (do you see the tree metaphor?) whereby you might want to try out an idea or a feature that may not actually make it into production;
Tag: a “tag” is a copy of either the trunk or a branch frozen at a specific point in time, such as a release (the tree metaphor comes to a screeching halt here); a tag is never modified once it’s created;
Working Copy: the “working copy” is either the trunk or a branch copied to your computer from the repo to allow you to make changes.

After all this reading, contemplating, starting, stopping, deleting and creating, I settled on a basic structure that works for me. I’d like to think it’s a pretty common structure because it is based on my understanding of how WordPress organizes their SVN repository (and I like to use best practices because there’s no need to reinvent the wheel):

Trunk

This is where I do my “next major version” development. For example, right after I finished my HTML5 codebase, HTML5Boilerplate released version 2 of their product. Rather than integrate those changes into version 1 of my codebase, I’ll integrate them into version 2 and do that development here.

Branches

When I imported my initial HTML5 codebase into my first SVN repo, I immediately created a branch and named it “1.0.” The “1.0” branch is my working copy of my HTML5 codebase code where I squash bugs and make minor fixes, then release them as dot releases. These releases are merged back down to the trunk so that they are included in the next major version codebase release.

Committing to SVN (See what I did there?)

By finally having an understanding of basic SVN techniques, by documenting my SVN structure and practices and by creating my first version controlled codebase, I was ready to take a deeper dive. Next I created branches of my codebase for both my WordPress codebase and my ExpressionEngine codebase. Stay tuned to the next three parts to learn what software I use and what workflow I use to manage sites built with either of these content management systems.

Strategory

About nine months ago, I wrote about a strategic shift in the foundational elements Brettro will use to design websites for its customers. The rumblings about HTML5 were becoming louder, I had just finished deploying my first full-scale, medium size website using ExpressionEngine and I had deployed a handful of mediocre (on the coding side) WordPress sites. (They have since become less mediocre.) The benefit of using products with a solid, committed design, developer and fan base behind them, like ExpressionEngine and WordPress, really began to gel with me.

Platforms and Coding

My skill is in coding, my passion is in creating meaningful, usable user experiences and content, my “superhero strength” is managing projects and my “weakest link” is my design chops. Recognizing this, I decided it was time to step up my game and create a plan combining my skill, passion, “superhero strength” and “weakest link” into a functioning business strategy and workflow.

Step one:

professionalize my internal processes,
document coding standards for Brettro,
develop a sustainable platform for client documentation, and
really sink my teeth into merging my “mad coding skills” with the best practices for developing websites using both WordPress and ExpressionEngine.

In that time, and largely through Twitter, I have found an incredible and helpful community surrounding both EE and WP. I started more professional code management using Subversion (and an amazing Mac client called Versions). I have launched my HTML5 codebase. I have created nearly 13 WordPress plugins (and, in many cases, had to completely scrap and re-create them as I learned more and more about WP coding best practices).

In short, I’m well on my way to achieving my goals of becoming more familiar with and better at coding for two brilliantly executed, powerhouse web publishing platforms.

But there’s more to do…

Design, Design, Design

If anything has suffered through all this, it is the design of the Brettro web properties. They are certainly not horrible—and definitely don’t rank amongst the legacy 1996-era sites with all the visual appeal of an avocado green refrigerator—but they are my weakest link.

With comfortable knowledge of HTML5, Subversion and WordPress under my belt, it is time to focus on Step Two: creating a visually rich, responsive, usable, compelling interface for our websites. (The Brettro web properties use WordPress, but that’s a different discussion for a different time. Coming soon, though.)

I’m excited by this next step. Design has always been the biggest struggle for me. I understand the basic concepts, but the crippling self-doubt (which apparently plagues most of the design types I follow on Twitter) about the elegance and visual appeal of the concepts I develop keep me from executing my best work. It’s in there. I know it is. I just need to take a deep breath, walk away from time-to-time, and push through the doubt.

Soon enough you’ll see those efforts come to light. And your feedback will be important.

But there’s still more to do…

Content, Education, Engagement

This is the point where I become so overwhelmed by the sheer volume of things I need to do, learn and participate in. But then I recognize how excited I am by all of it! And really, this batch of “more to do”—also known as Step 3–is really best done by intertwining it throughout the other efforts on a day to day basis:

Education in this arena never stops. And that’s one thing I absolutely love about it.
Strategically writing content for the web is such a compelling activity, especially with advocates (and professional heroes of mine) like Kristina Halvorson and Erin Kissane making such strong showings for its benefits
And Washington, DC has some absolutely brilliant programmers and designers with which to engage. I look forward to becoming an active and beneficial part of the community.

So, guess what? It’s time to get busy. Come back to read about and see the progress as it unfolds. It’s going to be exciting!