Drupal Review
When I first looked at Drupal back in 2002 I'll admit to being completely unimpressed. It had a very plain interface and seemed to offer only basic functionality. In July 2009 I had some spare time and based on many positive reports I decided to give Drupal another go.
I'm so glad I did.
The year since then has been a journey of discovery through the wealth of free Drupal modules and the well documented, intelligently designed Drupal code and API. Drupal is a fantastic piece of software and has an organized, friendly and generous community behind it making on-going, frequent improvements.
This review can only really scratch the surface of the amazement and gratitude that I have experienced over the last year of building things with Drupal. If you're considering a content management system I hope you will do yourself a favor and add Drupal to your short-list.
Overview – What is Drupal?
Drupal is described by it's developers as a “community publishing system”. It is still a content management system but one that has been optimized for the web as a social medium.
In plain language what this means is that Drupal takes the best bits from legacy content management systems, forums, wikis, blogs, membership systems and e-commerce platforms and creates an integrated yet modular system for communication, publication and e-commerce.
Drupal is also an application development framework which strongly encourages (if not actually forces) developers to follow a common, structured approach which leads towards modular, maintainable, interoperable code with a common user interface.
Drupal is a “game changing” technology in that it makes it possible for “power users” to build web based content management applications without needing to write code.
What most impresses me about Drupal is the intelligence and attention to detail that has clearly gone into almost every part of the software. This is reflected in the simple yet sophisticated content management environment and in the quality of finished sites built using Drupal.
Getting Started with Drupal
Installation itself is straight forward and within the capabilities of anyone familiar with installing applications on web servers or an adventurous person able to read documentation and use ftp to upload files.
Once past the installation, there is undoubtedly a long, steep learning curve ahead for anyone new to Drupal. This is to be expected with any sophisticated enterprise class application.
The good news is that there is a lot of high quality documentation and despite (or probably because of) the complexity, Drupal follows predictable patterns which once learned make it easier to find and configure what you're looking for.
For end users, it is possible to configure Drupal so that each contributor is presented with only the simplest options they need to do their job. This massively reduces the complexity and amount of training needed and extends the ability to edit web content to the least web savvy users with minimal technical support.
Views & Content Construction Kit (CCK)
The first modules that should be installed on any Drupal site are “Views” and “Content Construction Kit”. Understanding these two modules is key to getting the most out of the “site building” capability for power users.
Content Construction Kit (CCK) adds a simple-to-use interface to the Drupal administration that allows non-technical users (and even technical ones) to create “content types”. A content type could be something like a blog post, product, job vacancy, event or something more “esoteric” like a personnel record.
CCK allows users to add any number of fields to their content types so that complete content objects can be stored in the cms. In Drupal terminology, these content objects are called “nodes”.
The companion module to CCK is Views. Views adds another user interface which allows non-technical users to select “nodes” from the CMS using quite sophisticated criteria, sort them and choose which fields to show on output. Views can be output as tables, grids, unformatted lists or a “node view” which allows programmers flexibility to hand code the output.
There are many non-web applications that do something similar to Views so it's not an original idea but Views is slick, advanced and powerful.
The combination of CCK and Views allows non-programmers to create simple yet sophisticated systems for managing and displaying complex content on web pages without needing any programming.
This is powerful. Even for me as a programmer, it is so quick to create content types and output them using Views that I can save days (or even weeks) of coding user interfaces to achieve the same effect compared to other content management systems.
Better still, since CCK is itself extensible, the Drupal community have created lots of freely downloadable field types so that it’s possible to have fields that store images, documents, categories, anything!.
The CCK Date field type with it’s ability to handle repeating dates and differing levels of “granularity” is a particular work of art. It would take days of coding to create similarly rich date handling functionality in bespoke forms, but here it is available for free with a quick download and simple install.
WYSIWYG Editing & Image Handling
WYSIWYG editing and image handling are one of the weaker points in open source content management systems and Drupal is no exception.
WYSIWYG editing would be better described as “rich text” editing as it takes place in a “rich text edit box” and the content must be previewed in order to see what it will *really* look like. In Drupal, WYSIWYG editing seems to be a bolt-on after thought (more than just seems, I suspect).
Despite the bolt on WYSIWYG editing, the only place I've found Drupal to be seriously lacking is in the handling of images in the rich text editing boxes.
If you're using plain text editing then the process of adding images is fine. Click the “Image Assist” button to be presented with a categorized list of existing images or the option to upload a new image. The upload new image option works smoothly allowing you to define the attributes for the image such as it's “alt” text, left or right aligned and whether or not to show a nail or full size.
The problem is that which ever WYSIWYG editor you're using doesn't “know” about Drupal which results in a complex procedure involving switching between editing modes, setting the alignment in two places and problems if you try some of the options which don't seem to work at all.
Although it's possible to train content authors how to work through this procedure, I can see it being a barrier for newbie or occasional users.
In fairness, the clunky image handling in rich text editors is in contrast with the superlative image handling throughout the rest of Drupal.
Content types can be created with “image fields” which allow one or more images to be attached to content items (nodes) and referenced using a field name in Views or templates. Image uploading is very straight forward and robust and a module called ImageCache enables the ability for images to be flexibly resized on-the-fly with no performance penalty.
Urls & Aliases
A simple yet important part of any content management system but one which is apparently easy to get wrong. Drupal gets it completely right !
Drupal allows friendly urls in the format “/my-friendly-url”. The url can be entered by the content author when creating content or typically it is automatically generated by the system using the content title and a set of simple rules. For example blog posts are assigned a url like /blog/my-blog-title, products get a url of /products/my-product-name etc.
URLs are “platform neutral” in that there is no .php or .html file extension. This should be an absolute requirement of any up to date content management system to prevent broken links in the event of a change in content management system. Urls are also “guessable” in that generally a visit to /blog or /products will generate appropriate and predictable content.
It is possible to maintain a set of “aliases” for any url in the system. For example, if you have a url of “/products/offers/my-special-offer” but for marketing purposes you would like to publish a simplified url of “/special-offers” or “/july-madness” or whatever this is easily achievable through a simple user interface. It's also easy to see at a glance all of the urls that your Drupal system is publishing and either remove them or alias them to something else.
Forms
Drupal has an excellent underlying forms architecture called the “Forms API”. The Forms API simplifies the development of forms and at the same time makes it easy for developers to code forms to a common standard.
The Forms API provides a set of field types and other form elements which mean that high quality forms can be quickly “assembled” without developers needing to worry about coding any of the details such as setting labels, basic validation or multi-language translation.
All the obvious field types are supported such as text-boxes, select boxes, check-boxes etc. The forms API also automatically adds sophisticated checking of submitted forms data to protect against vulnerabilities such as SQL and script injection attacks.
In addition to the basic form types, there are smart text-boxes that can dynamically present users with a list of previously entered values, file and image upload types, and calendars for handling sophisticated date input in a simple way.
The Forms API is extensible by module developers allowing additional field types to be added to the system. A brilliant example of this is the “Hierarchical Select” module which implements a very neat and flexible solution to the problem of asking users to select from a long list of “tree-like” data. A demo of the hierarchical select module is available here.
A great feature of the Drupal Forms API is the ability for developers to code modules that call a function called form_alter(). This function can alter the behavior of any other form in the Drupal system. This can be used to add (or remove) additional fields to a form or change what happens when a form is submitted. The complexities of this are handled internally by Drupal and caching is used so that form_alter can be used extensively without affecting performance. This gives module developers huge scope and power in customizing and enhancing the Drupal interface.
Another great feature is the ability for module developers to call “drupal_execute()” to submit data to forms in other modules. This turns each form automatically into a mini-API.
The Webform module allows end users the ability to create forms using a point and click interface without having to know anything about the underlying forms API. The Webforms module allows the user to specify simple actions on submission of the form to allow emailing of submitted forms data or logging to a database. Forms responses logged to the database can be queried, downloaded or published using the Views module.
Modules & Development
One of the best things about Drupal is the breadth and depth of the freely available modules. There are nearly 6000 modules listed on the Drupal.org website. I have found all of the modules that I have used to be pretty well documented, very easy to install and configure.
Unlike many other CMS, the freely available modules (I haven’t seen any paid-for ones) are superb quality. Truly, works of content management art.
The Drupal community has coordinated module development so that there are not lots of confusingly similar modules all doing variations of the same thing. There tends to be one discreet but sophisticated module with easy to configure settings that does everything you could ever want – and usually more !
Drupal has been built from the ground up to be extensible. This is achieved with the concept of “hooks”. Hooks allow module developers to write code which attaches to an event or action within the system. Module developers can use hooks to modify most aspects of the default system behavior and just as importantly developers can create their own hooks to allow other developers to re-use and enhance their modules.
The result is that most Drupal modules integrate with and rely on other Drupal modules. The resulting dependencies are managed nicely in a straightforward user interface and well documented on the drupal.org modules page.
Taxonomy & Categorization
Drupal has very advanced Taxonomy and Categorization functionality.
For those that aren't aware, a taxonomy is a hierarchical list of categories that can be used to classify content as being about a particular subject.
Taxonomies are useful for navigation, filtering search results to particular topics and for search engine optimization to provide “relevance” to particular categories of content.
It is straightforward to create and maintain multiple taxonomies in Drupal and categorize content against any or all of them.
The content construction kit (CCK) module allows content fields to be created which store the results of user classifications. CCK enables content to be classified (or tagged) in one of a number of ways. Categories can be selected from a list (using a traditional select list or hierarchical select) or typed in a tags with suggestions from smart textbox. This process is extremely slick and supports taxonomies, ontologies or folksonomies if that is what you're looking for.
There are a number of freely available modules that will automatically categorize (or tag) your content against a local set of rules or using 3rd party web services. These kinds of systems are cutting edge and can be expensive in the traditional closed-source software world.
jQuery
I won't pretend to fully understand the extent and details of Drupals integration with jQuery. What I know is that Drupal intelligently implements “jQuery behaviors” to transparently and significantly enhance many areas of the user interface. In all cases that I've seen the integration has been degrades gracefully if JavaScript is not available.
The forms API can also be used by developers to intelligently and gracefully utilize jquery to improve the user experience. This is an area that I have not yet properly explored but allows functionality such as the updating of select box lists based on user choices without a page refresh.
User profiles & permissions
Drupal is a community publishing system which means that management of large numbers of users is a core part of it's functionality.
Some of these users will be trusted “team members” and others will very much untrusted “anonymous” web visitors. Drupal provides the means to grant them all controlled access to edit content in a secure way depending on their level of trust.
Drupal includes all the of the standard register / login / forgot password functionality in a nicely tabbed interface and can send out personalized messages to confirm email addresses before new users are approved.
Drupal supports the creation of an unlimited number of “roles”. Each role can be assigned a set of permissions and each user can be associated with one or more roles to define what each user is allowed to do.
In addition Drupal also has the concept of “input formats” which provides an overriding restriction on the types of content a user with a given role can input. For example this means that an un-trusted anonymous user can add comments but can only use simple html tags such as <strong> or <em> . A trusted content author might be allowed “full html” meaning that they can use any html tag or content. This prevents untrusted groups of users from creating content either vulnerable to script injection attacks or more likely comments with awful formatting tags such as “marquee” or “blink”.
Drupal makes it very easy for module developers to include and check user permissions in the module code. The result of this is that modules generally have very granular permissions controlling what each role can do with a given module.
A downside to this when setting up a non-trivial site with a few roles and a number of modules is that there can easily be over a 1000+ permissions check-boxes to check. This can be something of a task – although it isn't as bad as it sounds.
Drupal makes it very easy to create and customize user profiles – ie allow users to enter additional information about themselves such as their real name, job title and a photograph. This can be easily achieved using a simple point and click interface.
Whilst the customizable profiles feature is great, there quickly comes a point where some confusion arises. One thing that would be very nice would be use CCK fields on your profiles. This is something that many Drupal users have realized and a range of solutions are available for using content types as profiles. There are a number of pros and cons to this approach but the bottom line is that there is currently a significant complication in this area and it isn't clear what to do for the best in Drupal 6 to be compatible with version 7.
(My understanding is that since Views and CCK are core functionality in Drupal 7, that CCK fields can be applied directly to user profiles in version 7 – however, this doesn't help people building production sites in version 6 now. Fortunately “content profiles” are so well used in 6 that I'm sure there will be an upgrade path to 7 regardless of what choice you make now)
Multi-site Management with Drupal
It is not uncommon for many organizations (or even individuals) to have more than one website or even tens or hundreds of websites.
Each website generates a maintenance overhead in terms of keeping the software and module patches up to date for security, maintaining templates & themes and the maintenance of users, roles & permissions. Using a multi-site architecture can save huge amounts of time and make it easier to for users to move around a corporate “portfolio” of sites without having to re-register.
Drupal allows site developers flexibility to build sophisticated multi-site architectures that can be either completely separate silos or complete integrated. This means that sites can share any combination of core code, module code, themes, users / roles / permissions and content (ie nodes).
This is a somewhat advanced topic but multi-site can be done in a secure way so that a “hosted Drupal” provider could create a massively scalable Drupal installation for 1000's of separate customers or a corporation could automatically share user details across its portfolio of branded micro-sites.
The Drupal “Multisite Manager” module allows non-technical users to create and delete micro-sites almost as easily as creating a blog post (although in fairness the Multi-site module is not suitable for all users – power users only I would suggest).
The Drupal Remote Dashboard module is a new module (works at it's best on Drupal 7) that allows completely separate Drupal installations (ie different servers in different data centers) to be centrally managed and updated via a single master installation. (The master installation must be Drupal 7. Slave sites can be Drupal 6 or 7). This is ideal for developers who manage multiple Drupal sites for a number of clients. Remote Dashboard can be combined (or not) with the Multi-site module. .
E-commerce
No discussion of Drupal or open source e-commerce could be complete without mentioning Drupals' e-commerce module … Ubercart.
It's difficult to know where to start in summarizing Ubercart in just a few lines. Ubercart is much, much more than just a shopping cart, hence the name.
Ubercart leverages Drupal and it's library of modules so that Views, CCK and Taxonomy Menu amongst others can all be used in the creation of an online product catalog and shop.
Ubercart is supplied with installable modules that provide point and click payment gateways to most if not all of the popular online payment providers. There are modules for managing stock levels and calculating complex shipping charges.
Ubercart allows (via Drupal Actions) the ability to add “roles” to users when they make a purchase from your Drupal shop. These roles may be permanent or expire after a certain period of time. This makes it straightforward to create “pay walls” or sell digital goods via secure download (and allow paying customers to re-download at any time).
The Ubercart Userpoints module allows site members to pay for goods with virtual currency.
Ubercart is a cutting edge e-commerce system in it's own right – it's just happens that it's totally integrated with the worlds advanced open source content management system.
Input Filters
Input filters are a small but important part of the Drupal system. To me they typify the attention to detail, thought and just plain “rightness” that has gone into the development of Drupal.
Whenever a user saves content this is put into the database *exactly* as the user entered it. At the same time, the content is passed through a list of input filters. Each filter in the list is run in sequence on the content, each with the ability to modify the content in some way.
For example an input filter could ensure that the html entered by the user is safe (ie doesn't include the <script> or the <marquee> tags) and another could change all occurrences of the string {user_real_name} to the real name of currently logged in user. For most content a number of input filters will be run depending on which “input format” is used.
The key thing to understand is that input filters can be used to “transform” content at “save time” without risk of losing valuable information from the original cost and with negligible performance penalty since the transformation only occurs once each time a piece of content is saved and not when the content is published.
Performance & Caching
Drupal has a sophisticated, yet ultimately simple caching architecture. Page elements such as content, blocks, views, forms are all cached so as to reduce the amount of processing required for each page request.
With caching turned on, a simple Drupal installation on a moderate server can support a very high number of concurrent users.
For extremely high traffic sites, the Drupal Memcached module uses an algorithm to store the most frequently accessed pages in RAM so as to serve them completely from cache with the absolute minimum of processing. (Drupal Memcached is not suitable for shared hosting accounts).
As with many current generation CMS', caching in Drupal 6 does not work so well for authenticated users. If a user is authenticated it's likely that the page and various elements will be personalized for that user and it becomes tricky for a caching system to know if it can serve a given piece of content from cache or whether it needs to be regenerated from scratch.
In Drupal 7, the caching sub-system has been upgraded so that it can correctly determine which content can be served from cache for both anonymous and authenticated users.
Drupal 7 and the Future
At the time of writing, Drupal 7 is approaching a beta release and appear that a production release is likely in the near future.
On the other hand, Drupal 6 is already great, rock solid and stable so whilst I'm keen to starting building and launching Drupal 7 sites, there is no desperate rush to do so.
Drupal 7 has some big improvements such as “admin overlay” and making views and CCK a core part of the system that I think will dramatically reduce the steep learning curve associated with Drupal 6.
Significant improvements to the rich content image handling have also been made for Drupal 7.
It looks like Ubercart 2 will be made available for Drupal 7 but then Ubercart development will shift to a completely new module (along the same lines) called DrupalCommerce. There will be an upgrade path from Ubercart to DrupalCommerce.
Conclusion
10 years ago when I was a developer for Immediacy ( a .NET based closed-source CMS vendor), open source CMS' were quite basic. It was easy to see why organizations that could afford it were prepared to pay tens of thousands of pounds for good quality but proprietary content management software.
These days open source systems like Drupal are blazing a trail and setting the standards which legacy commercial content management systems are struggling to follow.
There are over 300,000 active websites powered by Drupal and an army of dedicated developers, technical authors, trainers and enthusiastic users – not to mention companies providing professional technical support. A great many modules have been developed, problems solved, lessons learned and documentation written.
Many organizations are still paying £30,000 and upwards in licensing fees yet putting up with sub-standard documentation, poor support and expensive, basic modules and plugins. Such organizations would have a hard time believing how much better they could be getting it for free.
Of course in many cases, open-source software isn't truly free. You still probably need to pay an expert to install the software and train your staff. However, with open source software you are joining a vast and powerful community that has already done a lot of the hard work and is giving it away for free in the hope that you'll join them and help make their software even better.
About the Author
Simon Gardner is a freelance web technologist specializing in content management and specifically Drupal. For more information about the benefits of Drupal, Simon can be contacted via his blog