Overview

Colorado State University Libraries implemented the Drupal Content Management System for its redesigned website in summer 2010. Here is my assessment as of 2010. Also see the Drupal LibGuide.

End User Features

Visual Design

• Priority: High
• Quality: High

The CTI_Flex Drupal theme met our requirements and works reasonably well for us. It came with suckerfish-based drop-down menus, a place for our site-wide footer, breadcrumbs, and left navigation like the University of Arizona Libraries site. It is relatively easy to customize.

Subsites with unique templates have been left as HTML pages outside of Drupal. We have not investigated creating separate Drupal sites with subdomains or customizing the main template based on request URLs.

User Feedback Tools

• Priority: Medium
• Quality: Medium

Comments can be enabled for any content type by default. They are enabled by default for blogs and exhibits/events, but not pages, web forms, and most other content types.

User profiles do not provide a contact form for non-users. We want people to be able to send us comments without logging in. For contact links at the bottom of pages, we may have to continue using our existing Perl-based comments form for awhile.

A global contact form can route e-mails to different recipients depending on the category/topic, but our contact system will probably be page-based so we can include multiple ways to contact people (phone, e-mail, chat, etc.).

Comments forms include a good captcha system for security, and the sitewide contact form can be configured prevent users from sending too many messages per hour.

Site Index (A to Z List)

• Priority: Medium
• Quality: Low

It was easy to change the built-in glossary view to automatically generate an A to Z list.

We could create a new content type "A to Z entries" and base the view on that, but there would be duplication of content and inconsistencies with the page itself.

To include non-Drupal pages in the A to Z list, we would have to add aliases or redirected pages.

We could add page fields like an "A to Z titles" field to allow for cross-referencing the page (e.g. Catalog, Library Catalog, Sage, Find Books) and/or an "include this page in A to Z list" checkbox field so not all pages are listed.

We will probably continue to maintain a manual HTML A to Z list, which is easy to add multiple entries and globally search and replace.

Site Search

• Priority: Medium
• Quality: Medium

Although Drupal has a nice Solr-based search engine, we will probably need to use a tool that can index files outside of Drupal. Some options:

Discovery, Nutch or other Solr-based tools are free, fast, powerful and unlimited for numbers of files, but do not work like Google and require a lot of development, configuration and maintenance time.

Our Google Mini can index absolutely everything and works like Google, but is slow and limited to 50,000 files.

Google Custom Search Engine is free, can index more files, and requires less configuration and maintenance, but does not index everything.

Site Map

• Priority: Low
• Quality: High

It was relatively easy to use PHP to automatically generate a simple site map based on the primary links, so maintaining a separate page is not needed. Other menus could be added as well, though they are probably not needed.

Breadcrumbs

• Priority: Low
• Quality: Medium

Automated breadcrumbs are generally working. The Menu Breadcrumb module and customization of the page script in the theme were needed.

Staff List

• Priority: Low
• Quality: Medium

A view to list staff Web authors works well and the Profile module is easy to customize, but it would have to be modified to include staff who are not Web authors. We will probably continue to use our custom PHP application.

Blogs

• Priority: Medium
• Quality: Low

We haven't looked at blogs in much detail. They seem easy to use, but not as full-featured as WordPress or Movable Type (e.g. no categories). We should probably use WordPress.

Authoring Features

Page Creation

• Priority: High
• Quality: Medium

It is fairly easy to create a page, but there are a lot of options that authors must understand (menu settings, input format, revisions, image and file attachments, URL path, comments, workflow, authoring, and publishing).

WYSIWYG Editor

• Priority: High
• Quality: Medium

FCKeditor is the most popular, has many controls, and does a reasonable job, but sometimes gets confused. It is sometimes necessary to switch to HTML view or paste code from Dreamweaver.

CKeditor claims to be a rewritten, faster, better version of FCKeditor. It is a more rapidly growing project. It has skins, a few more buttons, different icons, and a Dreamweaver-like HTML tag selector. It is necessary to temporarily deactivate the module to enter PHP code, which we will need in a few places. CKeditor only works in Internet Explorer if optimize CSS files is enabled under Performance, but this must be temporarily disabled whenever the CSS files are changed. For non-IE browsers, our changes are not saved unless we switch to Source view.

We should test some other editors. None is likely to be as full-featured as Dreamweaver, but it should be easier to use and more robust.

Authors are configured to have full WYSIWYG as the default. Filtered and HTML and WYSIWYG are options for everyone, and administrators can use PHP.

Menu Management

• Priority: High
• Quality: Medium

Menus work well and are consistent, but not as flexible as blocks of HTML which we may want to use in some cases.

It was necessary to create separate menus for primary links and left navigation, so the menus must be maintained in two places. It might be possible to use a PHP snippet to generate index pages using the same text and links as a left menu, though .

Any editor can edit any menu, which is not secure from errors, and regular authors cannot edit any menus, which puts more burden on editors.

The Menu Editor module makes menu creation and editing somewhat faster and easier, since multiple menu items can be edited in a single form, and dummy pages are created for menu items if the page doesn't already exist.

Media Management

• Priority: High
• Quality: Medium

We will continue to use Samba for file management. The IMCE module helps for browsing and uploading images and other files. The CKfinder module is similar, works with CKeditor and is visually more appealing, but has fewer features, and displays a message about being a full-featured demo unless you pay for it.

Web Forms

• Priority: Medium
• Quality: High

It is fairly easy to create web forms and get the data, compared with using FormHandler or a custom PHP script. There is no obvious way to send an email copy to the person who completes the form; this is reportedly a feature of Drupal 7, or could be hacked using some PHP.

Content Types

• Priority: Medium
• Quality: High

It is easy to create new content types and views based on them, such as promotions for the home page. This will save considerable programming time.

Authentication

• Priority: Medium
• Quality: High

LDAP Integration allows staff users to use their existing logins. This saves a lot of time and ensures accurate account information and emails. It was easy to get this to work with the CSU LDAP server and the help of an ACNS systems administrator who gave us the appropriate parameters. Triggers and actions are used to notify administrators when a new account is created, and to inform the user that the administrator will soon assign them authoring permissions.

User Roles and Permissions

• Priority: High
• Quality: Medium

Authors and editors can edit any node content, but only editors can edit menus and blocks. The Admin Role module allows for multiple administrators.

There is no built-in way to use roles to restrict creating and editing content based on directories/URL paths (e.g. departmental or top-level pages and menus), though the page template could probably be hacked to hide edit features depending on directory and user role.

To replace our existing staff intranet, it would be easy to modify the page template to restrict read access to staff-only content by IP number.

Workflows

• Priority: Low
• Quality: Medium

A simple draft -> done workflow seemed to work but needed more testing. Authors can create drafts of documents, but only editors can finalize changes. Draft versions should not be publicly visible. There is no way to use workflows or assign editors only for some URLs.

The Revisioning module worked better than Workflows for unpublished revisions.

We decided not to implement workflows and revisioning at this stage, since authors would be reluctant to adopt and use the CMS if they had to wait for editors to approve every change.

Taxonomy Access Control or TAC Lite could be used to restrict permissions to groups, but it was not obvious how to restrict write permissions without restricting read permissions.

Version History

• Priority: Low
• Quality: Medium

It is nice to be able to keep track of all page edits and versions, but usually not essential. Using workflow settings, we made creating a new revision for every edit the default for pages and most content types so that authors would not have to remember to do this, like in the Staff Wiki. Changes to menus and blocks cannot be tracked. The diff module is good for finding differences between versions.

Content Administration

Importing Existing Content

• Priority: High
• Quality: Medium

Import HTML requires php-tidy which is not installed in RedHat Linux; either we would have to compile PHP or use CentOS.

It generally works well, generating menu items, stripping off .html extensions, and creating redirects to the shortened URLs.

It was necessary to reorganize the generated menu, remove a placeholder page, and do some search and replace, but this was relatively quick.

Images and other non-page files should be put into an easier-to-access folder than sites/default/files/imported/.

The author meta tag should be put into the page author.

Exporting Content

• Priority: Medium
• Quality: Medium

If we decide not to use Drupal now or in the future, we may need to export the Drupal pages to HTML.

The HTML Export module allows dumping all existing pages to HTML, and keeps links relative, but it does not preserve subdirectories, e.g. about/hours becomes about-hours.html. Changing the module code to preserve subdirectories would be straightforward but non-trivial. An alternative is to write a separate utility application that queries the appropriate Drupal database tables and writes the information to files.

HTTrack is another way to dump pages to HTML, but it creates absolute links, and copies local directories containing non-Drupal pages as well as non-local sites.

Both methods do not allow excluding code from <head>, header and footer sections (which we would replace with SSI includes). Dreamweaver could be used to search and replace in all files, but it might require some complex regular expressions. It is much easier to create a copy of the site with simplified versions of the page.tpl.php and node.tpl.php templates for the purpose of exporting.

Integration with Existing Content

• Priority: High
• Quality: High

By default, Drupal will display an existing page or application if it exists, and a Drupal page otherwise. This generally works well, but it doesn't allow us to put some pages of a subsite in Drupal and other pages in HTML. If any pages in a subdirectory are in Drupal, they must all be in Drupal.

For testing purposes, we installed Drupal in a separate directory in a virtual host and added symbolic links to some existing directories. It was easy to grab the header, footer and scripts from the HTML <head> tag and replace our existing header.html, footer.html and scripts.html, and most pages displayed fine. A few sites with customized layouts like Archives would need some redesign.

Friendly URLs and Redirects

• Priority: Medium
• Quality: Medium

It is easy to turn on friendly URLs to remove the ?q= URL.

The Pathauto module generates automatic URLs based on the title, but everything is put in a content/ folder, so in general it would be better to force the user to manually enter a URL. Putting the URL path settings field just below the title in the page editor makes it more noticeable so that users will remember to give every page a path.

Path Redirect helps redirect existing pages to external pages, but it is necessary to create dummy pages, so rewrite rules are usually better for this.

Search and Replace

• Priority: Medium
• Quality: Medium

The Search and Replace Scanner module is powerful, since it can search and replace in the entire site and allows regular expressions. It does not search and replace in menus or blocks, and it cannot be restricted to a set of URLs, so its use is restricted to editors. It also has a bug that destroys the URL path aliases of all files with replacements, so it is necessary to temporarily turn off the pathauto module.

Statistics

• Priority: Low
• Quality: High

The Google Analytics module makes adding tracking codes easy.

Systems Administration

Modules and Upgrades

• Priority: High
• Quality: High

Acquia Drupal came bundled with most of the modules we needed.

Installing and upgrading Acquia Drupal with Subversion has worked well, though it took awhile to perfect the list of upgrade steps to sync with a test server.

Drush is a powerful command-line tool to make Drupal contributed module updates and other administration tasks easier. It normally requires PHP 5.2 but our version of RedHat Linux only supports PHP 5.1.6. The workarounds suggested at Drush with PHP 5.1.6 were necessary.

Backup and Restore

• Priority: High
• Quality: High

The Backup and Restore module has worked well for saving the database and copying the entire site to another server.

Poor Man's Cron is helpful for scheduling regular backups without using crontab.

Security

The book Cracking Drupal and the Security Review module are both helpful for checking and improving site security.

Drupal 7

• Priority: Low
• Quality: Low

Drupal 7 requires PHP 5.2 but we only have PHP 5.1 on our Web server. Drupal 7 Alpha still has a long way to go. It is supposed to improve in performance, security, modularity and robustness, but Drupal 7 versions of most contributed modules will not be available soon, so we won't be able to upgrade to Drupal 7 this year.

Conclusions

Drupal has many powerful features, holds lots of promise for improving our site and work processes, and requires relatively little software development, but it is more complex and time-consuming to learn, configure, use and maintain than we had hoped.

Our website redesign was completed in about ten months. Most of the content redesign was on the home page and top-level navigation items.

As of November 2010, only about 14% of our static content (25% of content with the CSU Libraries standard theme) has been moved to Drupal. Some pages could be left where they are, and the Import HTML module will help import some content, but content redesign should be the focus of our work because it will take the most time. We should have a dedicated content editor with the time, skills, authority and trust by Libraries staff to rewrite, edit, redesign, relocate and remove existing pages.

We need buy-in from Libraries staff Web authors, who need to be involved in and spend time developing the prototype and helping with the project. Only then will we know how usable and useful the system is to them. If systemic change is to occur, the appropriate people need to make the project a high priority, take ownership, and do the work.

A possible major benefit of a CMS is that it can reduce the number of systems to maintain, and the number of silos with separate content and behavior. Eventually it could replace wikis, blogs, comments forms, custom Web-based forms, staff directory, staff intranet, and custom subsites. We do not want most of the content to remain outside of the CMS, or to be neglected within the CMS.