A few months ago, I made a post about choosing a CMS. At that time, we were utilizing several different content management systems depending on project complexity and client preference. Since then, however, we have switched exclusively to Drupal as our CMS of choice, and in this post I will explain why.

A Real World Example

We are currently working on a website redevelopment project for the American Society of Media Photographers (new site will launch in early summer ‘09). In addition to requiring a full range of content management features, the project had three requirements that were a bit outside the normal range of a CMS project:

1. Authentication against an existing, proprietary user database
2. Integration of existing PHP code into Drupal, preventing the need to re-code entire site features that already worked as standalone components
3. The ability for chapters around the country to manage their own sub-sites on the main ASMP site

Obviously, we did our homework before settling on a CMS platform. The first thing to realize about Drupal is that it offers a truly granular level of control over the entire system. Here at Context, we’re generally fans of fully object-oriented MVC architecture. Every custom PHP project we do is built on top of Fuse, and we lean heavily toward Magento as our E-Commerce platform of choice. Drupal, however, is not MVC driven, nor is it generally object-oriented. However, the hooks system is extremely well documented and well integrated, and it allowed us to hook directly into the authentication functions to make short work of item #1 above.

Next, a mix of the PHP evaluator module and the PHP path module allowed us to simply ‘include’ existing PHP files at URLs of our choosing, and surround them in the Drupal page layout. We removed & replaced the page styling on the legacy pages with the updated CSS (and also removed the header and footer), and found that we had the legacy code transparently working within the Drupal structure.

Finally, #3 – chapter sub-sites. Initially I had thought we would need to develop a custom module or make heavy use of Taxonomy to tackle this one, but the Domain Access module provided a much more comprehensive solution. Built specifically for the management of sub-sites, we were able to integrate it into our Drupal install and get moving right away on managing sub-sites.

Why NOT Drupal?

So, we all know that Drupal is extremely powerful, but what keeps developers consistently choosing other open source content management systems? Previously, I felt that due to Drupal’s complexity and learning curve, it should be reserved for larger scale projects that really require its power. Otherwise, I thought, maybe it would be best to just put together something in WordPress, Joomla, or ExpressionEngine. However, Drupal’s bark is bigger than its bite when it comes to the actual learning curve, even for the more powerful and complex fatures. Drupal is certainly set up a bit differently than other content management systems, since it lacks the user friendly admin dashboard we’ve come to expect from Joomla, WordPress, or EE. Additionally, the Drupal default install is quite unimpressive. You have very little functionality until you start installing modules, and some of the terminology and information architecture can be a bit confusing at first. But just hang in there. Everything starts to make a lot of sense once you start delving into the system, and from there you will be “hooked”. Having a good book doesn’t hurt either – we liked Pro Drupal Development and Learning Drupal 6 Module Development .

So, at least for a while, it’s Drupal for us as our CMS of choice for any size project. I’m interested in seeing what Joomla does with version 1.6 (granular user permissions, finally), but I have to admit that I’m considerably more excited about Drupal 7.

I’ve found that the best way to keep on top of the available tools for web development is simply to maintain communication with other developers, finding out which products they like, which products they don’t like, and why they choose one option over another. So – what’s in your toolbox? Post some comments & let us know. Below is a list of a few of the tools we use over at Context to make our lives easier and make our clients happier:

Drupal (Content Management)

There are several content management systems we’ve worked with and have had good experiences with, but as we move forward, Drupal seems to be the winner in terms of features, scalability, and support. I suspect we’ll be using Drupal as the CMS for all projects in the foreseeable future, and I strongly recommend looking into it if you haven’t already. One thing I will say about Drupal is that its power isn’t at all apparent from the default install, so make sure you browse the documentation a bit in order to gain an understanding of just how much Drupal can do.

Magento (E-Commerce)

When it comes to E-Commerce, Magento takes the cake in terms of architecture, scalability, and customizability. Its architecture might be a little bit intimidating to some developers (it’s built on MVC and EAV), but its potential is just limitless. Most of the complaints I’ve heard about Magento seem to stem from a lack of understanding of MVC development, or a poor configuration of mySQL that leads to performance problems. Magento does still need some performance enhancements, but those enhancements are being addressed in an upcoming release slated for this month, and even now the speed is quite acceptable if you have mySQL tuned properly. I’m very interested in hearing alternatives to Magento, because I haven’t come across anything yet that, in my mind, is a legitimate competitor.

Fuse (PHP Development Framework)

Our own homegrown MVC framework, Fuse is definitely our weapon of choice for any custom PHP development. We’ve even successfully integrated it with Magento and Wordpress (e.g. the blog you are reading right now). Built to give us the flexibility of Rails but the freedom of using PHP, Fuse has grown into a very powerful competitor in the PHP/MVC world.

jQuery (Javascript framework)

If you’re not using a javascript framework, please start today. Even if you go with Prototype over jQuery, you’re doing yourself a disservice by not leveraging one of these phenomenal tools. It’s almost hard to quantify how much hassle we *don’t* have to go through to add historically tedious functionality like drag & drop, ajax forms, and dhtml popups. jQuery can turn an hour or more of tedious coding into a 30 second task – maybe a minute and a half if you first need to Google for the function name & available options.

I think we’re all patiently waiting for a standard way to embed any font into a web page via CSS, but adoption of the CSS3 standard for embedding fonts has not only seen slow progress, it has been met with opposition due to potential copyright issues. You can read more about the woes of standard cross-browser font embedding here.

However, you won’t have to wait until the CSS3 issues are worked out to be able to embed clean, anti-aliased, non-web fonts in your page without resorting to embedding text in images. The answer is here, and it’s called sIFR, the scalable Inman Flash Replacement.

Some people have called sIFR a hack, I just call it clever. And it’s no secret on the web – it’s been around in some form for quite a while now – but it seems that a lot of people I meet in the web design or website development business either haven’t heard of it or haven’t actually tried it.

sIFR works through a mix of CSS, javascript, and Flash. It performs surgical replacement of page text with dynamically generated flash movies, and those movies contain the replaced page text in the correct, non-standard font. Now, that may sound a bit overly complex and kludgey, but sIFR is packaged in a clean, easy, robust manner that works across browsers and allows a very fine level of control over the text replacements.

Let’s take a look at an example:

THIS IS MYRIAD PRO (which is not a standard web font)

The heading above uses a standard <h2> tag that is transparently replaced by sIFR with the flash movie containing the Myriad Pro font. One of the best things about sIFR is that if the user agent doesn’t support flash, it degrades gracefully into the default font for an h2 tag, so the user still sees the text. You may also noticed that you can highlight and copy the text as if it were a normal <h2> tag.

There is a lot of documentation on sIFR at the sIFR site (make sure to use sIFR3 for the best results), which should allow you to get things up and running quickly.

sIFR opens up a new world of web design freedom when it comes to choosing fonts. While I wouldn’t recommend replacing every bit of text on the page using sIFR, it works exceptionally well for headings and subheadings. We implemented sIFR quite a bit on the Native Eyewear website, and were very pleased with the results.

There are alternatives to sIFR such as Typeface.js, but so far sIFR seems to be the most reliable candidate for providing freedom of font choices in your website design. Your designers will be happy knowing that sIFR is in your toolbox, trust me!

Update (again): I had initially uploaded a jQuery based fix to get this selector working in IE6, but Emil Bjorklund pointed out that Dean Edwards’ IE7.js also fixes the issue, so I would recommend using that script to get the selector to work in IE6.

Recently, we’ve been making substantial use of a CSS selector that I stumbled on almost accidentally in the w3c docs: the “~=” selector, which can more compatibly be written simply by separating class names with a dot (and no spaces) . It’s certainly no secret, but I haven’t seen it in use much, and that’s a shame because it lends itself to some really clever and intuitive CSS. Here’s the definition for the selector:

Matches any E element whose “foo” attribute value is a list of space-separated values, one of which is exactly equal to “warning”.

It doesn’t sound too interesting, but what we’ve found is that it lets us use very intuitive, almost straight English syntax for our css classes by daisy chaining class names in a logical order.

Consider the situation where your template has a main content area, sometimes with a sidebar, sometimes without. There are plenty of ways to handle this fairly simple problem in CSS, but I’m finding the most elegant solution to be the following:

.main_column {
    min-height: 300px;
}

div.main_column.with_sidebar {
    float:left;
    width: 690px;

}

Now, when our main column needs a sidebar, we can do:

<div class="main_column with_sidebar">

<!-- Content here will be floated left -->

</div>

Why is this better than just defining “.with_sidebar”? Because it may be the case that two different classes (maybe “main_column” and “page_content”) both support a “with_sidebar” version that applies different width & floats depending on which class it’s being applied to. (”main_column .with_sidebar” won’t work because “with_sidebar” is not a descendant class of main_column.)

Taking it a step further, let’s add a green background:

div.main_column.and_green_background {

background-color: green;

}

now, how about:

<div class="main_column with_sidebar and_green_background">

<!-- Content here will be floated left with a green background -->

</div>

Again, there’s nothing here that can’t be solved in other ways, but I just wanted to introduce other people to this oft overlooked selector which, in my opinion, allows for very clever, elegant CSS.

It was once the case that a staple of any web developer’s job was to provide ongoing content updates for their clients. However, in a “web 2.0″ world of ever expanding, dynamic content, this model has become obsolete and often unsustainable. Developers’ time is best spent developing, not performing data entry and copy editing tasks.

Enter the content management system, or CMS. The increasing popularity of scripting languages such as PHP, ASP, and ColdFusion made it easy for even novice developers to deliver database-driven sites, and we saw the birth of an infinite number of custom content editing solutions, from simple and quick to robust and involved. Custom CMS development is still a very common (and sometimes appropriate) approach to dynamic content, but several excellent solutions have emerged that can prevent you from having to re-invent the wheel every time you need to deliver a CMS solution to a client. I will discuss 4 popular CMS products in this post, all of which are either free or very reasonably priced. There are, of course, a number of expensive commercial solutions that target niche enterprise markets, but I’m going to use this post to discuss systems that can be implemented on a budget while still providing the features and functionality to build a robust site. Hopefully this article will help you in choosing a content management system that will best suit your project.

Expression Engine

http://www.expressionengine.com

Cost: $249.95
Pros: inuitive back-end interface for easy content editing
Cons: templating system is a bit more development intensive than some others

When I talk about ExpressionEngine, I always first disclaim that I am not affiliated with its development or parent company, Ellislab, in any way. The reason for this disclaimer is that my description of EE can sometimes sound like a sales pitch – I just happen to personally like it and find it to be quite intuitive. With that being said, let’s continue:

ExpressionEngine has become my CMS of choice for sites that have a newspaper or magazine feel. It seems to lend itself to these sorts of projects extremely well, especially since the back-end interface is extremely intuitive and is therefore easy to teach to a diverse staff of writers, editors, or other content-creating personnel. It, of course, has the staples of a good CMS – pages (called weblogs), categories, user management, and customizable templates. From a development standpoint, the templates are configured very much like views in a model-view-controller architecture, where you have separate templates for each page that contain specialized markup tags. These markup tags are used to pull content from the database, and your surrounding HTML and CSS provide the look and feel. Personally, I like this approach, but it can be a little bit more development-intensive than some of its counterparts (e.g. Drupal, where everything is organized into blocks). The documentation and support for EE is also excellent, so the learning curve for their custom template system is very easily overcome.

One EE feature that I absolutely love is the ability to assign custom fields on a per-content type  basis, which means that the editor for a media entry can look very different from the editor for a news item, since they will very likely have different fields. Again, this gives a very intuitive feel to the administrative interface, which is a necessity if multiple people of varying computer skill will be editing content.

Overall, I would recommend EE for use in content-managed sites of a low to medium complexity and, as mentioned above, it works especially well for magazine or news sites.

WordPress

http://www.wordpress.com

Cost: Free
Pros: Free, easy install
Cons: Typically functions more as a blogging tool than a CMS

Let’s face it, WordPress is a staple of the blogging community at this point. It’s free, it’s simple to install and use, and it’s customizable. In fact, it’s so customizable that it has long since blurred the line between blogging tool and full-blown content management system.

The blog you’re reading right now is a Wordpress blog, and you can see that I’ve fully integrated  it with the Fuse PHP MVC Framework that drives the rest of our site. WordPress uses straight PHP as its templating engine, so it’s easy to start customizing right away, even with only an intermediate knowledge of PHP. Personally, I’m more a fan of tag-based templating engines like the one in EE, but can definitely appreciate arguments for the more direct approach of using the scripting language itself (e.g. PHP) as the templating engine.

WordPress has a slick and easy interface, though the custom field options do leave a lot to be desired when compared to ExpressionEngine’s implementation. However, it’s not unlikely that a plugin or extension can take care of that issue, either now or sometime in the future. All of the CMS products discussed in this entry have a modular, scalable architecture, and especially in the case of WP, Drupal, and Joomla, there is a seemingly never ending supply of add-ons that can help adapt the solution to your specific needs.

As a blogging tool, WordPress is top notch. Personally, I would probably pass it over in favor of one of the other solutions discussed here when looking for a fully functional CMS platform, but many complex Wordpress-based sites have emerged, proving that WordPress is extensible enough to hold its own as a CMS solution.

Drupal

http://www.drupal.org

Cost: Free
Pros: Extremely versatile and extensible
Cons: A little trickier to configure than other systems discussed

Out of the box, the default Drupal install doesn’t look too impressive. However, in this case, looks are very deceiving. The extensibility of Drupal is seemingly limitless, and the API is well documented. This combination ensures that you can customize the system to suit your specific needs. The beauty part? It’s likely that you won’t even have to build your own extensions, because so many free modules are widely available and easy to install.

It’s important to note that everything in Drupal is done via a module, even functionality that you might expect to be part of the base install. This is why, as I mentioned above, the default install appears to be a bit lackluster. However, modules are extremely easy to find and install, and many of them are included (although disabled) by default. I recommend starting with at least these modules: Blog, PHP Filter (allows you to write PHP in your blocks), and Taxonomy (categoriztion of content).

For CMS-driven sites that will require an increasingly complex integration, Drupal is the way to go. Its extensibility and huge development community make it the winner when dealing with projects that fall outside the standard boundaries of a normal content-managed site. As an example, we had a client approach us about an Intranet CMS for their company, but they also stipulated that the solution needed to authenticate against their existing Windows Active Directory. Additionally, they had other, separate web-based applications already in place and wanted those applications and the CMS to use a single sign on system. The solution we came up with was an implementation of Drupal and CAS. While the other CMS solutions discussed here support LDAP (Active Directory) authentication, Drupal is the only one with an existing CAS module.

Joomla!

http://www.joomla.org

Cost: Free
Pros: well supported, extensible, clean interface
Cons: lacks granular user permissions

I have to admit that Joomla is the system discussed in this post that I personally have the least amount of experience with. Although I tested it as a candidate for one of our projects, it ended up losing to Drupal because of its lack of granular user permissions. Like Drupal, Joomla is open source, well documented, and has a vast array of available extensions. Joomla’s templating system is block-based and configurable through XML and PHP, not unlike the E-Commerce solution Magento, which I will be discussing in another post. This style of template building is very extensible, but will be a bit of a learning experience for most designers.

The Joomla administrative section is very slick, and I personally prefer its terminology over even ExpressionEngine’s – Joomla refers to “sections” and “pages” rather than “weblogs” and “templates”. Dropdown menus and intuitive navigation icons provide a very pleasant user experience, and the feel overall is very non-threatening, but still very robust.

As I mentioned above, I was forced to use Drupal over Joomla on one project because Joomla’s user permissions aren’t granular – there are preset groups that all users have to be fit into. Now, most of the time, this will not be a problem, especially if only a small handful of people will be editing content. However, in a large organization, finely grained control over user permissions is essential. I understand that Joomla 1.6 has made granular permissions a priority, and a stable 1.6 is very much on the horizon.

Conclusion

Hopefully I’ve given a concise but useful overview of some of the more popular CMS products on the market. My mantra is always that you should use the best tool for your specific job, and each of these systems deserves consideration depending on the needs of the CMS project. I didn’t get into detail on specific features because you can get complete feature comparisons at the fantastic site CMS Matrix.

Please feel free to comment with any questions. Thanks!