Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?
Back for a limited time - Get 15% off sitewide on Slashdot Deals with coupon code "BLACKFRIDAY" (some exclusions apply)". ×
Book Reviews Books Media

Building Powerful and Robust Websites With Drupal 6 153

Michael J. Ross writes "For creating Web sites, developers are increasingly making use of content management systems (CMSs), any of which can provide the framework for a new site. But just as there are many similarities among all the leading CMSs, there are some significant differences, such as how easy they are to install, administer, and build upon, for creating new sites. If developer loyalty is any measure of the present and future success of a CMS, then Drupal should be considered a standout among other CMSs. For instance, its online documentation alone is often cited as a distinguishing advantage. But most developers would prefer learning Drupal from a book, such as Building Powerful and Robust Websites With Drupal 6, by David Mercer." Keep reading below for the rest of Michael's review.
Building Powerful and Robust Websites With Drupal 6
author David Mercer
pages 380
publisher Packt Publishing
rating 8/10
reviewer Michael J. Ross
ISBN 1847192971
summary A comprehensive, readable, and upbeat guide to Drupal 6.
This particular book was published on 1 February 2008, under the ISBNs 1847192971 and 978-1847192974. It is one of the latest titles from Packt Publishing, a relatively new technical publishing firm that is nonetheless gaining a reputation for its support of the open source software movement, including open source CMSs such as Drupal and Joomla. The firm's "about us" page notes that, with the purchase of every book that covers an open source technology, they pay a royalty to that open source project. A recent article on the Drupal Web site states that the company has raised more than $100,000 through these open source royalties.

In his book's "About the Author" section, David Mercer mentions that this title is a follow-up to a first edition of the book, even though the publication information that follows the title page, mentions nothing about this being a second edition. Most likely he is referring to his 2006 book titled Drupal: Creating Blogs, Forums, Portals, and Community Websites, which covered Drupal version 4.7.

The publisher makes available a Web page devoted to the book, where readers can download the sample code, submit feedback, post a question about the book, read an online excerpt, and obtain a sample chapter, on "Advanced Content," as a PDF file. Readers can also purchase the electronic version of the book, which contains everything found in the print version. For any programmer who plans on developing Drupal sites on a laptop, while away from their home or office technical library, the e-book version could prove especially valuable and convenient.

Building Powerful and Robust Websites With Drupal 6 aims to cover all the major aspects of using Drupal, and is targeted at Drupal beginners, though the author does state in the preface that the book's broad coverage may be helpful to intermediate users. The information spans 380 pages, and is organized into 10 chapters and one appendix, covering: an introduction to Drupal, installation, modules and blocks, site configuration, user access control, creating content, advanced content, themes, advanced features, site management, and site deployment.

The first chapter serves as an introduction to Drupal, and explains the purpose of CMSs, the advantages of Drupal and other open source software, a brief history of Drupal, what Drupal offers to the site developer, and the many types of sites that can be built. The author discusses the reasons for keeping an unfinished site unavailable to visitors, the purpose of a placeholder page, and the importance of planning the intended site ahead of time. Especially useful to the beginner is the second half of the chapter, which discusses the support information available on the Drupal Web site, such as the well-regarded Handbook in the forums. The chapter concludes with a summary that, like all the others in the book, adds no value and could be cut, to make the book more concise. Newcomers to programming in general, and Drupal in particular, may find this chapter to be quite worthwhile; but experienced Drupal developers can skip it.

To the uninitiated, installing a substantial piece of software and getting it running, is usually the first hurdle, and sometimes the most difficult. Chapter 2 explains how to obtain and install Apache, PHP, and MySQL — in the form of Apache2Triad. This is preceded by a brief overview of the underlying needed technologies, which would be helpful to someone unfamiliar with them. However, the diagram on page 33 could certainly use better labeling of the inner components. Also, on page 47, the reader is instructed to look for the file php.ini in "C:\windows"; that may be the case for users of Apache2Triad, but for everyone else, the PHP configuration file is by default located in the PHP root directory. Nevertheless, the chapter explains not only the (relatively few) steps involved in installing Drupal on a Windows server, but also explains how to troubleshoot some of the more common problems that can be encountered. It concludes with an overview of the administration area, and how to create a simple homepage. The author provides the URL that a reader can use in case they accidentally disable user login (including admin login); but the URL (.../user/login) would only work if the reader succeeded in enabling clean URLs.

The critical topics of modules, blocks, menus, and links, are discussed in the third chapter, titled "Basic Functionality." It covers how to enable and configure modules, and how to find and install third-party modules. Three commonly used modules — Forum, Comments, and Search — are examined in detail, as is a third-party module that implements DHTML menus. They are put to use in constructing the sample Web site used throughout the book for illustrative purposes. The chapter's material is comprehensible, but the discussion of primary and secondary links, at the end, could certainly use clarification.

Chapter 4 is straightforward, and covers the fundamentals of site configuration. The author discusses clean URLs, error reporting, file uploading, system event logging and reports, high-level site information, and site maintenance. The subsequent chapter addresses the powerful functionality within Drupal for allowing site administrators to control user access to content — utilizing roles, permissions, users, registration, and access rules. It is a valuable discussion, marred only by a subpar illustration at the beginning (on page 117), and, at the end, the absence of a clear explanation as to the application of host type access rules.

All of the aforementioned topics would be of little value in a site that had no content, and in Chapters 6 and 7, David Mercer discusses simple and advanced content, respectively. The former chapter covers the various types of content, how to work with them, and how to administer content — with particular emphasis on two of the modules that are most applicable to content: Aggregator and Book. The illustration on page 152 does not include the "language" filter criterion mentioned on the next page. The biggest improvement that could be made to this chapter, would be for the author to more frequently specify how in the Drupal menu system the reader can go to the administrative section under discussion — similar to site breadcrumbs. Currently, the reader has to skip back, sometimes several pages, just to discover the steps needed to go to the specific Drupal section. In the subsequent chapter, the author explores taxonomy, the Content Construction Kit (CCK), and handling content posting using HTML and PHP. But the illustration on page 216 is missing the URL filter; the multi-page summary of HTML should be replaced with a few references to quality online HTML guides; the initial HTML code on page 227 is missing from the screenshot; and the image file path on page 228 should not have the localhost hardcoded.

Chapter 8 discusses Drupal's user interface and themes, at some length — in fact, too much length, as this is some of the book's most long-winded material. The CSS review section could be replaced with a few well-chosen links. It is stated that all five available themes have been enabled in the discussion, and yet that is not reflected in any of the screenshots. The penultimate chapter covers some advanced features — OpenID, actions, triggers, languages, localization, performance, caching, throttling, and JavaScript. Apropos of that last topic, the author several times advises the reader to "reload" a theme in order to implement any change to the .info file, but fails to explain how the reader can do the reload. For resolving this question, the book's index is characteristically unhelpful. The final chapter briefly explores Drupal site backup, task scheduling, and other site maintenance issues. The section on the Path and Pathauto modules should be combined with Chapter 4's section on clean URLs. The appendix explains how to deploy a site, and thus should have been located at the beginning of the last chapter.

Overall, the book accomplishes most of which it sets out to achieve. It provides a generous amount of information about Drupal, and discusses the material at an even pace that should not overwhelm even the most inexperienced programmer. Also, the book is packed with screenshots and other illustrations, so the reader can see the pages where they would make changes, and also see the effects. Nonetheless, readers will get even more out of it if they follow along and make the changes in a sample Drupal installation.

Despite the book's merits, it still has some areas of weakness. They include, as alluded to earlier, the index, which is missing some key topics, such as views and clean URLs, to mention only two.

In various places throughout the book, the writing could be markedly improved. Many of the sentences are awkwardly constructed, and consequently more difficult to understand at first glance. This is especially true in the first chapter, which has more high-level description and less technical detail. In addition, many of the sentences are run on, exacerbated by a lack of commas, which would alert the reader when to pause within the sentences. Dashes are frequently used where semicolons are called for. In some instances, new terms are incorrectly put in title case (e.g. on page 8). The terms "which" and "that" are sometimes interchanged incorrectly, as are "that" instead of "who" (e.g., page 126).

In general, the book is too wordy — on a large scale (chapter summaries, and entire paragraphs, that could be excised), and on a small scale (unneeded phrases here and there, such as "hopefully like contributing meaningfully" on page 34). The discussions, while friendly, could certainly use some tightening up and correction. Readers can do without the imagined musings of a Web server and a Google bot. In the aforesaid article on the Drupal site, the author notes, "...I have cut out quite a bit of the old text and trimmed that which remained..." Further cutting and trimming needs to be done.

Like most programming books nowadays, this one contains numerous errata: "DevelopmentEnvironment" (page i), "openID" (page 3), "Javascript" (ditto), "little to now experience" (page 4),....and many many more.

Some of the phrasing in the book is a bit awkward; for instance: "sell it on as" (page 28), "Meg" (for MB; page 35), "before last again" (page 84), and "remit" (presumably to mean boundaries; pages 116 and 117). There are some inconsistencies, such as on page 4, where, in the same CSS rule, we see both "#FF0000" and "#aaa." There are countless compound adjectives lacking hyphens (too many to catalog here). Finally, there are too many exclamation marks that serve no purpose.

This is the first book I have ever seen — and I hope the last — for which the title is never written in title case, but instead in sentence case. This may be of no consequence on the book's title page, where the nature of the title is obvious. But it becomes quite misleading when incorporated into a regular sentence, such as in the second paragraph on page 2, which causes the reader to initially conclude that the author is talking about the process of "Building powerful and robust websites..." Only later does it become clear that the author is not discussing any such building process, but rather the book itself.

Yet aside from these blemishes, the book does an excellent job of covering all the important topics that would be of interest to beginning and intermediate Drupal programmers. The author clearly has a genuine passion for Drupal, and frequently encourages readers to contribute to the Drupal community and its growing body of knowledge. Building Powerful and Robust Websites With Drupal 6 is a comprehensive, approachable, and valuable guide to making the most of Drupal — easily recommendable.

Michael J. Ross is a Web developer, writer, and freelance editor.

You can purchase Building Powerful and Robust Websites With Drupal 6 from Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
This discussion has been archived. No new comments can be posted.

Building Powerful and Robust Websites With Drupal 6

Comments Filter:
  • by Anonymous Coward on Wednesday April 30, 2008 @01:31PM (#23253712)
    Drupal is a great tool if you want to do what Drupal already does and slap a new coat of paint on it, pretending it's a whole new look and feel.

    You can move modules from one column to another to another to the footer. You can plug in any of a large variety of different modules and have them do exactly what they were designed for. You can make the blue bits a different color and up font sizes on your headers with awesome power.

    For the vast majority of sites, where true design and functionality customization isn't really key, it's an awesome tool and all the better for being free. If a PTA wants a site up, a local sports team needs something, even an engineering company that doesn't care much about design and just needs an informational website, it's great at doing that and doing it very quickly.

    The problem is, the moment you make the mistake of thinking you're going to add fields to modules, apply true custom skins to them, rearrange their content, etc. on top of an already largely built framework, it very quickly falls apart. You get two choices at that point: add on systems that kinda sorta give you some of what you need but still leave you limited or hacking in to the source code that's really not built with that kind of customization in mind.

    In short: It's a great system so long as you use it for what it's good for. Make the mistake of thinking you can just add a few tweaks beyond that and build something outside of its realm and you open yourself up for a whole world of hurt.

    Sorry about the AC - given I work with Drupal as one of several CMSs, professionally, it's not wise to be seen to be bashing a tool you [selectively] sell.
  • by jimjamjoh (207342) on Wednesday April 30, 2008 @01:55PM (#23253972)
    I've deployed a few websites using Drupal, and it's great once you understand its framework, the interaction of "modules" and "themes", the concept of a objects within drupal (nodes, users, etc), its permissions scheme. But that's a huge uphill climb for anyone other than a hacker.

    I will say that I was able to configure one fairly customized blog using freely available modules and without touching a line of PHP code, which was nice.

    However, if you want to customize the behavior of the CMS at all, you really have to start digging into the core, and breaking a few things.

    This is why my current website is still Drupal 5.3, and why I don't see myself migrating anytime soon.
  • It All Depends... (Score:2, Interesting)

    by BigMTBrain (1094379) on Wednesday April 30, 2008 @02:00PM (#23254054)
    ...on the needs of your project. I spent months with Drupal, tracking the boards, reading the docs, listening to many podcast series. But I came away feeling that, despite its many features and modules, it's quite kludgey. I've also looked at Joomla and give it great marks for also being powerful and pretty, if limiting for some tasks. Lower-level MVC frameworks such as CakePHP, Rails, etc. are good for when you would like to manage the CMS side and let the framework manage the infrastructure. Zend Framework is my choice for its extensive capabilities while not forcing you into any particular paradigm. I'm sure that this and other posts will cause a "Battle of the Frameworks". So, I will say again that it all depends on the needs of your project. All frameworks and all CMSs have their merits. I was just putting forth my opinion in light of my particular development needs.
  • I'm kind of a PHP and Drupal bozo, although I have contributed some patches to some modules and so on. Mostly I complain, and file bug reports against modules, many of which I must admit are significantly unpolished. On the other hand, I have literally dozens of modules installed on my site now and have come to terms with pretty much all of them. I'd say the stickiest stuff for me so far is project and project_release. It was really designed for use on and it's changing slowly, at least to my perception.

    Let me tell you what I think the GP is talking about. Modules are currently not themed through any kind of centralized system. They can alter the document head and insert an include for a CSS file, which is what most of them do. Unfortunately there's no standardization of what types of CSS classes et cetera that they use. Some modules are extremely poorly designed from a re-theming standpoint, and I will go ahead and run out and pick on the amazontools module, which provides Amazon Associate Tools. I'm on Drupal 5 because a lot of modules haven't been ported to Drupal 6 yet, and I use a lot of modules :) A replacement is coming for D6 and the API is there already (module "amazon" as opposed to "amazontools") but I haven't waded into those waters yet. If I can, I may avoid the whole thing until D7, which is getting a database API overhaul, an image API overhaul, and a bunch of new theming stuff.

    My understanding is that there is more facility in D6 for modules to play nicely in the theming department, but again, I haven't looked into it. Perhaps someone will explain somewhere.

    Anyway, I have my own patch against the amazontools module which provides the missing CSS and some other options (about where amazon related links are displayed, I've submitted it for review) and I'm DEFINITELY no PHP god, so it is possible. Drupal makes a lot of things pretty easy, which is the only reason I've fixed any bugs in anyone's modules, or been able to add functionality.

    By the way, I've actually had pretty good luck adding fields to node types produced by other modules. Where I've actually had the most problem is in upgrades. A lot of module developers have the attitude that if there is a problem with the upgrade process that is documented in the readme, it's OK. But Drupal has an upgrade system for a reason, and asking users to do things manually is never reasonable. There's no way to know which maintainers are responsible and which aren't, and some modules and their maintainers are both precisely the type of representative of their type that you want to deal with. I'm not trying to say that Drupal is amateur hour all around, in fact I think it's really amazing, and I believe that it is both easier to deal with and more full-featured than almost any of the alternatives. The fact that the majority of Drupal sites look the same in no way detracts from this fact. And since most modules pretty much use drupal's functions to produce their output in most cases (e.g. lists, menus, et cetera) if you produce your own theme function for this purpose, which is done at the theme/template level, you do end up changing the appearance of most modules.

    What I want to know is, is anything else out there actually better? I looked at Joomla and Wordpress and other goodies and Drupal was my choice by a very large margin.

  • by _Sharp'r_ (649297) <> on Wednesday April 30, 2008 @02:21PM (#23254442) Homepage Journal
    Typically, those of us using Drupal for a small business site paid the learning curve a long time ago and don't have to relearn it while doing several more small business sites each month. You can even create installation profiles now that automate setting up the modules and configs that you prefer for a new type of site.

    The biggest work for a new site usually ends up being creating a custom theme to match a designer's graphics and layout and a couple of custom little things a particular site owner wants to have.

    However, if you are talking about someone new to Drupal that only plans on ever doing one small site, then yeah, the learning curve is probably a bit high. For a single large site with multiple ongoing developers, the built-in modularity probably has more advantages then the curve to learn how that works has disadvantages, which is why a lot of large companies are starting to use Drupal for their sites.

    Drupal's a great dynamic web application framework, as well as being being a really complicated blog-publishing tool. Don't get me started on setting up forums....
  • by eh2o (471262) on Wednesday April 30, 2008 @03:03PM (#23255254)
    In my estimation Drupal has serious design flaws from the ground up. Beginning with ignorance of major programming paradigms that make for secure and scalable web services (e.g. model-view-controller), and what amounts to criminal negligence in the design of a basic hook and trigger system. When I first saw the "weight" feature in Drupal I immediately got a whiff of bad code-smell... turns out that bad code runs all the way to the core. The core developers also have developed their own private terminology (modules, themes, views, blocks...) that is extremely jargon-heavy and at best vague and not in agreement with standard terminology, at worst inconsistent with itself (e.g. category vs taxonomy vs vocabulary).

    Just about every part of Drupal core and its modules suffers from a disease called "good enough for my site" where the developer stopped building abstractions exactly at the point where his/her particular requirement was satisfied. If that is also good enough for your site, consider yourself lucky.

    Drupal gets tagging wrong by leaving out the semantic predicate from the RDF triple--or what I call loosely "Web 1.1". As a result all sorts of interesting ways of structuring information and workflow are impossible. Some core modules are allowed to abuse the tagging system for alternative purposes (forum). Its implementation of tagging keeps abrest with current buzzwords (e.g. "tag cloud") but is a nightmare for actual information repositories that span organizational operations and materials.

    There is a serious case of TIMTOWTDI, but not in a good way, with over 1500 available modules in contrib, leaving the administrator to solve a giant matrix of modules X,Y,Z providing multiple variants on the same feature, each with random and weird limitations, incompatibilities, and serious worries about future compatibility and module lifespan. When I say matrix I'm not kidding--I have literally had to resort to tabulating information in spreadsheets to work out which module to use.

    Drupal is also a fast-moving target. There is a major version release approximately once per year, and active core maintenance only covers the latest two versions (and the situation may be much worse for some contrib modules). This works out to a product lifecycle of two years for any Drupal site. Code customization is cited as the #1 reason for sites to not upgrade, which means you are looking at rewriting all of your customizations every two years. For any large scale site, customization is basically required because you will find all sorts of things in modules and the core that need changing (see "good enough for my site"), but can't be patched into the mainline. Compare that to something like Ubuntu-LTS which has a lifecycle of 5 years, and an upgrade process that is significantly easier than a core drupal upgrade. Just to keep this post on-topic, this implies that the book mentioned in the review will start heading to obsolescence in about 10 months.

    Nonetheless Drupal easily wins over more "correct" CMFs (e.g. Zope/Plone) simply because it is operational and feature-packed out of the box, and the sheer volume of active developers outweighs the rather low quality code that is produced. AFAIK there is nothing better, though I certainly wish there was. My long-term future prediction is that Google will eventually have something that rivals Drupal and runs on the App Engine--but given their rather conservative front-end development schedule, it will probably take some time.

    YMMV. Feel free to contradict. :)
  • by MalusCaelestis (172079) on Wednesday April 30, 2008 @03:06PM (#23255318) Homepage
    I whole-heartedly disagree with your comments about extending Drupal beyond its core. Admittedly if you try using Drupal without installing any modules you'll get pretty limited functionality. If you want something to work differently, you can install one of the thousands (yes, thousands) of contributed modules or write your own using Drupal's API (which is actually pretty good, and it got even better in Drupal 6).

    For theming, you can use a stock theme (like the default Garland), you can grab one of many contributed themes, or you can create your own (from scratch or using an existing theme as a starting point). Drupal sites don't have to look like Drupal the same way WordPress sites don't have to look like WordPress.

    Just like any other system, Drupal is only as customizable as the amount of work you're willing to put into it. A lot of WordPress sites out there use stock Kubrick, just as many Drupal sites use stock Garland. But a lot of people choose to customize their sites by creating custom themes and writing custom code (or using freely available modules).

    Want some examples of sites that use Drupal that look nothing like your basic Drupal install and have plenty of unique functionality? Have a look at Popular Science []*, FastCompany [], or MTV UK [].

    * Disclaimer: I work for the company [] that built PopSci's new site and was one of the developers that worked on the site.
  • by cavemanf16 (303184) on Wednesday April 30, 2008 @03:19PM (#23255544) Homepage Journal
    I have actually been impressed by the Drupal forum support for web developers and admins doing what you describe with handling multiple sites and domains under one "Drupal install umbrella" or similar types of quick roll-outs for small businesses. I've considered doing this with my install for a couple of other sites I want to build, but I haven't tried to tackle doing so just yet.

    And yes, I was saying it would seem too much of a learning curve for the original poster to work through setting up Drupal for the one small business site only because a small business typically is more interested in having a Yellow Pages ad on the Internet than a full-featured community type site - which is where Drupal excels, IMO. Sure, Drupal can be used as a simple ad brochure type site, but that could quite possibly be overkill if you're only dealing with only one small business site.

    I was hoping this book review would have been a rave review for the additional insights about how to do some of the more esoteric stuff with Drupal, but it sounds like it was written poorly and not focused on information for the experienced web developer. Too bad, because I'm struggling right now with how to map AND to the same Drupal site without having cookies and nodes get all jacked up with mod_rewrite and other hosting nuances.
  • by Electrawn (321224) <electrawn AT yahoo DOT com> on Wednesday April 30, 2008 @04:43PM (#23256786) Homepage
    How can I build a corporate website in Drupal 6 if LDAP ISN'T READY FOR 6? Active Directory, OpenLDAP, Fedora Server....nada.

    Big ball drop here...
  • by nostriluu (138310) on Wednesday April 30, 2008 @04:44PM (#23256802) Homepage
    I wish all these web systems hadn't abducted the term CMS. It used to mean something that provided very fine grained control for different types of "enterprise" (in the truest meaning of the word - big organizations with heterogeneous systems and requirements) uses. Since these Web CMSs came along the term has been significantly diluted.

    Compare the feature set of Drupal to something like Alfresco for anything past Web based content - polls and blog posts - and you'll see what I mean (Dries, the founder of Drupal, admitted this).

    Anyway, I used Drupal for some projects at version 4.something. It's success is undeniable and many large sites are using it, but I think if you're not a core developer and need anything outside of what the core provides, you're in for a world of sorrow and pain, aka hacks and patches and blatant disregard. Among other things, PHP just isn't a good language to develop a large stable API in, and Drupal's systems of "hooks" just makes things all the more confusing.

    The fact that the core developers intentionally disregard compatibility between even point releases means most modules and customizations get orphaned quickly.

    I've since moved on to Java based systems, it's not for every use, but there are plenty of high quality mid level libraries that give you a good mix of control and re-use, and at least I can tell if something is outright broken after a release, know if a function is dealing with the right kind of data, and do refactoring. As well, the community is often more professional, though there is certainly a lot more up front learning and design required.

  • by nostriluu (138310) on Wednesday April 30, 2008 @05:27PM (#23257240) Homepage
    Hmm? Alfresco is totally Open Source as far as I know, with commercial support options. Another alternative is Jahia, though some of the more important bits are closed.

    But in my case, since my app wasn't mainly a CMS, I ended up going with a collection of about 30 open source Java libraries which I find quite nice. Instead of hoping Drupal would do what I want and hacking it (in the bad sense of the word) in the meantime, it gives a lot of control, and I get very fine grained best of breed approaches to each problem.

    I'm afraid what I'm working on doesn't really relate to general CMS requirements, though I'd be interested in a focus on the best solution. The fact is many "enterprise" CMSs are very heavy, and that's why organizations go with solutions like Drupal, since it's simple and self contained.

What this country needs is a dime that will buy a good five-cent bagel.