Raised Eyebrow Blog

We are very proud to unveil a project we’ve been working on for several months now: a redesign of policyalternatives.ca, the online home of the Canadian Centre for Policy Alternatives. Canada’s leading progressive research institute, the CCPA is a prolific publisher of reports and studies, books, articles, commentary and fact sheets on issues ranging from income equality to environmental policy, privatization of public services, and beyond.

They are highly respected, but like many organizations working towards policy change, they don’t always reach as broad an audience as they might hope; not many people have the time and inclination to read an in-depth research report, so in recent years they have been creating more bite-sized, easy-to-digest content in both written and multimedia formats. As the range of content has grown, though, so has the need to cross-reference related materials — so the CCPA’s website needed to both invite visitors to browse through an extensive library in an intuitive and approachable way, but also allow people seeking more in-depth content to locate related materials quickly and easily. (One of our developers describes the complex interrelationships between the CCPA’s publications as “like Facebook for documents.”)

Their five year-old website, although rich in content and highly trafficked, didn’t offer visitors any way to easily share the CCPA’s content with their social networks, whether through Facebook or Twitter, or even through their own publications, blogs or presentations. Exchange of ideas is the CCPA’s raison d’etre, so it stands to reason that above and beyond extending the website’s “share this” features, the organization would benefit from encouraging online visitors to use and share its content — and they do, using a Creative Commons license.

This project was a complex one on several fronts, as we wrestled with improving navigation through the site (both via menus and site links as well as with improved search tools); updating the site’s look and feel; and migrating the extensive site content (along with the aforementioned relationships between content items) from a commercial CMS platform into Drupal.

Oh, and we also set up a shopping cart (for books, memberships, donations and journal subscriptions).

There’s a real sense of accomplishment here at Raised Eyebrow when we look at the final result, but of course on the web, there’s no such thing as a final edit. Our best hope, in fact, is that we’ve helped to create a solid platform upon which the CCPA can continue to build and extend over the coming years. So while right now we are celebrating the grand opening, the real fun in some ways is still to come. I’m sure we’ll see the CCPA continue to play a leadership role when it comes to presenting research online in accessible and innovative ways.

Here at Raised Eyebrow, while we have experimented with dozens of Content Management Systems (CMS’s), these days we mostly build websites using either Drupal or WordPress.

Why these two CMS’s, of the thousands of content management systems available? Both CMS’s share several key qualities:

• They’re open-source projects. Over the past few years, Raised Eyebrow has increasingly turned to open-source software options because of the flexibility and security they offer.
• Both WordPress and Drupal boast huge communities of developers and widespread adoption; those are important things to look at when working with open-source software, because we like to see a critical mass of people who are invested in making the software better, both on the coding side and from the end-user perspective.
• They offer a rich and robust feature set, both within the core CMS and in terms of the plugins (or in Drupal parlance, modules) that are available — plugins and modules help us extend the base functionality of your site with features such as photo galleries, event calendars, interactive forms, shopping carts, and so on.
• Perhaps the most compelling reason we’ve chosen these two, though, is that our clients like using them. The interfaces are user-friendly; the software is reliable; and the basic functions that our clients need (from uploading a file attachment to creating new pages and blog posts) are available, easy to use, and intuitive. (I won’t claim that there aren’t things I wouldn’t change if I could wave a magic wand — but of the CMS’s we’ve tested, these two are far and away at the top of the heap.)

So how do you choose which one is appropriate for your project? Drupal & WordPress are very different systems, with different strengths and weaknesses. Here’s a quick overview of some of the distinguishing features of each CMS.

Drupal

Drupal welcome screen

Community focus: Drupal has extensive functionality for allowing people to interact with one another via your website. Creating accounts; logging in to access special content — or create their own; connecting with one another — all of these are possible with a Drupal site, so if your short- or long-range plans include turning your website into a social hub for your visitors, Drupal is a better choice.

Editing a page in Drupal

Editing is seamless: In Drupal, if you have administrative privileges, and you are logged in, you can edit your content simply by navigating to the page you want to update, and clicking an unobtrusive “Edit” tab. Many people find this a particularly intuitive approach to site editing. (Not only that, but Drupal is so profoundly customizable that if you want to, you can create custom themes for different areas of your site — so your back-end could look totally different from your front-end, should you feel so inspired.)

Specialized content types in Drupal

Built for dynamic content: Drupal has some very clever ways of cross-categorizing content, so if you have the kind of website where you want content to appear in multiple places based on various categories you assign to it, Drupal may be just right for you. And it’s often the better choice for managing complex kinds of content, where a simple 2-field “Title” and “Body” editing screen won’t suffice.

Highly modular & extensible: The underlying architecture of Drupal is quite flexible, and the CMS can be adapted for a wide variety of purposes. Drupal is like a Swiss Army knife or a food processor: it is many tools in one, and you can choose to use it for one task or several. WordPress is much more specific in its function: it does a handful of things and does them very well, but it isn’t the right tool for every job. (On the other hand, if you need a simple site, Drupal may be overkill, and you could spend a lot of time turning off the features you don’t want.)

Greater investment required up front: Drupal’s out-of-the-box configuration is somewhat limiting, and most people prefer to customize it pretty heavily. This requires not only a solid understanding of HTML and CSS, but also of PHP and of Drupal’s underlying architecture, which has a fairly steep learning curve. As a result, Drupal sites tend to cost more to set up, though the initial investment is well worth it if you plan to extend your site’s functionality to take advantage of Drupal’s flexibility.

WordPress

WordPress's editing screen looks quite different from your site's front-end. This is the screen I see while editing the blog post you're reading.

Built for blogging: I personally find Drupal’s blogging capabilities somewhat limited — for example, creating blog category lists, tag clouds and date-based archives is rather onerous in Drupal, whereas in WordPress they take a matter of minutes to set up. WordPress was first developed as blogging software, and it shows: its blogging features are well thought-through and have been polished by years of improvements.

WordPress's Media Library gives you easy access to all the files you've uploaded to your site: images, PDFs, media files, etc.

Easy-to-use file management: WordPress’s “Media Library” feature allows you to browse through all the files you’ve uploaded to your site — images, PDFs, multimedia files, whatever they might be — in a clean, attractive & easy-to-use interface. It makes managing your files and inserting them into your blog posts and site pages a much easier task.

Smart spam filtering: Because of WordPress’s blogging focus, the developers had to pay close attention to managing spam. (Blogs attract a lot of spam via comments and pingbacks.) WordPress comes bundled with spam-filtering software that does a remarkably good job — and moreover, its comment-management features are well thought-out and simple to use.

The WordPress Dashboard gives you an overview of activity on your blog or website.

Quick to install and configure: WordPress is famous for its 5-minute install, and it really does live up to its name. Although that doesn’t mean you’ll have a fully-functioning website in 5 minutes, it works well “out of the box” for most simple sites & blogs. As a result it is often less costly then Drupal to set up.

Easy to theme: Both Drupal and WordPress have a great deal of flexibility with regard to visual design — you can make a site built in either CMS look beautiful via either free templates or by applying your own custom design. However, theming a Drupal site is a much bigger task than theming a WordPress site, unless you are simply going to download a free theme and slap it on your site. If you want to be able to tweak design details, in our experience, that’s a much faster job in WordPress.

If you aren’t planning to use WordPress’s blogging features, navigating through the CMS can be a little confusing, because blog posts are the primary focus in the menus, and page editing is less prominent. In this sense, its focus on blogging can be a weakness as well as a strength.

WordPress keeps your site’s back-end (that’s the area where you create & edit content) totally separate from the front-end (the part your visitors see). Some people (like yours truly) prefer this approach, where content is more or less divorced from presentation, whereas others prefer Drupal’s integrated editing options. In my experience, this is a highly subjective preference, and it’s worth trying both to see which feels better to you.

In Summary

As with most decisions about your website, you are well advised to consider the long-range goals of your site before selecting the CMS you’re going to use. If you foresee a highly dynamic website with complex content types, and/or community features such as member login areas, multiple blogs, or user-created content, Drupal may be better suited to the job. On the other hand, if your content management needs are relatively straightforward, or if you intend to have a blog-centered website, WordPress could be just right for you.

Still have questions? Please feel free to leave them in the comments & we’ll do our best to answer them.

Discovered a very upsetting scenario today while building out a Drupal 6 site. If you have the Update module enabled and drupal.org goes down your module admin page at www.example.com/admin/build/modules stops responding. Why? I think it’s because somewhere in the Update module is a call to updates.drupal.org.

The quick and dirty solution is to temporarily disable the module via the system table in your database.

How do I do that?

• Using phpMyAdmin or some other GUI tool or via the command link
1. View the system table contents
2. Find the row where filename is modules/update/update.module
3. Edit the row and set it’s status field to 0
4. Refresh your modules page
• Via SQL Query/command line

  UPDATE `system` SET `status` = 0 WHERE `filename` = 'modules/update/update.module'

I’m going to submit an issue about this and look into a possible solution. I was halted in my work for over an hour today because of this.
Disclaimer: I am not responsible for those of you who do not backup before making any changes to your database.

So we (Christopher and I) are at DrupalCon, and one of the questions to the floor at The Themer’s Toolkit was “What theme toolkit do you use?”. I thought I’d give a quick overview of our toolkit:

Theme

We’ve been using a custom three column layout that Christopher developed way back when, but recently we’ve been tweaking it considerably, to include new features such as video support, stylesheet switching, custom search form and IE support. It’s now similar to Zen in many ways and provides context/content specific classes and ids for ease of styling. We have plans for the future to create a more flexible theme based on CSS frameworks.

Install Profile

We have our own custom install profile that configures things like TinyMCE and CCK settings as well as setting up an admin user etc.

Coding tools

We are primarily a Mac/Adobe shop, so we have been using Dreamweaver up to now, however we sometimes use TextMate for new projects or projects that don’t require a check-in/check-out capability. With the prospect of version control tools coming in the future we will be reviewing and reassessing. I know there are some hardcode VIM and Emacs users out there, we promise we’ll consider both :)

Version Control

Historically we have been a single developer shop with no need for a version control system as most sites were developed and then rolled out without need to many updates. However with the addition of more custom modules, working on much larger sites and the expansion of our team we now feel it necessary to implement some sort of version control system. Having seen some of these in action at DrupalCon, we will be working to have something running in a few months.

Modules

We use the standard modules such as CCK, Views etc. but also have the following custom modules:

Mobile Detection Module

I’ve recently finished a rough beta version of a mobile redirection module which uses this code to detect the user agent and then redirects to a specified URL. In most case we use a sub-domain folder like /sites/m.example.com and configure the settings.php to use a separate theme. We’ll release this at some point also when it meets drupal’s code and module development standards, not that it doesn’t already but we need to make it less site specific.

Block Class extension

I wrote an extension to the block class module that allows the user to choose from a specified list of block class options, rather than typing one in.

Node title length

In some cases, to stop the design from breaking, we need to ensure that the node title lengths are restricted to a certain maximum. This module allows you to choose the content types to apply the restriction to and does the necessary validation.

CSS Image Replacement

Chris wrote a totally awesome tool that we then roughly ported to a module that uses CSS to do image replacement. For now that’s all I can say, we’ll be working on releasing it in the wild at some point but it rocks and relies on GD libraries and CSS definitions to create images to replace text.

Advanced Menus

Chris built this module to allow us to place any of the available drupal menus in a block and position this anywhere on the site.

We’re constantly working to improve on our workflow, and having recently become a 2 person development team, soon to be 3, we are conscious that improvements need to be made in preparation for future growth. If you have any tips of suggestions for a team the size of ours I’d love to hear them.

We’ve come across an issue quite a few times during the development/build of a site where a client wants to include some content above or below a view and wants to have the ability to edit that content. There are a number of ways to achieve this functionality:

1. You could simply use the “Header” field in the create/edit view screen and place some text in there. However, that does not have a nice WYSIWYG editor, one could be assigned but it’s not ideal.
2. You could create a block and place it in a region above the view. Again, unless you have a WYSIWYG Editor set up for blocks, this is not perfect.
3. You could, in some way, add a view to the bottom of a page – ah!, that’s it.

The caveat with 1 and 2 above is that it requires giving the site editor/client access to views and blocks, in a lot of cases this is way too much control and will usually result in problems. 3 is the ideal solution. Once I figured this out, I began to develop the functionality: I created a Select CCK select field for all page content types which pulled a list of all available views by using the views_get_all_views() function. This field stored the name of the view, I then used the name of this view in page.tpl.php to load the view via the function views_get_view(). It started to get a little messy, so I decided to start building a module, only to find that one already existed.

It’s called Viewfield and does exactly what it says on the tin. It allows you to add a CCK field which is a list of views to choose from. The view will then display on a page in whatever position and format you choose. It works great.

You can see it in action on this page from the BCNDP website.

Content management systems (CMS) allow you to create content on the fly without having to worry about coding in HTML or uploading via FTP. Most content management systems then use a combination of PHP or ASP querystrings to deliver that content in a format something like http://www.yourdomain.tld?pid=36 or http://www.yourdomain.tld?q=node/15.

The reason for this is mostly to do with the database driven nature of a CMS, and it’s ability to retrieve all content/data related to a specific id. So what’s wrong with that? Most search engines don’t index pages whose URL contains a question mark or other character (like an ampersand ‘&’ or equals sign ‘=’).

What does this mean? It means that people can’t find your site. There are times however when you will want to create a nice clean URL for use in a marketing campaign or as a link on Facebook, or some other link sharing website. There are a number of ways to achieve this using Drupal and I’ll examine each of them in turn. Today we’re going to hand curate (Emiras favourite term) them.

Hand Curated

The quickest and easiest way to create a nice URL is to do it when you’re creating new content. Scroll down to the “URL Path Settings” area and simply enter your path. Remember to leave out the trailing slash at the end, otherwise it won’t work, it’ll be banjaxed.

While this path can be anything you want, try to keep to the following rules:

1. Keep it short - no one will remember a really long URL.
2. Keep it simple - we’re not trying to win the Man Booker Prize here.
3. Keep it relevant – the URL should relate to the title of the page/article and it’s content – search engines take relevancy into account too when indexing your pages.
4. Keep it organized – if you have a few different types of content on your site, try to organize your content via the URL. For example all Articles would go under “articles/your-title-here” and all Publications would go under “publications/your-title-here“. Also note that I use the hyphen “-” to separate the words in the title. You can use the underscore also “_”, but I prefer the hyphen as it’s easier to read aloud and people refer to it as “dash” also. You’d be surprised how many people I speak to don’t know what “underscore” or “underbar” means.

In Part 2 I’ll examine using the Path Auto module to automate this for you and then for Part 3 I’ll go on to talk about using Views and Arguments and how they can be used to create what are called “Hackable URL’s“.