Top Banner
Drupal for Publishers …………………………………………………………………………………………….… Release 1.0 May 2009 Seth Gottlieb, Content Here, Inc. …………………………………………………………………………………………….… © 2009 All rights reserved. Content Here, Inc.
26

Drupal for Publishers

Oct 03, 2014

Download

Documents

Seth Gottlieb

This is a report that I wrote back in 2009 when Drupal was at version 6.10. The specific details about the software are out of date but business aspects and general themes are still valid..
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: Drupal for Publishers

Drupal

for Publishers

…………………………………………………………………………………………….…

Release 1.0

May 2009

Seth Gottlieb, Content Here, Inc. …………………………………………………………………………………………….… © 2009 All rights reserved. Content Here, Inc.

Page 2: Drupal for Publishers

Drupal for PublishersSeth Gottlieb

Single Product ReviewVersion 1.0, Workgroup Edition

Copyright © 2009 Content Here, Inc.All Rights Reserved. Not for Redistribution.

License Agreement and DisclaimerWorkgroup LicenseThis report is licensed under a "Workgroup License" that allows your company to make this report available to upto ten (10) staff members. It may not be shared with customers or copied, reproduced, altered, or re-transmittedin any form or by any means without prior written consent. Any rankings or scoring information may not be used inpromotional materials.

DisclaimerThis report is intended to be an overview of the technologies described and not a recommendation or endorsementof a specific platform or technology strategy. The most appropriate platform for your use depends on the uniquerequirements, legacy architecture, and technical capabilities of your organization. Content Here, Inc., cannot ensurethe accuracy of this information since projects, vendors, and market conditions change rapidly. Content Here, Inc.,disclaims all warranties as to the accuracy or completeness of the information in this report and shall have no liabilityfor errors, omissions, or inadequacies in the information presented.

Credits and AcknowledgementsCover design and page layouts by LAC Design

XLST work by Patrick Liddy

Special thinks to Michael Greer (The Onion), Michael Meyers (Now Public), Ken Rickard (Morris Digital), Ed Sussman(Fast Company), and Robert Taylor (MyLifetime.com) for sharing their Drupal experiences.

Page 3: Drupal for Publishers

DRUPAL FOR PUBLISHERS | VERSION 1.0, WORKGROUP EDITION | APRIL 2009 2

© 2009 Copyright Content Here, Inc. | All Rights Reserved. Not for Redistribution. | www.contenthere.net

Drupal for Publishers

ABSTRACTWhile to the outside world Drupal is seen as a web content managementsystem, the Drupal community sees the platform as a framework for buildingdynamic, interactive web applications. With its modularity and built-infeatures like user profile management with self registration, taxonomy-based navigation, and commenting, Drupal is particularly well suited forbuilding social content applications. Indeed, Drupal's interactive featuresare a key reason for its adoption by traditional media companies looking toengage their audience as a contributing community. Publishers can start byenabling commenting on articles and can work their way to user submittedarticles, pictures, video, and audio. Over the past couple years Drupal hasbecome "go-to" platform for public radio station and newspaper websiteswhere timeliness is a critical part of the navigation and user experience.Magazine websites that strive for a groomed content organization and layoutto accompany their print editions use Drupal less frequently.

A thriving developer community has created an extensive library of modulesthat can be easily downloaded and installed. This allows a site owner toinexpensively pilot new features and see if an audience embraces them.Many startups have credited successful business launches to Drupal's lowstart-up costs and flexibility; established companies have used Drupal asan alternative to their main CMS to lower the barriers to innovation on newbusiness initiatives. Startups and established companies have also foundthat Drupal is extensible and scalable enough to grow with them.

The velocity and modularity of the Drupal project do create liabilities. Thereis a high level of functional redundancy between the hundreds of contributedmodules, and the level of quality ranges widely. Choosing the wrong modulecan easily make a site unstable or insecure. Many developers find that it iseasier to write a module from scratch than to find the best module to reuse.Upgrading to newer versions of Drupal has also been difficult. The Drupalcore team prioritizes advancing the platform over maintaining backwardscompatibility and providing a smooth migration path. Most Drupal moduledevelopers care even less about future-proofing their code and there arefew guidelines for them to follow if they tried. But with larger companies thatrun business-critical websites on Drupal, this mindset is shifting. Acquia, astartup designed to be the "Red Hat of Drupal" has entered the market toprovide corporate stability and accountability to counterbalance the energyand spontaneity of the Drupal community.

Page 4: Drupal for Publishers

DRUPAL FOR PUBLISHERS | VERSION 1.0, WORKGROUP EDITION | APRIL 2009 3

© 2009 Copyright Content Here, Inc. | All Rights Reserved. Not for Redistribution. | www.contenthere.net

PROJECT OVERVIEW

Table 1. Drupal Overview

Website: http://drupal.org

Project Inception: 2000

Current Version: 6.10

Project Type: Community open source with 3rd party support options

Licensing Options: GPL

Geography: Global

Common Uses: New media publishing

Sample Customers: The Onion [http://www.theonion.com/] runs on a forkedversion of 4.x.

Lifetime TV [http://http://www.mylifetime.com/] runs on 5.x.

Now Public [http://http://www.nowpublic.com/] runs on 5.x.

Integration Standards: ANSI SQL

Architecture: LAMP (PHP 4 and 5)

Databases: MySQL and PostgreSQL

Page 5: Drupal for Publishers

DRUPAL FOR PUBLISHERS | VERSION 1.0, WORKGROUP EDITION | APRIL 2009 4

© 2009 Copyright Content Here, Inc. | All Rights Reserved. Not for Redistribution. | www.contenthere.net

BACKGROUND

From its humble beginnings in 2000 as a university student's hobby project to create abulletin board system for exchanging messages among students, the Drupal project hasgrown at an increasing rate - vastly outpacing other popular open source web contentmanagement platforms like Joomla!, Plone, eZ Publish, and Typo3. With every new majorrelease, the number of downloads (now at 200,000 per month) doubles. Attendance atDrupal user conferences has increased at a similar rate; the most recent Drupal conferencedrew 1,422 attendees and 55 corporate sponsors.

Many attribute Drupal's success to the Web 2.0 wave picking up on the project's emphasison social media and community content. In the media and publishing industry, there isa common desire to convert heretofore passive audiences into engaged communitiesthat personally identify with the brand and contribute content. No doubt the leadershipof project founder Dries Buytaert played an important role in the rapid growth of theDrupal community. It helped that Drupal had the good fortune of not getting stuck in theorganizational schisms that hobbled Joomla! and and phpNuke.

In addition to growing, the Drupal community is changing. Originally used for smallsites ranging from individual blogs to small community-of-interest sites, Drupal is beingadopted as a publishing platform by big-name media sites with millions of unique visitorsper month. Early adopters include theonion.com and mtv.co.uk, both with high trafficvolumes that silenced doubts about Drupal's scalability. It seems that every day anotherrecognizable media brand announces their migration onto Drupal; most recently MotherJones, Recovery.gov, and Virgin Radio have been identified as Drupal sites.

Large company interest has attracted investment capital. Acquia, a startup co-founded byBuytaert, recently raised $7 million to become the "Red Hat of Drupal." Acquia developershave already had a positive impact on the Drupal core with updates to make it moreenterprise ready. They also offer different support packages including Drupal hosting andmonitoring services. Acquia is not the first company to try to offer support services aroundDrupal but it was the first one to include Dries. SpikeSource put together a Drupal offeringcalled "Drupal SpikeIgnited," but it was barely noticed by the Drupal community and failedto thrive. Acquia, with its closer connection to the Drupal community, has shown success indeveloping value-added services and selling subscriptions.

While Drupal's dramatic growth is a great measure of success, it is also creating stresswithin the project as it tries to serve increasingly divergent needs. The individual andgroup blog sites still represent a bulk of the Drupal population but their needs are notnecessarily in line with the larger Drupal implementations that demand scalability,configuration management, and strict security. Large Drupal sites are working together bybuilding communities that discuss issues like performance. They are also contributing andunderwriting development of enterprise grade features.

Page 6: Drupal for Publishers

DRUPAL FOR PUBLISHERS | VERSION 1.0, WORKGROUP EDITION | APRIL 2009 5

© 2009 Copyright Content Here, Inc. | All Rights Reserved. Not for Redistribution. | www.contenthere.net

EXAMPLE SUCCESSES

Despite the once infamous Peter Van Dijck post " Drupal considered dangerous forstartups?" [http://poorbuthappy.com/ease/archives/2006/12/09/3382/drupal-considered-dangerous-for-startups] , there are a number of highly recognizable websites running onDrupal. Many new businesses (startup and internal) attribute their success to the efficiencyand flexibility of the Drupal platform. McClatchy has roughly 85 websites, ranging from fullnewspaper sites like the Miami Herald to small blogs and micro-sites, running on Drupal.Drupal has become so common in public radio that it is news when a public radio sitechooses a platform other than Drupal. Sony Music and Warner Brothers Music are hostingall of their artist sites on a Drupal multi-site configuration where the code base is sharedacross potentially hundreds of independent sites. Warner Brothers has three programmersdoing all the programming work for all of these artist sites. However, it should be noted thateach site has its own database and there is no content sharing between sites.

In general, Drupal has the highest adoption rate with sites that focus on communitycollaboration and timeliness such as newspapers (which are increasingly taking on ablog-like format for their online experience) and broadcast stations (whose traffic isprimarily driven by what was just said or played in the broadcast). Magazines that usetheir websites to create a community around the magazine content and loosely couple thetwo publications also like Drupal. Magazines that carefully lay out pages to replicate theexperience of the paper magazine tend choose other systems. Here are a few short casestudies of early successes with Drupal.

Fast Company

In February 2008, Fast Company deployed Drupal to enable social media functionality across their

two sites: fastcompany.com and incbiznet.com. A primary design goal of the new system was that

all of a registered visitor's content contributions in both sites should be associated with his user

profile. They found Drupal to be a better functional fit than alternative commercial and open source

platforms because of its focus on social media. Fast Company chose Drupal over white-label hosted

social media solutions like Pluck and Kickapps because they wanted control over their data and also

to reduce the risk of getting locked into an expensive pricing plan.

Fast Company now operates a hybrid architecture consisting of FatWire's Content Server product

for managing magazine-oriented editorial content and Drupal for all content delivery and for

managing socially oriented content. The rich end-user functionality of both sites created a high

degree of complexity that extended the migration project and also created scaling issues since

resolved through caching strategies.

Lifetime TV

In 2007, the Lifetime TV team took roughly four months to migrate their primarily static website

www.lifetimetv.com onto Drupal. The main goal for the migration was to establish a framework for

building community oriented functionality that would turn the site into a social portal for women.

Page 7: Drupal for Publishers

DRUPAL FOR PUBLISHERS | VERSION 1.0, WORKGROUP EDITION | APRIL 2009 6

© 2009 Copyright Content Here, Inc. | All Rights Reserved. Not for Redistribution. | www.contenthere.net

In searching for a new platform, they considered a number of Microsoft and PHP based commercial

and hosted solutions. They chose Drupal for its focus on community features which were not yet

supported by the commercial platforms. They were willing to compromise on classic web content

management features like digital asset management, workflow, and strong preview.

The Lifetime TV site, as well as its sister site Dress Up Challenge [http://dressupchallenge.com],

is designed to support interactive functionality under high traffic load. The most popular features

on the site are interactive games. The development team consists of five in-house developers and

Lifetime TV occasionally uses external systems integrators for special projects. They deploy code

two times per week but many of these deployments combine code and content.

Morris Publishing

Morris Publishing publishes many regional publications including The Florida Times-Union, The

Athens Banner-Herald, and The Augusta Chronical. While the centralized Morris Digital group

has its own custom CMS for its bigger web properties, Drupal is now the standard platform for

deploying smaller sites such as Bluffton Today (see below). Because of Drupal's community

orientation and agility, it has been a powerful enabler for Morris to innovate business models

with a local focus. The ability to inexpensively execute new business ideas has led to strategic

breakthroughs like moving away from the broadcast model, which has proven very successful at the

community level.

Drupal was originally brought into Morris in 2005 as an unsanctioned end-run to quickly and

inexpensively build out a daily local tabloid (a new concept for Morris) called Bluffton Today.

Using the standard publishing platform would have taken too long and commercial products

were not feasible because of the budget. They found Drupal to match up with 80 percent of the

requirements and two "technically sharp non-programmers" were able to pick up enough PHP to

get the site done in a short amount of time. Since building Bluffton Today, Morris has continued to

build new sites on the Drupal platform.

Now Public

Unlike the traditional media companies in this report, Now Public was built from the ground up

as a community news site. Site founder Michael Meyers claims that the business wouldn't have

succeeded without Drupal. The platform allowed them to prove a new publishing concept by getting

their business off the ground and continues to enable innovation. A development team of two full

time employees and four consultants took the site from concept to launch in under five months.

Now community contributors post over 800 stories a day.

Now Public has a development team of 10 that continually innovates on the platform. The

philosophy is to always try new ideas and learn from every failure. They see Drupal more as a web

development platform than a CMS and have built a number of custom features to make it easier

for power users to be more productive on the site. Larger projects take from two to three weeks

and code is deployed weekly. For the more complex projects, Now Public has brought in some

high profile Drupal developers though the rest of the team consists of PHP generalists that learned

Drupal while at Now Public.

Page 8: Drupal for Publishers

DRUPAL FOR PUBLISHERS | VERSION 1.0, WORKGROUP EDITION | APRIL 2009 7

© 2009 Copyright Content Here, Inc. | All Rights Reserved. Not for Redistribution. | www.contenthere.net

The Onion

The Onion, which runs both theonion.com and avclub.com on Drupal, was one of the first big

name sites to adopt Drupal and prove that the platform could be scaled to high volumes of traffic

(roughly 5 million unique visitors per month browse theonion.com). When The Onion deployed

Drupal (version 4.5), their size and other requirements put them in the minority of the Drupal

community. In order to scale, they had to fork their version to the degree that it is no longer

compatible the main line of Drupal development. They also had to apply some engineering rigor

that was uncommon to the mainstream Drupal community at the time. The Onion does not use

components and features (like CCK, Views, and Blocks - see explanation in the Developer section)

that store configuration settings in the database due to the inability to effectively manage these

configurations across environments. Instead they control this configuration as code, implemented as

modules. But that doesn't mean that the Drupal development team moves slowly: they deploy new

code daily.

Perhaps the most interesting aspect of The Onion's use of Drupal is that they use it as a pure

content management system - not as a social media platform. All of the social media functionality

has been built in Django and layered into the site using AJAX. The Onion is happy with the

editorial interface that the Drupal provides their web producers because it gives them adequate

control over article content and layouts by embedding markup.

Page 9: Drupal for Publishers

DRUPAL FOR PUBLISHERS | VERSION 1.0, WORKGROUP EDITION | APRIL 2009 8

© 2009 Copyright Content Here, Inc. | All Rights Reserved. Not for Redistribution. | www.contenthere.net

WHAT THE PUBLISHER NEEDS TO KNOW

Historically, Drupal's quirky, developer-dominated community has been disconcertingto traditional managers. A visit to a Drupal conference ("Drupalcon") would give aconservative CIO pause before entrusting the company website to the product of such afree spirited group. Indeed, the first big Drupal sites were a leap of faith made to achievebig dreams on a minimal budget. Now, with its proven track record in the publishingindustry, a Drupal migration doesn't feel like such a maverick move. With nearly 750contributors to the last release, the Drupal community is large with staying power equalto or greater than a commercial product. Still, working with Drupal is a much differentexperience than buying a more traditional commercial product like Vignette, FatWire, orInterwoven. Development teams are going to be smaller, development cycles are going tobe shorter, and everything is going to feel looser. Here are some specific areas to consider.

Time to Market

Drupal implementations tend to go quickly when compared to traditional web content management

systems. Part of the reason for that is many Drupal sites are being put up on a shoestring, but

equally important is that Drupal sites tend to be "assembled" rather than built. Whereas in

traditional deployments feature requests are pushed back with formal requirements, development,

and testing processes, with Drupal it is not uncommon to hear someone say, "I think there is a

module that does that, let's give it a try." This pragmatic approach makes compromises to take

advantage of what is available (and then iterate and refine) rather than try to design the perfect

solution on the first go. Many Drupal sites do code deployments multiple times per week.

That is not to say that the pre-existing feature or found add-on module is good enough to use

indefinitely. In many cases, companies will have to invest in developing important features that

have to be robust. A good example of that is search. The traditional on-board search engine was

barely adequate and many companies found that they had to integrate with something better. Now

there are a number of add-on search integrations available, however there are other unsatisfactory

features that need to be replaced with more sophisticated implementations.

Sites that are developed like prototypes (where new ideas are tested by quickly implementing

and rolling out a feature) tend to become unmanageable unless someone has the discipline to go

back and fortify successful, but hastily implemented, features. A manager should not make the

mistake of thinking that because something is working therefore it is done and requires no further

investment. Drupal does not protect a developer from poor decision making (see Security section).

Unlike other development frameworks that make it hard to break rules and cut corners, in Drupal,

the easiest way to do something is often the worst way.

Availability of Talent

The Drupal community is huge and continues to grow rapidly. It is getting to the point that most

PHP developers have at least played around with the platform. There are Drupal user groups in

many larger cities in North America and Europe. However, while basic Drupal development can be

point-and-click-easy, Drupal is one of those technologies where a novice developer can lulled into

Page 10: Drupal for Publishers

DRUPAL FOR PUBLISHERS | VERSION 1.0, WORKGROUP EDITION | APRIL 2009 9

© 2009 Copyright Content Here, Inc. | All Rights Reserved. Not for Redistribution. | www.contenthere.net

a sense of confidence and then quickly get out of his depth. By the time he realizes he is breaking

things, the site may be difficult to fix. There are many Drupal sites out on the web that are unstable

and insecure because of unscrupulous hacking by Drupal newbies.

Historically many of the most talented Drupal developers have been independent free-lancers.

These superstars are easy to find on the Drupal.org site that lists their profiles and all their Drupal

accomplishments. A potential employer can learn alot about a candidate by reading his posts

and comments on the Drupal forums. However, some Drupal sites have complained that the top

Drupal developers can been aloof and unresponsive (even to promises of generous compensation)

when the client needs help . This has posed a problem for larger companies looking for the level

of accountability and professionalism that a large systems integrator would offer. Some of the

biggest Drupal sites have built relationships with one or two big names in the Drupal community

to assist with the architecture but prefer to build skills internally for the day to day maintenance

and enhancement of the system. These companies find that a good PHP developer can pick up

Drupal rather quickly. Of course, if you don't know the language yourself, PHP skills are difficult

to measure because their are a lot of novice programmers and web designers who claim PHP

knowledge if they can type <?php echo "Hello World"; ?>.

Over the last couple of years, reputable systems integrators have been building competencies

in Drupal and are able to provide a comprehensive implementation service that includes project

management and other skills in a contract that shares the risk between the buyer and supplier.

Demand for these services is high so these companies are able to charge a premium over an

independent developer that you would find yourself. Still, many customers feel that the reduced risk

is worth the price.

Costs

Like most applications built on PHP, Drupal runs quite nicely on cheap hardware and inexpensive

hosting plans. A farm of four servers running the Linux operating system can handle a reasonably

high traffic site with acceptable levels of fault tolerance. The other software that it takes run

Drupal (Apache Web Server, the PHP programming language, and the MySQL database) are all

free. Most commonly the site would run at a hosting service that specialized in supporting LAMP

(Linux, Apache, MySQL, and PHP). Depending on the level of service required, a hosting plan

to adequately support 1 to 2 million page views per month is in the $3,000 per month range. The

recent trend in "cloud computing" (with services like Amazon's EC2 and S3) has disrupted the

hosting marketplace and many hosting providers are leveraging these services. Buyers should keep

an eye out for changes in price and options available. Because so many hosting services and cloud

technologies support LAMP, the buyer can take advantage of the commoditization and competition

to get better prices and service.

Road Map

The Drupal project has historically been very aggressive with respect to pushing the platform

forward. By the time one release is official, there is already considerable excitement of what

will be in the next release. Each release tries to introduce a balance of feature, architecture, and

usability improvements. The last two major releases have been interesting because of the diversity

Page 11: Drupal for Publishers

DRUPAL FOR PUBLISHERS | VERSION 1.0, WORKGROUP EDITION | APRIL 2009 10

© 2009 Copyright Content Here, Inc. | All Rights Reserved. Not for Redistribution. | www.contenthere.net

of the Drupal community. By population, a majority of the Drupal community thinks of Drupal

as a blog-like CMS that is effective for managing a small dynamic website. A smaller, but very

influential segment of the community sees Drupal as a framework for building big elaborate

sites that get bombarded with traffic. As the central figure of the project and the president of the

Drupal Association, project founder Dries Buytaert sets the direction and arbitrates between these

competing interests. In addition to being the leader of the Drupal project, Dries is the CTO of

Acquia, which can apply influence with the resources and products that it is able to provide. Acquia

is still a startup and is figuring out its market. So far, it looks like it is trying to serve both ends

of the spectrum: their "gardens" offering is designed for small hobbyist sites (along the Geocities

model), and also offer high end hosting for high traffic sites.

One aspect of the Drupal road map that is intentionally neglected is backwards compatibility.

Drupal core developer Angela Byron summarized the policy by saying:

The Drupal project has an unconventional philosophy on backwards compatibility.

During each major version of Drupal, developers are highly encouraged to think up

crazy new things that Drupal can do, without fear of breaking legacy APIs. While

users’ data will always be preserved throughout the ages, if we come up with new

standards we want to support, or a much better and more performant way of doing

something, developers are given free reign to go off in that direction. (Source:

OStatic [http://ostatic.com/blog/interview-angela-byron-top-drupal-developer-and-

evangelist])

In February 2008, the Drupal community launched the 6.x series of the platform. Version 6.0 was

a huge improvement over version 5 in terms of stability and performance but few of the big sites

have migrated from version 5 yet even as Drupal 7 nears release. Most industrial-grade Drupal sites

wait a few point releases before making a major upgrade but some of the sites built on Drupal 5 and

earlier will never upgrade because they have had to hack at the core to build in functionality that

was introduced in later releases.

Drupal 7, which will reach code freeze in September 2009, promises to be an even larger step

forward than version 6.0 was. After September 1st, the core team will shift gears from adding

new features to fixing bugs and optimizing performance. On the architectural side, Drupal 7 will

include a testing framework that may help improve the quality and reliability of submitted code

and also make it easier to tell if a module is safe to upgrade. There are a number of enhancements

targeted toward media companies including better handling of multi-media content and improved

functionality for structuring and organizing content. They have also enlisted the help of design

specialist Mark Boulton to help with usability.

In addition to the core road map, a Drupal adopter needs to consider the road map of the modules

that they use because the modules are what provide most of the functionality. Modules are

often built by small companies or individuals who have a difficult time planning and predicting

how much investment they will be able to make. Enhancements to a module are usually made

when someone steps up to pay for it (either by paying the module developer or by contributing

enhancements that they have made). The good news is that this arrangement can give great control

to a buyer who can afford it; the bad news is that this style of management can lead to some chaotic

decision making and messy code.

Page 12: Drupal for Publishers

DRUPAL FOR PUBLISHERS | VERSION 1.0, WORKGROUP EDITION | APRIL 2009 11

© 2009 Copyright Content Here, Inc. | All Rights Reserved. Not for Redistribution. | www.contenthere.net

The Knight Foundation, a non-profit organization founded to support journalism has created a fund

to support Drupal development that benefits journalism. The Knight Drupal Initiative (KDI) [http://

groups.drupal.org/knight-drupal-initiative] has pledged a nearly $500,000 to invest in journalism

related Drupal projects for 2009 and has a history of granting money to Drupal related projects

through its News Challenge program. A notable beneficiary of this program is Radio Engage [http://

radioengage.com/] initiative to create a special Drupal distribution that is configured for a radio

website. The Knight Drupal Initiative grant and individual contributions by media companies

should continue progress in developing stable, media-friendly functionality.

Page 13: Drupal for Publishers

DRUPAL FOR PUBLISHERS | VERSION 1.0, WORKGROUP EDITION | APRIL 2009 12

© 2009 Copyright Content Here, Inc. | All Rights Reserved. Not for Redistribution. | www.contenthere.net

WHAT THE EDITOR NEEDS TO KNOW

Editors and content contributors with a history of frustration working on complicatedsystems autocratically controlled by IT will be delighted by the simplicity and autonomythat Drupal promises. Most of the functionality can be controlled by configuration throughthe administrative interface and the installation of modules. However, the editor shouldconsider the fact that he is now more responsible for the stability and maintainability ofthe site. An editor with administrator privileges can easily make a mistake with majorconsequences and, because most work is done on the live site, those consequences areimmediate.

Content Entry

One of the most distinctive characteristics of Drupal is that it has no concept of a folder or a

tree structure for content. In its place is a powerful taxonomy system for tagging content. An

administrator creates a hierarchical collection of terms called "vocabulary." Vocabularies can

either be controlled or allow users to add their own terms. These terms can be used to create

faceted navigation of the content repository. Faceted navigation leads more pathways through the

site, more relevance, and, potentially, more page views (and advertising impressions) per visitor

session. For example, a new topical index page of content can quickly be created and dynamically

added to the navigation by tagging relevant articles. The administrator can restrict who can use

different vocabularies to tag their content. This approach has advantages and disadvantages. The

core advantage is that tagging is more flexible than a classic hierarchical foldering system; content

can appear in more than one section of the site. The disadvantage is that the lack of folders makes

it harder to do things like hierarchical access control to editing content. While possible, it is a little

awkward to configure Drupal to only allow a subset of contributors to add content to the "sports

section" of the site.

Drupal has a flexible content model that allows the definition of different content types. Out of

the box, there is support for content types "blog," "page," and "story" but many more are available

through the installation of modules and custom content modeling. The user interface to input these

content types are somewhat primitive: essentially a vertically oriented list of fields that can be

broken up into tabs. The framework itself doesn't provide much in the way of client and server side

validation and database lookups, but those features can be added with custom code if desired. Most

customers don't bother.

Like many content management systems, Drupal uses the TinyMCE rich text editor. The basic text

styling functionality is well supported by the editor itself, but the integration for linking and image

embedding is fairly rough. There is no support for browsing the site to create managed intra-site

links so it is up to the contributor to make sure in-page links work. Fortunately, because of Drupal's

flat URL structure, article URLs do not change often. Version 7 of Drupal is expected to introduce

some enhancements of the WYSIWYG editor option.

Old school customers with webmaster skills don't bother with the rich text editor and choose

instead to type or paste in their own HTML. If the contributor knows what he is doing, he can

write HTML that is of better quality and standards compliance than that produced by a WYSIWYG

Page 14: Drupal for Publishers

DRUPAL FOR PUBLISHERS | VERSION 1.0, WORKGROUP EDITION | APRIL 2009 13

© 2009 Copyright Content Here, Inc. | All Rights Reserved. Not for Redistribution. | www.contenthere.net

control. A contributor with limited HTML skills will tend to create poorly formed HTML that is

worse than what a WYSIWYG control would produce. One of the interesting features about Drupal

is that there is an option to allow users to insert PHP code into the text area fields. This exposes

a lot of flexibility to a webmaster who can be trusted to write reliable PHP code. It is also a risk

because it puts a contributor in the position to really mess up the site. The PHP in content feature

has been pulled out into its own module that is disabled by default. Many Drupal implementations

remove the PHP module to mitigate the risk of abusing this potentially dangerous feature. Still, for

the "programmer journalist" who can be trusted to write solid PHP code, publishing an application

as a piece of content has its appeal.

By managing metadata, the author can control the behavior of the content such as allowing visitors

to comment on the item or promoting the item to appear on the front page of the site. There is very

little functionality to control things like the order of articles in a list. There are, however, add-on

modules that supply a block (described later) that contains an ordered list of items.

Workflow

Over the years, the community has been improving the workflow capabilities of Drupal. It

started with the "Workflow-ng" (or "Workflow Next Generation") module that was a ground-up

replacement of the original "Workflow" module. More recently was the arrival of the Rules module

that takes workflow one step further by allowing the configuration of complex rules to determine

the progression of content from state to state. Still, few Drupal sites make much use of workflow

to support editorial processes. The most common use of Workflow-ng and now Rules is to drive

complex application logic in interactive applications. For example, Acquia uses the Rules module

for its trouble ticketing system. Many Drupal media sites do not do much with workflow. Instead

they use the rudimentary yes/no "published" field on each content item to control whether an asset

is live. Often these sites have their true editorial cycle outside of Drupal and only push the content

into Drupal when the copy is final and all that is left to do is some post-processing for the web.

WoodWing [http://www.woodwing.com/], an application for running print workflows in Adobe

Creative Suite, is coming out with an integration that pushes content into Drupal at a specific

state in the workflow. The sites that do start their editorial process in Drupal tend to have smaller

(trusted) editorial staffs, more streamlined processes and a less formal editorial tone. Drupal fits

fine in both of these scenarios. If you have a complex web-first editorial workflow, you may be

able to implement it using the Rules module but you will be out of the mainstream.

Page 15: Drupal for Publishers

DRUPAL FOR PUBLISHERS | VERSION 1.0, WORKGROUP EDITION | APRIL 2009 14

© 2009 Copyright Content Here, Inc. | All Rights Reserved. Not for Redistribution. | www.contenthere.net

Figure: Publish State - Drupal's default configuration has a simple Boolean field to indicate published or draft.This is suitable for some implementations but sites with more elaborate workflow needs may want to implementthe more sophisticated "Rules" workflow module.

Editorial Control

One of the most attractive things about Drupal is the level of control that it gives non-programmers.

An early challenge for Drupal was to eliminate the need for a webmaster. To a large degree Drupal

has achieved that by making everything parameterized and implementing a portal-like display

tier. Drupal essentially has one master page layout for every page on the site. This is different

than other frameworks that may give the editor multiple layouts to choose from. The Drupal

layout has "regions" that can be populated with "blocks" that are supplied by modules. From the

administrative user interface, an authorized user can drag a block into a region and then configure

its behavior. If you know a bit of PHP, you can write an expression with logic that describes

when the block should display (like when the visitor lives in Massachusetts). It would be better if

Drupal provided a user interface to configure this logic rather than relying on the editor to write

syntactically correct PHP.

Page 16: Drupal for Publishers

DRUPAL FOR PUBLISHERS | VERSION 1.0, WORKGROUP EDITION | APRIL 2009 15

© 2009 Copyright Content Here, Inc. | All Rights Reserved. Not for Redistribution. | www.contenthere.net

Figure: Drupal's layout manager - The Drupal presentation tier is very portal-like with regions that can be filledwith modules. Users are empowered but run the risk of messing up the live site.

There is also no way to select a display template for a particular content asset. All assets of a

particular content type are displayed by the same display template that controls the middle of

the page where the item is displayed. There is well known work-around where the template logic

displays the content different ways according to the value of a metadata field, but this is not a

particularly elegant or scalable solution. The upshot of this is that editors tend to embed a lot of

markup into their content. For example, a site may have just a couple of generic content types and

embed markup into the body to make the articles look like "features" or "reviews." This, of course,

is sub-optimal because it makes it very difficult to globally reformat the articles - especially if

the contributors practiced the lazy habit of using inline font and style tags rather than referencing

global style sheets.

The administrative interface gives non-programmers control over nearly every aspect of the

function and behavior of the site. A user can edit workflows, assemble views (queries that return

and display lists of content), and install and configure modules. But with control comes risk:

modifications are done on the live site and are active the instant the user clicks save. It is not

difficult to put the site in a non-working state. Because contributors have the control of developers

they need to apply development practices like tying out things on a development environment and

thoroughly testing first. Prudent access control and an open dialogue between contributors and

developers are the surest ways to balance the benefits and risks of delegated control.

By and large, early adopters of Drupal have practiced a fast and loose management style where

changes are made to production with little structure or ceremony. The "perpetual beta" mindset of

Web 2.0 has mitigated some of the risk of working this way by making visitors more tolerant of

unexpected behavior. When moving control into the hands of the editors, they either eventually

Page 17: Drupal for Publishers

DRUPAL FOR PUBLISHERS | VERSION 1.0, WORKGROUP EDITION | APRIL 2009 16

© 2009 Copyright Content Here, Inc. | All Rights Reserved. Not for Redistribution. | www.contenthere.net

settle on their own appropriate balance of stability and agility or make enough mistakes to force

developers to take back control.

General Usability

Frameworks are not usually evaluated for their end-user usability because normally developers use

frameworks to build applications for users. But Drupal is not your normal framework. It straddles

the line between application and framework because it provides some core application functionality

and a container for other applications (that is, Drupal modules) to sit in. A Drupal module gets

a location that the user can navigate to and a baseline user interface that can be extended within

certain constraints. While Drupal is not technically a portal technology it is a framework like a

portal is a framework.

Drupal is one of the rare projects that takes a scientific approach to usability. The community has

relationships with university usability labs that regularly test usability and make recommendations

for improvements. The most impressive part is how receptive the Drupal community is to the

feedback. The usability team is particularly committed to making the user interface approachable

to a novice user. They take care to promote consistent behavior and language used. To this end,

there has been an interesting debate around the word "Node." Technical people really like the fact

that everything in Drupal (from a piece of content to a user profile to a group of users) is a Node.

This allows programming logic to easily and uniformly act on most of what is managed in Drupal

- its very object oriented. But to a non-technical person who doesn't really understand the virtues

of object oriented-ness, "Node" is a silly, abstract word that means nothing. Over the past releases,

there have been efforts to expunge terminology like "Node" from the contributor user interfaces.

Earlier versions of Drupal enforced a single user interface for visitors and managers of the website.

All visitors and users would go to the same site and, depending on their privileges, they would see

more or fewer menu options. There are some advantages and disadvantages to this approach. On the

plus side, being able to edit the site as you navigate it is very intuitive for a content contributor. On

the negative side, the flexibility that Drupal gives you in theming your site can easily make it less

usable for content contributors and administrators. Starting with version 6, Drupal allows you to

select a different theme for administration of the site. This way internal users can get a theme that

is optimized for usability rather than branding.

Drupal has a nice direct path through simple content contribution tasks. An authenticated users

clicks the "create content" link and is presented with a list of content types that he is allowed

to create. The user interface has room for instructional text to explain what the various content

types and controls are used for. Other tasks that require going into the "Administer" area of

the application can get more complicated because of the sheer number of configuration options

available to the user (see screenshot). With every release, there are different approaches of how

to organize the administrative functionality. While progress has been made, it is still confusing.

As mentioned earlier, Drupal does not love strict hierarchies so the end result is a long list of

links with terse explanations. Advanced users know where to look and, more importantly, where to

ignore. Eye scanning analysis of novice users shows total disorientation.

Page 18: Drupal for Publishers

DRUPAL FOR PUBLISHERS | VERSION 1.0, WORKGROUP EDITION | APRIL 2009 17

© 2009 Copyright Content Here, Inc. | All Rights Reserved. Not for Redistribution. | www.contenthere.net

Figure: Drupal Administration - The administration pages can look busy and confusing to the uninitiated.Different versions of Drupal have explored different approaches to organize the large number of links but this kindof shuffling has led to minimal improvement.

There may be a limit to how much Drupal's usability can be improved as it tries to serve such

a diverse set of users. A developer who sees Drupal as a development framework, will have a

different vision for usability than a site administrator who will have different needs than a content

contributor. To some extent this can be handled by access control, but that only goes so far. Drupal

may one day break up its user interface by user segment, but until that happens there will always be

compromises.

Page 19: Drupal for Publishers

DRUPAL FOR PUBLISHERS | VERSION 1.0, WORKGROUP EDITION | APRIL 2009 18

© 2009 Copyright Content Here, Inc. | All Rights Reserved. Not for Redistribution. | www.contenthere.net

WHAT THE DEVELOPER NEEDS TO KNOW

At first, developing on Drupal is quite a departure from the other enterprise gradetechnologies a developer may be experienced with. There are some great articles ofdevelopers transitioning from an initial repulsion to an eventual respect and admiration forthe technology (see How I Learned to Love Drupal [http://www.netaustin.net/2008/12/21/how-i-learned-love-drupal] by Austin Smith). Drupal's loose development style runscounter to the ideals practiced in other frameworks. Java developers tend to requirethe most adjustment. Drupal is not designed to be object oriented. There is not a strongseparation between the data, the business logic, and the view. Unit testing has beennearly impossible (although that is changing with version 7). Deployment is messy. But,despite all this, there usually comes a point in a Drupal developer's progression wherehe embraces the philosophy and sees it as quite elegant and liberating - similar to howdevelopers embrace Ruby on Rails. Indeed, many of the best Drupal developers, includingDries himself and Robert Douglas, come from Java backgrounds. Developers are advisedto read from some true Drupal experts before giving up on the technology.

While the core codebase is pretty clean, module code can be a total mess. There are manyin the Drupal module development community who have only basic programming skills andvery poor judgement when it comes to code design. This has given Drupal the probablyundeserved reputation of being hacky and sloppy.

Extensibility and development efficiency

One of Drupal's biggest strengths is its modular design that has enabled a thriving community of

contributors to form around the core project. Modules, which are written in plain PHP, contain

custom code that adds new functionality or extends core functionality. To install them, you simply

put them into the "modules" directory and enable them through the UI. Writing modules is pretty

straightforward once a developer is familiar with Drupal's "hooks" mechanism. Matt Butcher's book

Learning Drupal 6 Module Development is useful to get started in module development.

While developing modules is relatively easy, it takes discipline, knowledge of Drupal best

practices, and sound programming sensibilities to write a good module. Many of the modules

available for download are unstable or are of otherwise poor quality. Developers are advised to

thoroughly test a module on a replica of the live site before deploying it to production. Poorly

written modules can have bad interactions with other modules and even mangle core functionality

and/or data. Modules also do not always migrate nicely during core upgrades. One major issue in

the Drupal 5-6 upgrade was that the Views and CCK modules (described later), which many other

modules relied on, took a while to be upgraded to Drupal 6. This was largely because of poorly

timed rewrites of these modules.

The Drupal module library has hundreds of modules but there is a high level of functional

redundancy among them. Many developers confess that it is often easier to write a module from

scratch than to source the most appropriate re-usable module. The best information about which

modules are good comes from the Drupal specialists in the community using them every day. It is a

good idea to get to know these people over IRC or at various Drupal events. Another good resource

Page 20: Drupal for Publishers

DRUPAL FOR PUBLISHERS | VERSION 1.0, WORKGROUP EDITION | APRIL 2009 19

© 2009 Copyright Content Here, Inc. | All Rights Reserved. Not for Redistribution. | www.contenthere.net

is the usage page [http://drupal.org/project/usage/] that lists how many sites are using a module.

Still, even a poorly written module may be of some value if it can be used to demonstrate or pilot a

feature. If the feature turns out to be successful, it may be worth the investment to re-implement in

a more robust way.

Extensive customization of a Drupal site can be done without writing a single line of code. By

installing the right modules, selecting a good theme, and configuration through the administrative

user interface, a non-programmer can make a lot of progress. Modules like CCK (Content

Construction Kit, which allows user-defined content types to be configured in the user interface),

and Views (which allows users to define query based lists of content) can minimize programming.

However, these convenience comes at a cost: configuration management.

Because these settings are stored in the database, it is very difficult to deploy them from a

development environment to a production environment using standard configuration management

practices. Drupal veterans all have their tricks when it comes to replicating environments but they

often seem like hacks when compared to more traditional, file based, configuration management

practices that use a source code control system. There are a number of developers working on this

problem for their employers who need this functionality. Notable modules include the Database

Scripts project [http://drupal.org/project/dbscripts] (that contains scripts to dump, erase, restore,

and merge databases), the Deploy module [http://drupal.org/project/deploy] (that provides a

mechanism and user interface for synchronizing objects across multiple Drupal instances), and

Drush, which provides a scriptable command line shell to control a Drupal environment. These

projects are still in the experimental phases and are far from mainstream. A more realistic strategy

is to stick with modules that have a robust system storing setup parameters in the initialization

script (that can be managed in a source code control system). The Views module has been improved

in this way through development supported by Sony BMG. Development practices with scripts that

can build the site from a pristine Drupal instance are also encouraged. Larry Garfield from Palentir

is working on a Drupal deployment system.

The upcoming major release of Drupal (version 7) is expected to make Drupal more robust as

a development platform and better able to serve larger sites. A key improvement will be the

introduction of a unit test framework that is intended to make releases more reliable and shorten

the QA period that goes into each release (Drupal 6 was developed for five months and was in

code freeze to fix bugs for 7). Improvements such as unit testing and performance upgrades tend

to highlight the differences within the Drupal community. Big sites are desperate for these features

but smaller, more casual sites tend not to appreciate the effort that goes into them.

Migrating between versions of any software application can be problematic but Drupal can be

worse than most. The trouble is not so much with the core (although issues can arise) but with the

modules. Very few modules are designed to upgrade nicely between versions of the Drupal core. A

big part of this is that modules freely interact directly with the core database tables that the Drupal

core changes between releases of the system. Many modules (even the popular ones) are slow to

support newer versions of the Drupal core. Because of this, many Drupal sites are running on old

versions of the core.

Page 21: Drupal for Publishers

DRUPAL FOR PUBLISHERS | VERSION 1.0, WORKGROUP EDITION | APRIL 2009 20

© 2009 Copyright Content Here, Inc. | All Rights Reserved. Not for Redistribution. | www.contenthere.net

Security

Over the years the Drupal community has become increasingly aware of security issues. The Drupal

core application is getting more secure and the security alert and fix systems are getting more

responsive. Still, it would be an overstatement to say that an interest in security has become a

significant part of the Drupal developer community consciousness. For example, some Drupal

module developers write a lot of SQL code and many are not sufficiently aware of SQL injection

attacks and other concerns. The better Drupal module developers mitigate the risk of SQL injection

by using the database abstraction layer API that automatically escapes potentially nefarious inputs.

This database API is very easy to use. Rather than using the PHP method "mysql_query," Drupal

developers can use the similarly named but safer "db_query."

Cross-site scripting is a more common exploit, after all, the history of the application was to

allow communities to communicate over the Internet. The Drupal core has put some thought into

its handling of user submitted text. Text input fields can have "filters" with different levels of

permissiveness. Out of the box are: plain text with no formatting (useful for fields like a title); rich

text that can be either simplified HTML or a syntax Textile [http://www.textism.com/tools/textile/];

and a full HMTL filter intended for administrators only. On the presentation side, built-in functions

like check_plain(), check_markup(), check_ulr(), and filter_xss_admin() do the work of filtering

out potentially harmful text before they are written to the rendered page.

The Drupal Forms API provides a framework for building forms for collecting user data. Using the

Forms API is not required but it offers useful security and features. In particular, it helps protect

against cross-site request forgery. Any module that modifies data should use the Forms API, which

ensures that updates are made using POST requests and contain fields that identify the request as

being legitimate.

One aspect of Drupal that will always be a stumbling block for companies with strict security

standards for infrastructure is the fact that Drupal is a single application that does both the

management and the display of content. This is unlike some of the more traditional CMS platforms

that publish content out to a separate delivery tier that can sit out in the DMZ. You can't really

protect a Drupal site with firewalls. It needs to sit out in the open. This design is great if you want

to dissolve the barriers between author and audience like many publishers are trying to do. It makes

less sense if you have valuable data that you need to be paranoid about protecting. You will not see

many big banks running on Drupal.

The Drupal community has a security advisory system that quickly communicates vulnerabilities

(see the Drupal Security Page [http://drupal.org/security]). Because of the number of add-on

modules in circulation (and their varying quality), the number of notices is quite high and most

Drupal site maintainers had to ignore most of them. Recently the security advisory service has been

restructured to differentiate between core issues and issues related to modules. Still, if your site has

a lot of modules, you still need to evaluate all of the notices for their relevance to your site.

Performance

Drupal is a very relational database oriented framework. When trying to optimize a Drupal site

for performance, most of the work is done at the database level. Liberal use of the Views module

Page 22: Drupal for Publishers

DRUPAL FOR PUBLISHERS | VERSION 1.0, WORKGROUP EDITION | APRIL 2009 21

© 2009 Copyright Content Here, Inc. | All Rights Reserved. Not for Redistribution. | www.contenthere.net

(which is simple enough for a non-DBA to use) can lead to the home page of your site, executing

hundreds of database queries with every request. Keeping the number of queries reasonable is

a good place to start. You should also optimize the database itself; for example, using a faster

MySQL persistence engine like InnoDB is recommended.

In many ways, scaling Drupal is like any other LAMP application. One of the core LAMP

philosophies is to "share nothing." That is, there is loose coupling across the stack without large

monolithic components like a Java application server. Consequently the strategy to scale LAMP is

to distribute load over many machines. A larger Drupal site will have several web servers behind

a reverse proxy server (such as Squid or Varnish) talking to a cluster of MySQL database servers.

This configuration works particularly well for media and publishing sites where more people read

than contribute content. For sites with high volumes of user submitted content, the cluster must

constantly synchronize files and data but this challenge has been overcome many times and there

are plenty of people who know how to do it. If your site has the good fortune of getting several

million page views per day, there are always CDN options such as Akamai.

Drupal also has its own performance features. There is a "throttling" mechanism where you select

features to turn off if the server is straining. There is also a configuration to compress CSS files by

combining them, compressing them, and caching them on the browser. The same approach is used

for Javascript files. The net result is that the browser makes fewer requests to the server with each

page load.

Drupal's caching system is getting progressively more sophisticated. It used to be that full pages

were cached in a relational database and retrieved for display to un-authenticated visitors. Logged

in visitors got freshly generated pages but slower performance. Now Drupal is doing much more

with in-memory cache and finer-grained cache control. There is also a configuration that uses the

popular memcached [http://www.danga.com/memcached/] system. The memcached integration

increases the amount of memory that can be used to store things like user sessions and other data

because it is a distributed service. One thing that is missing from the caching framework is block

level caching where segments of the page (such as a global navigational element) are considered

stable enough not to require generation with every request.

Persistence

In Drupal, every piece of content is called a "node" and is stored in the node table which contains

core attributes that all nodes must have. Extended (or specialized) attributes are stored in extender

tables. This makes Drupal behave in a somewhat object oriented manner. Programming logic can

easily work across different types of nodes ("polymorphism" in object oriented parlance). The

downside is that the node table can get very large, exposing poorly written queries (like partial

string matches against un-indexed fields). It is not uncommon for node tables to reach over a

million records.

Drupal 6 has a database abstraction layer that does some translation into different variants of

SQL, but nearly all Drupal sites are running on either MySQL or PostreSQL. Theoretically Drupal

can run on Oracle and there has been some work in that area. However, running on Oracle would

certainly put you in the minority of the Drupal community. The database abstraction layer in Drupal

7 is a total rewrite and may make porting to alternative databases more feasible and more common.

Page 23: Drupal for Publishers

DRUPAL FOR PUBLISHERS | VERSION 1.0, WORKGROUP EDITION | APRIL 2009 22

© 2009 Copyright Content Here, Inc. | All Rights Reserved. Not for Redistribution. | www.contenthere.net

Versioning is now part of the Drupal core, but there are some add-on modules available to enhance

the functionality. The implementation is fairly simplistic but it does a good job of managing

revisions of the title, teaser, and body fields. Custom content types need to implement their own

versioning, which is not too hard to do. Binary files such as binary attachments to structured

content types are stored in a "files" directory and are not versioned.

Profile management

Drupal's profile management is one of its key strengths and one of the reasons why it is such a

good option for building community sites. All users of the system (everyone from the super user

administrator down to the lowliest self-registered visitor) have the same construct of profile.

Groups and permissions determine what a user can do. Drupal is designed in such a way that it

is very easy to build functionality where everything that a visitor does is neatly organized and

displayed on his profile page. The most powerful user in the system is the first one to be added

(user id = 1, where user id is a sequence). Throughout the application there is logic to check the

user id (for a value of 1) as well as look at roles when determining permissions. This is an example

of a hacky little feature that just works in Drupal.

Although profiles are not stored using the Node system, they are just as easily extensible with

additional attributes. New fields can be a single line text field, a multi-line text field, a check box,

a list selection box, a free form list, a URL, or a date. If the rich text editor is enabled, it will be

used to edit the mult-line text field. One issue with the extended attributes is that they are stored in

a single long text field which can make them awkward to query and update with a SQL script.

Presentation

In Drupal, all of the presentation code that controls the layout and branding of the site is

encapsulated in a pluggable "theme." A theme consists of a couple of presentation templates written

in either straight PHP or a templating engine like phptemplate. The central templates are the

page template, which contains the overall HTML wrapper; the node template, which controls the

display of each individual node, and a comment template that controls the display of comments.

There is also a template.php file that contains functions. This helps to encourage developers to

keep complex logic outside of the templates but there is nothing stopping them from abusing the

separation between layout and logic. This requires discipline because it can be very tempting to

bend the rules of good judgement when deadlines are tight.

Because the developer has no idea what kind of functional modules will be placed on a page, the

Drupal presentation tier is difficult to optimize for performance. Every module can manage its own

database connections and can execute any number of queries against the database. An overloaded

page can execute 100's of queries with every page load. Moreover, many of these queries can be

generated using the "Views" module and may not be optimized for performance. The Node table,

which many of the queries will hit contains every piece of content in the repository and can get

quite large so un-indexed table scans can be quite costly.

Page 24: Drupal for Publishers

DRUPAL FOR PUBLISHERS | VERSION 1.0, WORKGROUP EDITION | APRIL 2009 23

© 2009 Copyright Content Here, Inc. | All Rights Reserved. Not for Redistribution. | www.contenthere.net

Resources

The Drupal community is active, prolific, and generally helpful. People blog about Drupal

development topics and post questions and answers on the Drupal.org website. It is not hard to

find answers to most questions with a few Google searches. There are many books written on

Drupal, though they tend to go out of date quickly. Two of the better titles are Professional Drupal

Development (by John VanDyk) and Using Drupal (by Angela Byron, Addison Berry and a number

of other authors). Interested developers should definitely subscribe to the Planet Drupal RSS feed

that aggregates all of the Drupal oriented blogs.

Attending one of the many Drupalcon conferences across North America and Europe is a great way

to connect with Drupal developers and learn from the best. The conference sessions are informal

and invite fairly technical questions. "Birds of a Feather" sessions get into more detail. Drupalcon

conferences usually end with a coding (and documentation) sprint where developers can work

together on a shared project to improve Drupal and amplify learning. Many cities also have local

users groups that are organized on meetup.com. In between Drupal conferences and Meetups, the

Drupal IRC channel is always active for immediate questions.

Potential customers looking for commercial grade software support should look at Acquia's

services. They are not the first company to offer a Drupal support package but they certainly

have the inside track on Drupal with Dries as their CTO. The Acquia support offering comes with

modules that can be installed in your Drupal installation and report on its health and integrity.

Sticking with the Acquia distribution will also help ensure the upgradability of your installation to

future versions of the platform.

Page 25: Drupal for Publishers

DRUPAL FOR PUBLISHERS | VERSION 1.0, WORKGROUP EDITION | APRIL 2009 24

© 2009 Copyright Content Here, Inc. | All Rights Reserved. Not for Redistribution. | www.contenthere.net

SUMMARY

Table 2. Drupal 6.10 Summary

Category Score Explanation

Availability of Talent Drupal leverages widely available PHP skills and there isa large community of Drupal developers.

Road Map The large Drupal development community continuallypushes the platform forward. Investment by the KnightFoundation and individual publishers is helping to improvemedia and publishing functionality.

Content Entry Drupal has a flexible content model but validation andcross linking features are somewhat weak.

Workflow Drupal's workflow modules have sufficient support for thebasics.

Usability Good support for basic contribution tasks. Novices caneasily be overwhelmed by the administration area.

Editorial Control The blocks framework gives the editor powerful controlover what appears on pages but editors cannot chooselayouts. PHP skills are needed to control when a blockdisplays.

Extensibility Drupal's API and module framework allow developers tooverride nearly any default behavior but there is someadjustment to working in the Drupal way.

Developer Efficiency Developers find they can develop robust applications at"prototyping speed." Convention over configuration feelsliberating after working with Java frameworks.

Security Solid API for making applications secure but very littleprevents developers from working around the API.

Performance Drupal supports traditional LAMP scaling strategies plusadditional caching and throttling features. Drupal has aproven track record supporting high traffic sites.

Profile Management Drupal has extensible user profiles that are associatedwith everything a user does.

DeveloperResources

Drupal has huge and active developer community thatattends conferences, provides training, and writesprofessional books.

Key: Nonexistent; Below Average; Average; Above Average; Exceptional.

Page 26: Drupal for Publishers

DRUPAL FOR PUBLISHERS | VERSION 1.0, WORKGROUP EDITION | APRIL 2009 25

© 2009 Copyright Content Here, Inc. | All Rights Reserved. Not for Redistribution. | www.contenthere.net

Drupal's large and active community of developers continues to grow and improve theplatform. Drupal's community ensures the future of platform and makes it relatively easyto find developers and hosting solutions to support your Drupal site. But the Drupalcommunity is also extremely diverse and has different needs. This has prevented it fromaddressing some usability issues and infrastructural limitations such as code deployment.

From a functionality perspective, Drupal straddles the line between a content managementsystem and web application development platform. As a pure CMS it is good for the basicsbut comes up a little short when it comes to access control, page layout, and generalusability. Sites looking for a more fluid, blog-like organization of content with immediatepublishing will feel more comfortable with Drupal than sites that are interested in creating amore controlled magazine-like experience online.

For building content-rich web applications, Drupal gives you a higher starting point than atypical web application framework but forces you to design your application in a distinctlyDrupal way. The Drupal architecture can get somewhat messier than a technology that wasdesigned initially as a framework. Unlike other web application frameworks, Drupal doesnot necessarily push developers toward making good design decisions. It is very easy tobuild insecure, unmanageable websites on Drupal and many sites do this either by writingbad code themselves or installing poorly written modules.

But the upside of being able to rapidly build interactive websites cannot be denied. A gooddeveloper can build a Drupal site about as fast as a web designer can build a prototype.There was a case of a radio station website being built in a day. That successful websiteshave been on the platform for years is a testament to the point that the Drupal architectureis robust and scalable enough to support serious media and publishing websites. There arefew, if any, cases of media and publishing companies "outgrowing" Drupal. In many ways, itis hard to do better than a platform that goes up quickly and lasts.