Drupal For Publishers

Drupal
for Publishers
Release 1.0 May 2009 Seth Gottlieb, Content Here, Inc.

.
2009 All rights reserved. Content Here, Inc.
Drupal for Publishers

Seth Gottlieb Single Product Review Version 1.0, Workgroup Edition Copyright 2009 Content Here, Inc. All Rights Reserved. Not for Redistribution.
License Agreement and Disclaimer

Workgroup License
This report is licensed under a "Workgroup License" that allows your company to make this report available to up to ten (10) staff members. It may not be shared with customers or copied, reproduced, altered, or re-transmitted in any form or by any means without prior written consent. Any rankings or scoring information may not be used in promotional materials.
Disclaimer
This report is intended to be an overview of the technologies described and not a recommendation or endorsement of a specific platform or technology strategy. The most appropriate platform for your use depends on the unique requirements, legacy architecture, and technical capabilities of your organization. Content Here, Inc., cannot ensure the 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 liability for errors, omissions, or inadequacies in the information presented.
Credits and Acknowledgements

Cover 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.
DR UP A L F O R P U BL I S H E R S | V ER S I O N 1 . 0 , W O R K G R O U P E D I T I O N | A P R IL 20 0 9
Drupal for Publishers

ABSTRACT
While to the outside world Drupal is seen as a web content management system, the Drupal community sees the platform as a framework for building dynamic, interactive web applications. With its modularity and built-in features like user profile management with self registration, taxonomybased navigation, and commenting, Drupal is particularly well suited for building social content applications. Indeed, Drupal's interactive features are a key reason for its adoption by traditional media companies looking to engage their audience as a contributing community. Publishers can start by enabling commenting on articles and can work their way to user submitted articles, pictures, video, and audio. Over the past couple years Drupal has become "go-to" platform for public radio station and newspaper websites where timeliness is a critical part of the navigation and user experience. Magazine websites that strive for a groomed content organization and layout to accompany their print editions use Drupal less frequently. A thriving developer community has created an extensive library of modules that can be easily downloaded and installed. This allows a site owner to inexpensively pilot new features and see if an audience embraces them. Many startups have credited successful business launches to Drupal's low start-up costs and flexibility; established companies have used Drupal as an alternative to their main CMS to lower the barriers to innovation on new business initiatives. Startups and established companies have also found that Drupal is extensible and scalable enough to grow with them. The velocity and modularity of the Drupal project do create liabilities. There is a high level of functional redundancy between the hundreds of contributed modules, and the level of quality ranges widely. Choosing the wrong module can easily make a site unstable or insecure. Many developers find that it is easier 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 Drupal core team prioritizes advancing the platform over maintaining backwards compatibility and providing a smooth migration path. Most Drupal module developers care even less about future-proofing their code and there are few guidelines for them to follow if they tried. But with larger companies that run business-critical websites on Drupal, this mindset is shifting. Acquia, a startup designed to be the "Red Hat of Drupal" has entered the market to provide corporate stability and accountability to counterbalance the energy and spontaneity of the Drupal community.
2009 Copyright Content Here, Inc. | All Rights Reserved. Not for Redistribution. | www.contenthere.net
PROJECT OVERVIEW
Table 1. Drupal Overview
Website: Project Inception: Current Version: Project Type: Licensing Options: Geography: Common Uses: Sample Customers: http://drupal.org 2000 6.10 Community open source with 3rd party support options GPL Global New media publishing The Onion [http://www.theonion.com/] runs on a forked version 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: Architecture: Databases: ANSI SQL LAMP (PHP 4 and 5) MySQL and PostgreSQL
BACKGROUND
From its humble beginnings in 2000 as a university student's hobby project to create a bulletin board system for exchanging messages among students, the Drupal project has grown at an increasing rate - vastly outpacing other popular open source web content management platforms like Joomla!, Plone, eZ Publish, and Typo3. With every new major release, the number of downloads (now at 200,000 per month) doubles. Attendance at Drupal user conferences has increased at a similar rate; the most recent Drupal conference drew 1,422 attendees and 55 corporate sponsors. Many attribute Drupal's success to the Web 2.0 wave picking up on the project's emphasis on social media and community content. In the media and publishing industry, there is a common desire to convert heretofore passive audiences into engaged communities that personally identify with the brand and contribute content. No doubt the leadership of project founder Dries Buytaert played an important role in the rapid growth of the Drupal community. It helped that Drupal had the good fortune of not getting stuck in the organizational schisms that hobbled Joomla! and and phpNuke. In addition to growing, the Drupal community is changing. Originally used for small sites ranging from individual blogs to small community-of-interest sites, Drupal is being adopted as a publishing platform by big-name media sites with millions of unique visitors per month. Early adopters include theonion.com and mtv.co.uk, both with high traffic volumes that silenced doubts about Drupal's scalability. It seems that every day another recognizable media brand announces their migration onto Drupal; most recently Mother Jones, Recovery.gov, and Virgin Radio have been identified as Drupal sites. Large company interest has attracted investment capital. Acquia, a startup co-founded by Buytaert, recently raised $7 million to become the "Red Hat of Drupal." Acquia developers have already had a positive impact on the Drupal core with updates to make it more enterprise ready. They also offer different support packages including Drupal hosting and monitoring services. Acquia is not the first company to try to offer support services around Drupal but it was the first one to include Dries. SpikeSource put together a Drupal offering called "Drupal SpikeIgnited," but it was barely noticed by the Drupal community and failed to thrive. Acquia, with its closer connection to the Drupal community, has shown success in developing value-added services and selling subscriptions. While Drupal's dramatic growth is a great measure of success, it is also creating stress within the project as it tries to serve increasingly divergent needs. The individual and group blog sites still represent a bulk of the Drupal population but their needs are not necessarily in line with the larger Drupal implementations that demand scalability, configuration management, and strict security. Large Drupal sites are working together by building communities that discuss issues like performance. They are also contributing and underwriting development of enterprise grade features.
EXAMPLE SUCCESSES
Despite the once infamous Peter Van Dijck post " Drupal considered dangerous for startups?" [http://poorbuthappy.com/ease/archives/2006/12/09/3382/drupal-considereddangerous-for-startups] , there are a number of highly recognizable websites running on Drupal. Many new businesses (startup and internal) attribute their success to the efficiency and flexibility of the Drupal platform. McClatchy has roughly 85 websites, ranging from full newspaper 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 site chooses a platform other than Drupal. Sony Music and Warner Brothers Music are hosting all of their artist sites on a Drupal multi-site configuration where the code base is shared across potentially hundreds of independent sites. Warner Brothers has three programmers doing all the programming work for all of these artist sites. However, it should be noted that each 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 community collaboration and timeliness such as newspapers (which are increasingly taking on a blog-like format for their online experience) and broadcast stations (whose traffic is primarily driven by what was just said or played in the broadcast). Magazines that use their websites to create a community around the magazine content and loosely couple the two publications also like Drupal. Magazines that carefully lay out pages to replicate the experience of the paper magazine tend choose other systems. Here are a few short case studies 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.
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.
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.
WHAT THE PUBLISHER NEEDS TO KNOW

Historically, Drupal's quirky, developer-dominated community has been disconcerting to traditional managers. A visit to a Drupal conference ("Drupalcon") would give a conservative CIO pause before entrusting the company website to the product of such a free spirited group. Indeed, the first big Drupal sites were a leap of faith made to achieve big dreams on a minimal budget. Now, with its proven track record in the publishing industry, a Drupal migration doesn't feel like such a maverick move. With nearly 750 contributors to the last release, the Drupal community is large with staying power equal to or greater than a commercial product. Still, working with Drupal is a much different experience than buying a more traditional commercial product like Vignette, FatWire, or Interwoven. Development teams are going to be smaller, development cycles are going to be 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
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
10
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-andevangelist]) 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.
11
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.
12
WHAT THE EDITOR NEEDS TO KNOW

Editors and content contributors with a history of frustration working on complicated systems autocratically controlled by IT will be delighted by the simplicity and autonomy that Drupal promises. Most of the functionality can be controlled by configuration through the administrative interface and the installation of modules. However, the editor should consider the fact that he is now more responsible for the stability and maintainability of the site. An editor with administrator privileges can easily make a mistake with major consequences and, because most work is done on the live site, those consequences are immediate.
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
13
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.
14
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 implement the 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.
15
Figure: Drupal's layout manager - The Drupal presentation tier is very portal-like with regions that can be filled with 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
16
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.
17
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 kind of 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.
18
WHAT THE DEVELOPER NEEDS TO KNOW

At first, developing on Drupal is quite a departure from the other enterprise grade technologies a developer may be experienced with. There are some great articles of developers transitioning from an initial repulsion to an eventual respect and admiration for the 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 runs counter to the ideals practiced in other frameworks. Java developers tend to require the most adjustment. Drupal is not designed to be object oriented. There is not a strong separation between the data, the business logic, and the view. Unit testing has been nearly 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 where he embraces the philosophy and sees it as quite elegant and liberating - similar to how developers embrace Ruby on Rails. Indeed, many of the best Drupal developers, including Dries himself and Robert Douglas, come from Java backgrounds. Developers are advised to 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 many in the Drupal module development community who have only basic programming skills and very poor judgement when it comes to code design. This has given Drupal the probably undeserved 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
19
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.
20
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
21
(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.
22
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.
23
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.
24
SUMMARY
Table 2. Drupal 6.10 Summary
Category
Availability of Talent
Score
Explanation Drupal leverages widely available PHP skills and there is a large community of Drupal developers. The large Drupal development community continually pushes the platform forward. Investment by the Knight Foundation and individual publishers is helping to improve media and publishing functionality. Drupal has a flexible content model but validation and cross linking features are somewhat weak. Drupal's workflow modules have sufficient support for the basics. Good support for basic contribution tasks. Novices can easily be overwhelmed by the administration area. The blocks framework gives the editor powerful control over what appears on pages but editors cannot choose layouts. PHP skills are needed to control when a block displays. Drupal's API and module framework allow developers to override nearly any default behavior but there is some adjustment to working in the Drupal way. Developers find they can develop robust applications at "prototyping speed." Convention over configuration feels liberating after working with Java frameworks. Solid API for making applications secure but very little prevents developers from working around the API. Drupal supports traditional LAMP scaling strategies plus additional caching and throttling features. Drupal has a proven track record supporting high traffic sites. Drupal has extensible user profiles that are associated with everything a user does. Drupal has huge and active developer community that attends conferences, provides training, and writes professional books.
Road Map
Content Entry
Workflow
Usability
Editorial Control
Extensibility
Developer Efficiency
Security
Performance
Profile Management
Developer Resources
Key:
Nonexistent;
Below Average;
Average;
Above Average;
Exceptional.
25
Drupal's large and active community of developers continues to grow and improve the platform. Drupal's community ensures the future of platform and makes it relatively easy to find developers and hosting solutions to support your Drupal site. But the Drupal community is also extremely diverse and has different needs. This has prevented it from addressing some usability issues and infrastructural limitations such as code deployment. From a functionality perspective, Drupal straddles the line between a content management system and web application development platform. As a pure CMS it is good for the basics but comes up a little short when it comes to access control, page layout, and general usability. Sites looking for a more fluid, blog-like organization of content with immediate publishing will feel more comfortable with Drupal than sites that are interested in creating a more controlled magazine-like experience online. For building content-rich web applications, Drupal gives you a higher starting point than a typical web application framework but forces you to design your application in a distinctly Drupal way. The Drupal architecture can get somewhat messier than a technology that was designed initially as a framework. Unlike other web application frameworks, Drupal does not necessarily push developers toward making good design decisions. It is very easy to build insecure, unmanageable websites on Drupal and many sites do this either by writing bad code themselves or installing poorly written modules. But the upside of being able to rapidly build interactive websites cannot be denied. A good developer 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 websites have been on the platform for years is a testament to the point that the Drupal architecture is robust and scalable enough to support serious media and publishing websites. There are few, if any, cases of media and publishing companies "outgrowing" Drupal. In many ways, it is hard to do better than a platform that goes up quickly and lasts.

Drupal For Publishers

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Drupal For Publishers

Uploaded by

Copyright:

Available Formats

Drupal

Release 1.0 May 2009 Seth Gottlieb, Content Here, Inc.

2009 All rights reserved. Content Here, Inc.

Drupal for Publishers

License Agreement and Disclaimer

Credits and Acknowledgements

Drupal for Publishers

WHAT THE PUBLISHER NEEDS TO KNOW

WHAT THE EDITOR NEEDS TO KNOW

WHAT THE DEVELOPER NEEDS TO KNOW

Extensibility and development efficiency

You might also like