Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
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 amazon.com. 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:
  • In a related development to a story posted eariler today [slashdot.org] Taco has bought copies for the entire /. dev team.
    • In a related development to a story posted eariler today [slashdot.org] Taco has bought copies for the entire /. dev team.
      Later that day, Taco also bought copies for all current Slashdot subscribers with good or better karma affected by the outage. Mr. Morgan Greywolf was quoted as saying "Wow! That was really, really nice of you, Rob! You are wayyy coool, Taco!!!!"
    • I'm a writer... previously published a decade or so ago, and now polishing my skills once more to re-enter the market.

      Michael J. Ross would be a perfect editor for me; he's ruthless and cuts right to the problems in a chunk of prose. However, judging by this article, I would pay a large sum of money to ensure he never reviewed my book.

      If he has an overall favorable opinion, he should allow that to be the tone, with his reservations being an undertone, suggestions for improvement, and a notice to the reader
  • I tried Joomla and mambo once and was somewhat impressed. may be Drupal is better, but is it? How easy is its installation? What advantages does it have over the other two? A slashdotter wants to know.
    • Re: (Score:2, Insightful)

      I tried Hoojooboo, Tookatakkatukka and Whatsits and wasn't impressed by their names either.

      Seriously though I tried Drupal and it's installation process was fairly painless and the interface was nice. I just prefer to code my own sites rather than hoping that somebody else will add a feature that I want. Yes I know it's open source, but going through somebody else's code can take a long time and when you have deadlines to meet time is a precious commodity.
      • I just prefer to code my own sites rather than hoping that somebody else will add a feature that I want. Yes I know it's open source, but going through somebody else's code can take a long time and when you have deadlines to meet time is a precious commodity.

        I've noticed a phenomenon lately where people are starting to think of a CMS as a "framework" for building out the functionality they need in a website. I personally think this is very misguided. If you're OK with off-the-shelf functionality (perhaps w

        • by Mouse42 ( 765369 ) on Wednesday April 30, 2008 @03:25PM (#23255646)

          Hacking a bunch of new and modified functionality it a CMS like Drupal is a PITA.

          With Drupal's modular framework, and abstracted theme layer, it makes it much less of a PITA to add new and modified functionality.
        • Re:Joomla/Mambo yes? (Score:5, Informative)

          by -noefordeg- ( 697342 ) on Wednesday April 30, 2008 @04:40PM (#23256758)
          Well, Drupal -IS- a framework, and to this date by far the best framework I have worked with.
          I'm guessing here that you have never looked at Drupal and the way it is built? Your last sentence give you away. "Hacking" Drupal is something which is very very very rarely needed. After 50 Drupal sites we still have not had the need to to "hack Drupal" - sites which some you really could not tell were running Drupal, others are large e-commerce sites and some just plain CMSs.

          The GP here sounds clueless. If you want to meet deadlines, use something like Drupal.
          I've coded frameworks and CMS/E-commerce systems from scratch. I've used Mambo, WordPress and some frameworks. Been into OsCommerce, which was my worst experience with any system - hands down.
          The company I'm a part of run ~20 onlines stores (from some very large to rather small) and about 70 other CMS/company sites (some large). And right now we are porting everything to Drupal / UberCart - www.ubercart.org (best commerce extension for Drupal).
          Just hearing someone mention "coding my own system" makes me shudder. Either they are totally clueless or fresh out of school. There is no other excuse. Really!

          There is absolutely no way one person or a small company can compete with a system like Drupal. You simply don't have enough time and resources to code something with as many bells and whistles, supporting new standards, and with such an API ad Drupal has. The API is to die for. The modules, and here we ARE talking about real stand alone - easy to install - no messing up other code/core - modules, are just "kick ass". Just look at the available modules for Drupal.

          Axed this from BuisnessWeek:
          "(Drupal) which is used by Sony BMG Music, Warner Music Group (WMG), Forbes, The Onion, Harvard University, Time Warner's (TWX) AOL, Amnesty International, and more than 250,000 other companies to manage their Web sites."

          A lot of government and educational sites in my country are being "upgraded" to Drupal.

          For anyone wanting to have a look at the technical aspects of Drupal: http://api.drupal.org/ [drupal.org]
        • by yabos ( 719499 )
          I ported our website over to Drupal in about a day's time without really having much knowledge of creating my own themes using it. It's a simple website with only about 10 pages but I wanted the ability to have blog like functionality for posting news stories without having to manually edit all the php files or hacking something else together. It wasn't all that hard in the end and for most websites I can't think of much you couldn't do with it. There's even e-commerce plugins apparently although I don't
    • Roll up, roll up, come and get your tickets for Joomla vs Drupal!

      It's like mySQL vs Postgres 2.0!!!! With an i in front!!!!
    • I ran a site using Mambo/Joomla for a couple years and have moved to Drupal 5.x and now 6.x

      Ease of installation is similar - with both projects it is basically "create a database and user" then run a php script

      I'm "familiar" with php (but by no means an expert - so in depth comparisons of system architecture is beyond me) - Drupal just seems to run "better" (i.e. faster on the same hardware) than Joomla for whatever reason

      Of course this is just my opinion ;-)

    • by LWATCDR ( 28044 )
      I think Joomla/Mambo is just a little easier to install but why is that a big deal with a CMS? Installing something like a CMS is such a small part of running a website that it is one of the things I worry about the least. Security, flexibility, speed, and ease of management all seem more important than how easy it is to install.
    • I was able to install Drupal and I never had any experience whatsoever installing a CMS over FTP.

      I used this screencast [drupal.org] and it was a breeze.
    • Joomla and Mambo are crap. Drupal is okay, but bloated. I prefer ExpressionEngine. It's fast, feature-rich, and elegant. For a Joomla->EE migration on a small-medium newsletter-style site (moving from flat articles to a nice categorization system, etc), it took about 2 weeks to get up to speed on EE and another week to bang out the templates. The sticking points came from their data migration team not following directions (a direct db->db migration wasn't feasible).
  • If developer loyalty is any measure of the present and future success of a (product in a category), then Brand X should be considered a standout among other (products in a category).

    ...because the evidence that Drupal is developer-loyalty-producing is what?

    But most developers would prefer learning XXX from a book...

    Really? I'm a developer and I haven't touched a tech book since I graduated college 10 years ago. Welcome to web, folks - books like this are obsolete.

    • If developer loyalty is any measure of the present and future success of a (product in a category), then Brand X should be considered a standout among other (products in a category).

      ...because the evidence that Drupal is developer-loyalty-producing is what?

      But most developers would prefer learning XXX from a book...

      Really? I'm a developer and I haven't touched a tech book since I graduated college 10 years ago. Welcome to web, folks - books like this are obsolete.

      and since i enjoy learning from books and dislike trying to put together a coherent picture from snippets googled from here and there, that would make me, umm, obsolete?

      thank god for that - gimme my retirement and free gubment cheese

      • by Amouth ( 879122 )
        this is why we use ebooks.. i havn't touched a real one in a long time (except to move my wifes).. personaly.. ebooks are a wonderful thing
        • except to move my wifes
          The plural's irregular; wives - like knives.
          • There is no evidence he lives in Utah...Or Texas apparently.

            But as Strunk and White would say, "Form the possessive by adding 's." Without the apostrophe, the parent post is correct; it's an attempt at a plural form.
            • by Amouth ( 879122 )
              opps.. missing a ' in that.. i only have one wife.. and i doubt she would agree to having another..
          • by Gilmoure ( 18428 )
            Wives can cut you deeper than knives. Harder to heal up after, too.
    • I'm not sure about this. I'm just entry level, but I just bought a book to learn PHP. Could it be the difference between a developer who is established and just needs to pick up a few new things here and there, and someone who is less established and needs to learn entire systems?

      I for one find that, so long as I am lacking a dual monitor system, it is infinitely easier for me to follow along in a book while typing up sample code than it is to change between multiple windows/desktops.
    • books are not obsolete. I was flying back to Dallas when American cancelled my flight, cancelled my rebooked flight, and then cancelled that.
      3 days late, i got home.

      I had 3 hard copy books with me and that kept me busy.

      so yes, the web is great, but not if you are stuck w/o a computer or web access.
    • It's hard to read on the web whilst on the throne.
    • Yeah buddy, whatever.

      Honestly, why people that seem somewhat intelligent have this idiotic idea that their anecdotal evidence is proof of anything?
  • It sounds way too much like Ru Paul [wikipedia.org]
  • I looked at Drupal and Joomal and found sites powered by both of them to be lacking for my needs. Right now I'm in the initial stages of transitioning a prominent not-for-profit site I administer to Expression Engine, which seems to be nicer than anything else out there than any CMS I have looked at. Of course, it isn't free like many of the alternatives, but it seems to deliver exactly what I want in terms of functionality, visual appeal and extensibility.
    • Do you mind sharing what it is that Drupal is missing?
    • by rmcd ( 53236 ) *
      If you're going to be hosting blogs be sure to look closely at the blogging component of Expression Engine. It's all I've seen of EE (I'm a user, not a developer), and it's got a horrendous user interface. I can't speak about the rest of EE.
      • The fields available in the blog-entry screen are highly customizable. If they aren't organized properly, yell at your EE admin. The flexibility of the blogging module is what makes EE awesome.
        • by rmcd ( 53236 ) *
          I've already yelled :-). Maybe you can help me make a more constructive request. I have several objections to the EE blogging module; perhaps these can be addressed:

          1. If you cut and paste from a word processor into the EE screen, you lose all links and formatting. Not true with Blogspot.

          2. Handling of graphics is just terrible. I couldn't figure out how to place a graphic where it should go so I posted in blogspot and our sysadmin ported my post over. The sysadmin apparently struggled for a while with grap
  • 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.
    • I'm interested in your experience with it thus far. I've just finished spending a few weeks looking at Joomla and am now working with Drupal. Any chance you would like to give more details?

      I've been thinking about teaming up drupal with a few other php/mysql products. My end goal is content management, contact management, community building and some social network stuff. I planned on writing my own modules if I couldn't find any that meet what I need. Would the willingness to do modules myself
      • by drinkypoo ( 153816 ) <drink@hyperlogos.org> on Wednesday April 30, 2008 @02:02PM (#23254098) Homepage Journal

        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 drupal.org 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 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 drinkypoo ( 153816 ) <drink@hyperlogos.org> on Wednesday April 30, 2008 @03:41PM (#23255906) Homepage Journal

            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.

            I guess there are two responses to this. The first is that I'm using "free tagging", and through a combination of the use of the Views module and the Tagadelic module it's possible to do most of the fancy schmancy dancy things that people like to do with tags. In D6 you can use the Drawing module to draw SVG associative navigation maps and cute stuff like that. There's also other ways of referencing nodes from other nodes (like the node reference module, whee.)

            The second is that the Category module, which has been known to eat sites for lunch, is supposed to be useful someday soon. :) The first answer is a better one, I think.

            Drupal allows multiple taxonomies (yeah okay, so sue 'em) and I have a grip of them on my site. The default system allows you to select which of them apply to which types of node.

            If Drupal has one major failing, IMO it is that it has too much structure. I would like to see everything be a node, and nodes be able to have any kind of data attached to them. Rather than having a user and a node about the user, the node that described the user's credentials would also display their profile information about them. I'm constantly dismayed by the input format system, too :)

            Er, and of course, if you're right about the low quality of code (I know jack diddly and can't make a judgement like that) that's pretty serious, too. It won't chase me off, though, at least not until I know more to do better on a scale useful for my site.

            AFAIK there is nothing better, though I certainly wish there was.

            Makes me feel better about using and recommending it, anyway :)

            • by eh2o ( 471262 )
              I have no problem recommending Drupal to people as long as I communicate to them how much work to expect for maintenance and customization beyond the default capabilities.

              For a lot of people it's just fine, and certainly something like Plone has a much steeper learning curve.
          • MVC has nothing to do with security and scalability (other than "separation of logic and presentation makes them both easier"). Drupal uses a separation of content and presentation sometimes called PAC [garfieldtech.com].

            Scalability has to do with intelligent caching, of which Drupal has plenty. Its pluggable cache system lets you use a database, flat files, or memcache for caching.

            Security has to do with how code is written and how many eyes are on it. Code is written according to Drupal's coding standards, and developer

            • by eh2o ( 471262 )
              Drupal is reasonably robust against XSS and injection attacks, unlike more than a few other PHP projects. Kudos for that. The security-announce list also keeps up to date with new problems, which are not too common, but every drupal admin had better be on it. I actually found an order-of-operations bug in the D5 input filter--not with security implications, but it did mess up the escaping of certain sequences. That is just to say that its not proven to be bug free.

              Security-wise my main complaint is abou
      • I use Drupal almost exclusively. I am able to make my sites look like almost anything I want and perform any function I have needed so far. Willingness to write or re-write modules does help occasionally. I have several websites so it makes sense for me to learn one system and use it on all my sites. The sites I have built range from small personal blogs to complicated shopping carts. It works for me.
    • 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.

      It's pretty easy to edit the CSS in the theme files and achieve whatever custom look you want. If you can do it on a static web page, you can get Drupal to output it. I'm in the process of converting a static website to Dr

      • It's pretty easy to edit the CSS in the theme files and achieve whatever custom look you want...
        Yes. That's what the AC poster said. And he also said that moving beyond COSMETIC tweeks, there are serious roadblocks. That's what he said.
    • Well, first of all, modules in Drupal are code plugins. The stuff you move from one side of the page to another is a "block". :-)

      Drupal is great for getting something out quickly, but yes, for any serious site you are going to be using numerous "contrib" modules (the add-on systems you mention). Drupal's architecture is built around letting add-on modules do the powerful stuff, while core is an engine to enable them to do powerful stuff.

      For instance, if you're building a complex site without the CCK and V
    • Re: (Score:3, Interesting)

      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 co
    • by yabos ( 719499 )
      I really think you are pretty wrong on the customization aspect. It's not that hard to build your own template including CSS for all the different built in chunks of html it puts out.
  • Hi,

    I was having a discussion not long ago with a colleague. I was proposing using Drupal has the framework for a web application. I've done it with a lot of success in other small projects.

    He objected that it was too big for what we needed. At the end, he agreed that we needed a framework. So he proposed zend. I know that zend can be used with Drupal to make modules [drupal.org].

    For me, building a Drupal module would make sense. The application is a big RSS aggregator. We could use drupal for user management, right mana
    • I've been thinking about a project along very similar lines. I've discussed it with others and have we have found ourselves looking at the same options.

      Some want to use django and build it from there. I'm leaning towards building what we need on top of Drupal. I set up Drupal on a test server and now I'm trying to get a good handle on the core and existing modules. Then when I know what I can do that way, I'd like to get started on my own modules.

      At the very least if you are all wet, you
      • by mhamel ( 314503 )
        User management and right management are two things that you'll almost always need. You can do it from scratch, it's not "that" complicated. But it always get more complicated with time. Let's say the user management:

        * You need to have automatic email handling for registration.
        * If you need single sign on.
        * You may need gotcha.
        * Then latter you discover that you needs groups and the administration interfaces that goes with it.
        * You need all those to interact with the permission system that you did put in pl
  • I've just spent the morning looking at CMSs, in preparation for moving our company website over, so this review is very timely for me. We have a fairly standard small business site, lots of static content, a number of reply forms, etc. We're not looking to build a community or anything like that, so I'm leaning towards something like CMS Made Simple. My question is, for a site like this, should I even bother moving to a CMS or stick to a straight html/CSS static site? It would be nice to have other people b
    • Re: (Score:2, Insightful)

      by mhamel ( 314503 )
      Just the update capabilities of a site like Drupal are worth it. Most little structures don't want to ask a web developer to add or modify small content for your a web site. It help giving the content ownership to the content producer. Without it, every modifications has to go through IT, which is too complicated.. mostly if it is a small company. A CMS will keep the site updated easily.

      If you don't want to invest time, just use an existing theme. If you want your own look, take the time to learn how to do
    • Initial learning curve would be way too much, and wouldn't serve a purpose if you don't plan on having a highly active community. For my personal "blog" I use Drupal 6, but I don't know that I would use something so fancy for a small business site if I were a web developer. Seems like more work than it's worth. (You can see what my Drupal site looks like in my homepage link)
      • Re: (Score:3, Interesting)

        by _Sharp'r_ ( 649297 )
        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
        • 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 caveserv.com AND adamstechconsultants.com/drupal to the same Drupal site without having cookies and nodes get all jacked up with mod_rewrite and other hosting nuances.
          • Too bad, because I'm struggling right now with how to map caveserv.com AND adamstechconsultants.com/drupal to the same Drupal site without having cookies and nodes get all jacked up with mod_rewrite and other hosting nuances.

            You can mod_rewrite one domain name to 301 to the other and just config stuff for the other, but you probably already knew that. It's still the simplest solution.

            You can also try making sites/caveserv.com a symbolic link to sites/adamstechconsultants.com (so all the other files undernea

      • >>>Initial learning curve would be way too much

        well, a high learning curve, sloping up quickly, means it is EASY to learn!
      • by b0bby ( 201198 )
        Yeah, I think Drupal might be overkill for us, CMS Made Simple seems more our speed. We'll be hiring designers to create the look of the new site, the real question is do I then stick with static pages or put our content into a CMS? A host like opensourcehost.com seems to have it all set to go, so hopefully between a good design team & a decent host my personal learning curve wouldn't have to be too bad...
        Nice pictures, by the way.
    • by cwgmpls ( 853876 )
      I don't understand why a small business wouldn't want community-like functions in their website. Don't you have any customers you would like a better relationship with? I think if you look into everything that a website can do for your company, you will realize that you do want a community site. And if you do want a community site, their is no better platform to build one in than Drupal.
      • by b0bby ( 201198 )
        In our industry, there are external sites we can integrate with for a community with lots of resources; we just need to decide if we're willing to pay the price to do that. If it's worth doing, that's the way we'd go rather than try to create something from scratch. So you're right, community functions are important, I just think that we can safely outsource their provision.
  • Yup. May be powerful and robust, but all the core is super heavy and not so easy to extend.

    Don't even talk about "Joomla" and "Mambo". They're a nightmare to maintain, and a royal pain in the ASS for building an SEO friendly site with friendly URL's that don't look like a matrix reloaded computer screenshot.

    Sigh.
    • Is Drupal's core really that hard to extend? I'm thinking about taking some stabs at parts of 5.7 for functionality I hope will appear in Drupal 7, by which time I might think it's worth it to make a transition from the modules I'm using to the modules that will be around by then - by which time I probably still won't have replacements for modules I'm using now with Drupal 5.

      I looked at other CMSes, and Drupal looked like about the easiest thing like it, I guess I was right. It actually IS pretty easy to g

    • Yup. May be powerful and robust, but all the core is super heavy and not so easy to extend.

      If you mean installing modules, I've found that to be pretty easy.

      If you mean writing modules... wel I've not done a lot of work there but I did not find it so hard to port a module written for Drupal 5.x to 6.x, and the API looks OK from what little I saw. Between setting up blocks right and using CSS well, you can customize a site pretty well.

      Don't even talk about "Joomla" and "Mambo". They're a nightmare to mainta
  • 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 reall
    • What do you think about the interface itself once you get things the way you want? If a hacker can get a site dialed in and working correctly, can someone without a lot of tech knowledge maintain and operate the site easily?
      • definitely. it very much "just works" once you get everything configured how you want it. i set up a blog with it for my fiance and she was able to publish content with ease. you can teach people how to create roles, specify permissions, create custom "content types", build views (the views module is an absolute must!!), etc.

        none of those things require any coding. but some of the specialized things i wanted to do (have "promotable" content, customize the display of content, create content without using
    • A steep learning curve means it is easy to learn.

      People mistakenly use the term to mean it is hard.
      • noted, thank you.
      • Not necessarily "mistakenly" but nowadays commonly referred to "visually" as in "climbing a steep slope". The majority of people reading the title of the post will interpret it as meaning that Drupal is relatively time-consuming and effortful to learn, even outside of the context of this thread. Words and phrases often creep in their meaning over time within a culture, often initiated by "mistaken" use. The "current" meaning (by majority rule) of "steep learning curve" in most circles and contexts, for al
    • by yelvington ( 8169 ) on Wednesday April 30, 2008 @02:59PM (#23255176) Homepage

      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.
      No, no, no. You do not hack the core. You extend by writing modules and/or overriding theme functions.

      If you have not learned to stay off the road to Drupal hell [nicklewis.org] you have much left to climb left on the Drupal learning curve. [buytaert.net]

  • To anyone considering Drupal for their project I simply say this: If you must use Drupal, do it yourself. All Drupal evangelists are coincidentally Drupal consultants. The CMS solution they pitch as being effortless will turn into what any software customization project is -- work. If you don't know Drupal, you'll either have to learn it or have to pay someone to do it. Also, don't look too deeply into its architecture unless you don't cry enough.
    • >>>All Drupal evangelists are coincidentally Drupal consultants

      And that makes it a cult?

      So what does that make scientology then?
    • Well, I preach Drupal, and I'm not making any money on it, although I could always go for some. The win for Drupal, I think, is that it does pretty much everything without all that much customization. I've developed my own full-custom templates (I'm not using one now though, because I've been too lazy to make one for 5.x) and it's not that hard - the standard for drupal themes is a php file-based system (phptemplate.) But then, I'm always willing to look at something else. I just haven't found anything that
  • It All Depends... (Score:2, Interesting)

    by BigMTBrain ( 1094379 )
    ...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 Frame
  • As an aside for those interested in how easy it is to setup or how much you can customize it. I setup this site for my last job at http://www.gwca.org/ [gwca.org] (its been a bit butchered since then so your mileage may vary) and it had a steep learning curve but was extremely powerful and very easy to customize.
  • I bought the book and wish I didn't. The book is more for folks who don't know PHP, CSS, HTML, etc.

    The Handbooks on the Drupal site are much better than the book. You can find the beginner's cookbook here...

    http://drupal.org/handbook/customization/tutorials/beginners-cookbook [drupal.org]

    And the tutorials here...

    http://drupal.org/handbook/customization/tutorials [drupal.org]

    Drupal is good for quick website development and comes with a ton of modules for added functionality. It's a good way to go if you know PHP or if

  • "Many of the sentences are awkwardly constructed, and consequently more difficult to understand at first glance."

    Back at ya.

    "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."

    The hilarious irony of your criticism of this author's writing style really made my day. Please clean up your own act before criticizing others.

  • Funny thing is: I don't like PHP. Many other programmers don't like PHP as well. But there's no CMS out there that comes near to some of the PHP CMS like MODx or Drupal. WTF? Is everybody else writing yet another hand-made CMS on his own, over and over again?
    • Plone [plone.org] maybe?

      Plone is a content management framework that works hand-in-hand and sits on top of Zope, a widely-used Open Source web application server and development system.

      [snip]

      Zope itself is written in Python, an easy-to-learn, widely-used and supported Open Source programming language. Python can be used to add new features to Plone, and used to understand or make changes to the way that Zope and Plone work.

    • Check out WebGUI

      http://www.plainblack.com/webgui [plainblack.com]
      • The only difference is that it's written in Perl; still; I like WebGUI as much as I like Drupal.

        I've always liked Coranto [coranto.org], also written in Perl but a lot more user-friendly & much smaller in footprint.

        cmsmatrix [cmsmatrix.org] is also coincidentially hosted by plainblack if my mind doesn't leave me now...
  • I'm using Drupal 6 to develop a site right now. I like it quite a bit, I like especially the ease of creating human friendly (SEO) URLs for each page, and also for the caching you can enable.

    But, one thing to note is that using Drupal 6 is harder than it should be right now because a number of the more interesting Drupal modules are still only for version 5.x, and you can't just load them in. If you really need a module check the dev notes as there may be patches to let it work with 6.x (as is true of the
  • 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.

    • We've extensively evaluated Alfresco as an ECM solution for our university (41,000 students, 2800 staff, 500,000 web pages across ~450 domains). As a content repository and document management solution it looks great, but its web content management capabilities are very basic and currently not ready for prime time in my opinion.

      For one thing there's no in-context editing, so content contributors need to be trained in an administrative interface that's often quite complex. You also can't nest templates easil
  • I used both during last years and I must say that APEX is much, much better if you want to design something nonstandard (i.e. missing in Drupal out of box). I wanted some menu items to be shown only to certain users in Drupal... arrrgh, what a problem doing a simple task! While authentication and authorization methods in APEX are easy to use and understand (and you can create your own authorization method and bind it to the page OR any element, be it tab on the page or button, or report, whatever -- if the

Computer programmers do it byte by byte.

Working...