Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Book Review: Pro Drupal 7 Development, Third Edition

samzenpus posted more than 3 years ago | from the read-all-about-it dept.

Book Reviews 74

Michael J. Ross writes "With the growing interest in Drupal as a platform for developing websites, the number of books devoted to this CMS has increased from a handful to now several dozen. Consequently, intermediate and advanced Drupal programmers may wonder which one of those books would be their best choice as a single resource for learning how to create custom Drupal modules and themes. Ever since its first edition in April 2007, the Pro Drupal Development series from Apress is more frequently cited as the best candidate than any other." Keep reading for the rest of Michael's review.In its third edition, Pro Drupal 7 Development is now helmed by Todd Tomlinson and John K. VanDyke, and again features a forward by Dries Buytaert, the founder and project lead of Drupal. This edition was published on 29 December 2010 under the ISBN 978-1430228387. The publisher offers a fairly sparse Web page for the book, containing a brief description, the source code used in the book, a page for errata (several reported), links to purchase both the print and electronic versions (oddly, with no bundle discount), and a section for author information, which currently has no entries. At 720 pages, it is the longest Drupal book on the market, as of this writing (and should remain so until the scheduled release of Wiley's Drupal 7 Bible). Yet Pro Drupal 7 Development is not terribly thick, probably because its paper appears to be thinner than that typically used for programming books. Although this allows the text on the other side of each page to show through slightly (and no doubt unintentionally), it generally does not pose a problem, but would have if a paper any thinner had been chosen.

The book's material is organized into 25 chapters and two appendices, covering numerous topics: Drupal infrastructure, including requisite Web technologies; module development basics; hooks, actions, and triggers; the menu, database, user, node, field, and theme systems; blocks; the form API; the filter system; searching and indexing content; file management; taxonomy and vocabularies; caching; sessions; jQuery; localization, internationalization, and content translation; XML-RPC; how to develop secure code and other best practices; site optimization; installation profiles; testing; Drupal database reference; and other resources. Given the sizable number of chapters and topics explored in this book, it would be impractical to attempt to provide any sort of full synopsis in this review. Instead we will focus more attention on those topics that will be of greater importance to Drupal developers (a phrase used to distinguish them from any Drupal site builders who do not create their own modules or modify existing ones).

The subject matter presented first — how to structure module code and make use of Drupal's hook system, as well as actions and triggers — is essential reading for anyone new to these topics (but presumably could be skipped by any veteran programmer familiar with them from earlier versions of Drupal). Most readers should find that there is sufficient information provided to understand the concepts and/or the code being presented, but there are a few exceptions: For instance, on page 22, the narrative refers to only a single node, but the code in annotate_node_load() suggests multiple nodes are being processed. Also, readers following along by implementing the example code, will likely be frustrated that the action "Beep multiple times" is not displayed in their own "Trigger: After saving new content" list box (page 42). Fortunately, these are the exceptions, because the authors present the ideas at a measured pace, with sufficient groundwork so readers will not become lost.

An understanding of Drupal's powerful hook system, is a necessary foundation for learning the concepts that form the heart of this book — namely, the menu, database, user, node, field, theme, block, and form systems (often referred to as the Drupal APIs). The presentation of the ideas is done in a methodical fashion, with plenty of example code and screenshots. Readers who patiently work their way through the material — particularly if they try to get the code working in their own Drupal environments, and perhaps even experiment with variations — will likely find it a time-consuming process, yet they will be richly rewarded for their efforts. The only blemishes are the several places in the text where there is a mismatch between the narrative and the code, or between the code and a screenshot. Several examples should suffice: The menufun_hello() function on page 67 is missing code for the two @from variables. Page 76 refers to a mysterious "second parameter, $b." The $items code on page 77 is close to what is in Drupal 6's user.module, but is nothing like Drupal 7's. Remarkably, "%index" appears in a section head (page 79) but nowhere in the text. The pager display code (on page 96) is missing "$result = $query->execute();." A "module named dbtest" (page 111) doesn't seem to exist.

The topics covered next in the book generally go beyond the Drupal APIs, and are much more diverse. Readers will learn how to filter user input, as well as how to allow users to search a site's content, upload files, and characterize nodes using terms from taxonomy vocabularies. Incidentally, the chapter on caching would have been better positioned just before the chapter on optimizing Drupal's performance, since the two areas are so closely related. Yet both are invaluable for minimizing the page load times for any substantial Drupal-based site. The authors show how, within Drupal modules, to utilize jQuery and XML-RPC. The chapter devoted to localization and translation — a subject growing in importance as sites go multilingual — is quite thorough.

The last five chapters of the book address topics that can help anyone become a better Drupal developer: code and form input security, programming best practices, Drupal site optimization, installation profiles, and testing techniques. Even though the authors provide a full chapter on Drupal programming best practices, there are similar nuggets of wisdom sprinkled throughout the other chapters — evidence of the authors' deep experience writing Drupal code, and seeing the pitfalls. The book's two appendices consist of a Drupal database reference, which describes all of the tables and their columns, and a summary of Drupal resources aside from the book, including user groups. The book concludes with an index that is missing some key concepts (e.g., permissions and roles), and would have been able to include more entries if the publisher had not chosen to use an unnecessarily large font and line height.

Each chapter concludes with a brief summary, and all of these summaries provide no value and should be dropped from any future editions. For each one of the items labeled "Note" (scattered throughout the book), if it repeats information mentioned in the text (some just a couple sentences earlier), then it should be excised; otherwise, the information should be folded into the text. The book's narrative could be improved in other ways: There are a number of instances where the authors refer to particular lines of code in the example code, and it would have been most convenient for the reader had line numbers been used. Module names are often incorrectly presented in all lowercase (e.g., page 13). Occasionally some phrases or acronyms should have been explained (or not used), such as "HA companies" (page xxix). On the plus side, the material is occasionally livened up with some welcome humor, such as the devilish functionality of "Evil Bob's Forum BonusPak" (page 14) and some equally devilish deadly pets (page 282). At first, readers may chuckle at the phrase "Drupal's legendary snappiness" (page 499), but evidently the authors were not being facetious.

The example code sprinkled throughout the chapters is especially helpful to the reader, and there are only a few places where the code does not match the narrative, or the code is incorrect in some other way (aside from those instances mentioned above): The text on page 14 neglected "annotate.admin.inc"; and in the listing for annotate.info, the "configure" path should not include "content/." In the discussion on paged display (on page 96), "clicking on 5 would take the visitor to rows" 41 through 50, and not "51 through 60." The code on pages 147 and 149 erroneously refers to "punchline" and a joke node type in job_node_access(). On page 355, field_tags is identified as field_geographic_location. The contents of the files in the downloadable source code do not always match what is seen in the book, starting with annotate.info (page 14) and annotate_admin_settings_submit() (page 20). Even worse, the source code for Chapters 3-6, 12, 13, 15-17, 19-22, 24, and 25 is missing completely.

There are numerous other, more simple errata: "-sites" (page 8), "an[d] installing" (9), "/q=node/3" (10; missing the '?'), "modules /" (17), "[the module] removes" (19), "hooks key" (45; should read "triggers key"), "beep_multiple_.beep_.action()" (49), "end" (55; should read "beginning"), "to [the] module" (61), curly quotes in code (63, 67, 190, etc.), "%user_uid_only_optional" (77), "function_menufun_menu()" (79), "product" (98; should read "produce"), "lower-case" (111), "users signature" (117), "[the] time" (118), "themeing" (153), "secondary" (190), "to and an" (308), "php", "class. the", and "apis" (all on page 323), and "pave" (409). At that point, I stopped recording the errata. Most if not all of these errors should have been spotted in the book's technical review process, assuming they were not introduced after the reviews were done.

For computer programming books, information presented outside of the narrative — such as figures and example source code — can either greatly enhance the reader's experience, or undermine it. In Pro Drupal 7 Development, the diagrams and screenshots are relatively few in number, yet are used effectively, with only a few errors: The caption for Figure 3-8 appears to be incorrect, as is the URL in Figure 4-5. Figure 5-1 contains an erroneous "$database". Table 17-1 is missing a row for uid 0. The screenshots in Figures 19-1 and 19-2 are quite fuzzy and difficult to read.

A few comments on the book's physical design and production are called for: In the review copy that the publisher kindly sent me, the first text block signature consists of only the first two leaves. As a consequence, that signature had almost no glue holding it into the binding, and had already started to separate from the binding. The production team should have anticipated this sort of problem; but it may have been a choice driven by pending changes to the title and/or copyright pages.

Fortunately, none of the above flaws are significant compared to the wealth of information provided by this book. Pro Drupal 7 Development clearly demonstrates why, in the minds of countless Drupal developers, this series is the gold standard for learning the inner workings of Drupal, and how to utilize them for building custom modules.

Michael J. Ross is a freelance website developer and writer.

You can purchase Pro Drupal 7 Development, Third Edition from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Sorry! There are no comments related to the filter you selected.

Drupal != Pro (2)

polyp2000 (444682) | more than 3 years ago | (#35201818)

Just my opinion, I wouldnt touch Drupal with a barge pole. Really nasty set of code. Still , if you are forced into using it without looking at other PHP frameworks such as Symfony then maybe this book will help you find your way around it.

Re:Drupal != Pro (0)

Foofoobar (318279) | more than 3 years ago | (#35202014)

Gotta second that. The homegrown ORM it has is not scalable in the least. It's many-to-many table creation creates like 8 TABLES for a relationship that only needs a bare minimum of 3. I've had to clean up Drupal builds so many times that I tell people never to use this if they plan to be doing business with their site or plan to ever scale it.

Re:Drupal != Pro (0)

Anonymous Coward | more than 3 years ago | (#35202112)

Even the most basic Drupal search for performance and scalability brings up case studies of massively scaled commercial sites and groups dedicated to bringing out the best performance. Try this with other frameworks and compare the results. "8 tables for a relationship that only need a minimimum of 3". No mention of what modules you were using, no mention of what you were trying to accomplish. Great trolling foo.

Re:Drupal != Pro (2)

theNAM666 (179776) | more than 3 years ago | (#35202154)

Eight? I've never seen that. Maybe there's an example, maybe you're pulling it out of your rear end.

A botched Drupal install by a non-pro is, of course, a botched install. I've seen plenty-- they range from beginners who didn't really know what they were doing (just like with PHP sites), to so-called "pros" who don't realize that the framework is very different and keep trying to do things "the old way."

I'm guessing you're the latter.

Yes, for some truly enterprise-class apps that require global data synchronizations between multiples points of presence, for instance, one can easily imagine scenarios where Drupal default db / table generation is not good enough-- in which case, anyone implementing it, should consider that and modify that layer. Yes, anyone can probably do better, if they architect that by hand.

The point is, it's a framework. The framework needs to generate data structures, on it's own, not manually. The framework needs to be relatively universal and portable and understandable, not a super-optimized, custom and thus harder-to-understand (if not obfuscated) solution.

For that, Drupal is pretty good. As in "the great is the enemy of the good." As in, perfection is something else, and searching for perfection, often blocks getting things "good" done in an effective, efficient manner.

Re:Drupal != Pro (2)

Foofoobar (318279) | more than 3 years ago | (#35202284)

Well if I am pulling it out of my rear end, its getting yanked along with most of Drupals shit stained code. And I am not kidding. I have seen HORRENDOUS stuff that Drupal trys to do with its 'nodes' and I'm speaking not only as a DBA but as one who uses Hibernate on a regular basis (ORM done right). For a many-to-many relationship, there should be only one additional joining table... no more. But Drupal makes a mess of the database and of joins and your queries end up being megalithic nightmares that only Cthulhu's sys admin could love.

I mean, bravo if you enjoy coding in this spaghetti coded mess but don't try to say it's better than an organized framework. Because you are kidding no one but yourself.

Re:Drupal != Pro (0)

Anonymous Coward | more than 3 years ago | (#35202540)

I bet you are nothing but a Joomla lover ;)

Re:Drupal != Pro (1)

cayenne8 (626475) | more than 3 years ago | (#35202562)

I'm wanting to play with this stuff...possibly FOR websites to generate a little extra $$ at home from my servers I'm putting together there.

I'd been eyeballing Drupal...

What would you and others recommend in its place? Why? Can you give solid examples/reasons why "X" would be better than Drupal....especially for a noob.

Re:Drupal != Pro (1)

Foofoobar (318279) | more than 3 years ago | (#35202592)

HONESTLY??? Groovy/Grails because its very easy to learn, has a ton of plugins, and integrates with Java. But if you are stuck in PHP I'd say Zend because most companies are looking for people who can develop in a framework and something that is extensible.

Re:Drupal != Pro (1)

cayenne8 (626475) | more than 3 years ago | (#35202690)

"HONESTLY??? Groovy/Grails because its very easy to learn, has a ton of plugins, and integrates with Java. But if you are stuck in PHP I'd say Zend because most companies are looking for people who can develop in a framework and something that is extensible."

Thank you.

I've not played much with java, but I have done some playing around with PHP (generating some rough pages connected to Oracle...coded by hand back in the day). I might could go a bit quicker with the Zend then.

But I'll install all you suggested and see what comes about the easiest as I start to jump in and mess with it. I don't need anything terribly complex...but the more turnkey it is..the better.

Re:Drupal != Pro (1)

Compaqt (1758360) | more than 3 years ago | (#35209108)

If you're just going to throw up some content with ads for a few $$, you'd be better advised to go with WordPress.

WordPress out of the box is far more featureful than Drupal out-of-box.

Granted, you can add (then configure) a huge bunch of Drupal modules to get the same functionality, but your goal is just adding content, right?

Oh, and WordPress handles both blog entries (chronological content), and pages at a specified URL (like /about, /contact, etc.)

And WP has far more (and nicer) themes (free and paid) than Drupal.

WordPress is better, easier, lighter than Drupal:
Why Drupal Devs Should Fear WordPress [chapterthree.com]

WordPress is Better, Drupal Devs Take Note [drupal.org]

Re:Drupal != Pro (1)

Anonymous Coward | more than 3 years ago | (#35202334)

Drupal is pretty good. As in "the great is the enemy of the good."

An excuse our in-house Drupal guy makes all the time. We can't do that simple thing cause Drupal makes it impossibly difficult and/or painful.

I can't justify using pretty good bloated software with an insane architecture. There are many better options out there in a variety of web programming languages. Drupal is held aloft by its fan-boy community and its low bar to entry. Entry, not mastery. I'm very impressed when someone claims they really know the inner workings of Drupal. Impressed, but sympathetic.

I find people who love Drupal haven't used anything else, or what they did use was so bad you can't blame them for buying into Big D.

Re:Drupal != Pro (2)

theNAM666 (179776) | more than 3 years ago | (#35202792)

I doubt your "in house Drupal guy" is an expert of any kind, especially if he's telling you that. You can *of course* do anything, and the idea that "Drupal makes it impossibly difficult or painful" is just silly. It's a resource question.

You evidently have some negative experiences that you're projecting on Drupal. Fine. Since you're a AC, I'm going to assume for now, you don't have enough experience to really make the judgments you're making. Drupal's architecture is, somewhat intentionally, parallel to an OS architecture. You might as well call Linux an "insane architecture"-- you'd have as much validity.

Re:Drupal != Pro (1)

Compaqt (1758360) | more than 3 years ago | (#35208962)

>You can *of course* do anything

Well, there's a difference between you *can* do anything, and the ability to do it within time/money/server resources limits.

It's like saying, "Could you program a Visio clone on Linux?" The answer is both yes and no.

Re:Drupal != Pro (-1)

Anonymous Coward | more than 3 years ago | (#35202582)

A botched Drupal install by a non-pro is, of course, a botched install.

'Drupal Pro' is an oxymoron to everyone except the 'Drupal Pros' themselves and the people who have no idea how to build web sites that hire them as consultants. Someday you guys will get it.

Re:Drupal != Pro (1)

kc8jhs (746030) | more than 3 years ago | (#35202930)

Considering that Drupal doesn't have an ORM, doesn't claim to, and probably won't ever have an ORM in the sense you run into with most MVC frameworks, I have no idea what you are talking about.

Re:Drupal != Pro (1)

Foofoobar (318279) | more than 3 years ago | (#35203784)

Um... what the hell do you call 'nodes'?? They are Drupal's 'Object Relational Mapping' for database tables. Hence 'ORM'... duh.

Re:Drupal != Pro (3, Informative)

kc8jhs (746030) | more than 3 years ago | (#35204070)

I have to assume that you are trolling, or that you haven't really used Drupal.

I've never seen anyone claim that the node system is an ORM, because it isn't. It's just a table(s) in a database, and a module that provides code to manipulate that data, but is not object oriented, nor is it mapped in anyway that resembles an ORM. The mapping to properties->columns is not even, and there is no ability to relate other nodes or objects based on the presence of another table, all of those operations are left as an exercise for the developer needing to implement it. This is why the other statement about 8 tables just to express the relationship between two objects makes no sense.

Re:Drupal != Pro (1)

Foofoobar (318279) | more than 3 years ago | (#35205720)

You obviously lack the understanding of what ORM is as you basically just described it in denying that Drupal even has it.

Re:Drupal != Pro (1)

kc8jhs (746030) | more than 3 years ago | (#35216036)

Reading and writing to a database does not make an ORM.

Re:Drupal != Pro (1)

Ice Station Zebra (18124) | more than 3 years ago | (#35203020)

Guess you've never really developed anything beyond a "hello world" level application or else your tables are really really wide. In either case, I'll take Drupal's well developed DB structure to your kitchen sink design any day.

Re:Drupal != Pro (1)

theNAM666 (179776) | more than 3 years ago | (#35203208)

Bet he avoids wide tables by serializing the data-- ROT13ing it first.

I personally just drop in custom code when there are performance issues-- and the client is paying. But hey, that's me. Other people like to make kitchen sinks.

Re:Drupal != Pro (2)

theNAM666 (179776) | more than 3 years ago | (#35202074)

You know, I hear this again and again. Mostly from people who don't seem to have invested much time in Drupal, or who seem stuck on older models for managing web content.

Drupal is a FOSS project. Is it perfect? No. Does it have many advantages over a "PHP framework" such as Symfony? Yes, primarily in the scale and size of the contributing community, and the ability of that community to work along roadmaps to better solutions.

Is most of the code "contributed" by volunteers, often working under practical goals and limitations? Yes. Are there challenges with managing code quality control and practicality vs. "perfection" in such a community project? Yes, of course.

Are there a lot of naysayers in this room? Probably.

Re:Drupal != Pro (1)

Foofoobar (318279) | more than 3 years ago | (#35202166)

Actually, an MVC framework such as Symfony, Zend, Codeigniter, Phpulse, Cake, etc all can scale far better, and has faster development times. There is no trying to figure out how to 'code around' Drupal. Code is properly separated and follows coding standards. Sure you have libraries that work for Drupal but framework have libraries that work for EVERYTHING... not just Drupal and the code can fairly easily be switched from framework to framework. Lets see you move Drupal code to Codeigniter or Zend.

Re:Drupal != Pro (1)

theNAM666 (179776) | more than 3 years ago | (#35202894)

Cake? Ancient MVC? you've got to be kidding me. You're evidently looking at matters from a developer's perspective, and a very limited one at that.

In the real world, real people producing actual applications that are used by others, produce relative dreck with those "frameworks." Cake sites tend to be a bunch of random UIX nighmares, with boxes here and there for input.

Nothing comes very close to Drupal's overall UI/UIX consistency, which is the result of the FOSS community management model, and review, not a bunch of "hotshot" programmer cowboys thinking they're writing optimized, awesome code.

Re:Drupal != Pro (1)

Foofoobar (318279) | more than 3 years ago | (#35203824)

You're evidently looking at matters from a developer's perspective...

Um... And you're looking at things from a tuna fishermans perspective? I'm sorry. what perspective should I be using here?

Re:Drupal != Pro (1)

theNAM666 (179776) | more than 3 years ago | (#35203938)

End user (unless, Mr. Tron, you work for IBM and don't believe in them). Content Management Professional. Site Owner. Journalist. Board of a Professional Organization.

Maintainability. Long-Term Development Cost. Management Cost. Etc.

Any view except "I'm the grunt who has to build it, and I'd like to do it my way because I'm comfortable with my way."

Re:Drupal != Pro (1)

Foofoobar (318279) | more than 3 years ago | (#35203990)

Oh ... so Drupal is for your mom. I see the target audience now.

Cake et al. (1)

Compaqt (1758360) | more than 3 years ago | (#35208942)

Is only Cake's MVC ancient? Or also the other PHP frameworks? Is there a better way of MVC?

And is, say, Symfony, better?

Also, re: UI- you're able to use Smarty or something else for templating in Cake. Is that not sufficient?

Re:Drupal != Pro (1)

adamfranco (600246) | more than 3 years ago | (#35206840)

Actually, an MVC framework such as Symfony, Zend, Codeigniter, Phpulse, Cake, etc all can scale far better, and has faster development times. There is no trying to figure out how to 'code around' Drupal. Code is properly separated and follows coding standards. Sure you have libraries that work for Drupal but framework have libraries that work for EVERYTHING... not just Drupal and the code can fairly easily be switched from framework to framework. Lets see you move Drupal code to Codeigniter or Zend.

During the past 3 years I have developed several applications with the Zend framework (which I really like as MVC frameworks go). Earlier in my career my team developed its own MVC framework which turned out to operate well, but wasn't worth the immense development effort. Recently I've worked on several "sites" and one "application" based on Drupal.

What I have found in this process is that Drupal is not a content management system, but rather a framework for building a content management system. It doesn't do much out of the box with no community modules (unlike Joomla or WordPress), but its plugin system works well for developing a very wide variety of CMS platforms for many uses. Just as Drupal is not so specialized as a particular CMS, neither is it so general as an MVC framework. For example, Zend's 'router' is much more flexible than Drupal's 'menu' system and Zend's configuration system blows away anything in Drupal.

A great use case for Drupal is a "site" with lots of "articles". Adding an additional data field (say an address), theming it, and using it to filter a dynamic selection of content is about a 15 minute job that requires a few clicks in the Content-Type UI, a few clicks in the Views UI for the filter, and maybe a few template lines for theming if the field will be displayed. The user-input forms, content validation, data storage, and default theme are all handled. Contrast this to using an MVC framework where you have to add properties to your model (and update the database schema if not using an ORM), then add some lines to your edit-form view to add the fields to the HTML, then update the form-save controller action to pass off the submitted form data to the model after validating it, then update the display view to show the new field, then add a new action that filters based on your new field. This is certainly not the end of the world, but it requires a significant bit of programming.

At the end of the day it is all about using the right tool for the job. If I am going to develop an application with a custom database and data model (or based on an existing database) and just want to put a front-end on it, I'll use the Zend framework for the front end. If however, I'm going to build something that looks like a CMS with something like "content nodes", user-comments, tagging/categorization, a variety of user-roles, etc, then it is going to be much easier and more supportable to build such a system in Drupal.

With every framework there is an explicit or implicit vision baked into how it is designed. If your project fits into this vision then the framework will work smoothly and be a fabulous help over starting from scratch. If your project doesn't fit the framework's vision then you will find yourself fighting with the baked in assumptions and ultimately frustrated by all of the workarounds you have to write.

Re:Drupal != Pro (0)

Anonymous Coward | more than 3 years ago | (#35202660)

The complaint isn't that Drupal isn't perfect, or that its near-perfection is its weakness.

It's that on the spectrum of 'Garbage' to 'Perfect', Drupal is so close to 'Garbage' that its not worth writing, printing, or reading or reviewing a book on it.

Re:Drupal != Pro (2)

hobo sapiens (893427) | more than 3 years ago | (#35203388)

haha, good self-interview.

If I were going to put a blog or some simple CMS, Drupal would be a solid choice. It supports a lot of semantic web functionality out of the box Nice simple install process, relatively good data design.

Having had to venture to the fringes of Drupal, I was less than impressed. Drupal is billed as a do-all web framework. I don't think you could be more wrong than to think Drupal will fit any possible use case. You start using off-the-beaten-path modules, things get real ugly real fast.

Learning the framework is not fun. Sure, the IOC/hooks part is neat in theory. In practice it's a pain to code. And the code conventions suck IMO. (two space indenting, WTF?) The way the forms work, and the Db abstraction are a bit overbaked. I like learning new things. What I don't like learning is someone's wonky framework. Especially when it's clear it wasn't well planned, but more of a patchwork of neat ideas.

And then the modules. Look! there are thousands of community developed modules! The community will do the work for us! Wait a second, sluggo. Many of those modules are really poorly designed. Some of them are so amateur that once you start throwing real datasets at them, they completely buckle. And since they use the Byzantine framework (which I am convinced many drupal developers do not really understand) they are almost indecipherable.

A lot of my Drupal experience went like this:
boss: "we're using drupal. it does a lot of neat things, and if we don't like how it works we can just rewrite it"
me: "uh...ok..."
boss: "so we need this site to do A, B, and C."
me: "in order to do that, I'll have to extend the SOLR search, and then write a Drupal module to get the results. It will work great but will take n days."
boss: "any other options?"
me: "drupal has x, y, and z which if we turned them on their side and misused them could probably kinda sorta work"
boss: "I like that, do it"

a very frustrating sequence when you could have just used an existing MVC like Zend and did it yourself. Even moreso when you were hired as a LAMP developer and then are told everything will be done in Drupal (what, that's the same thing! Drupal is written in PHP.) So in all fairness that might have left a bad taste in my mouth about Drupal.

On a personal note, I found working with CCK and Panels to be far less interesting and rewarding (and in many ways, less effective) than coding it myself.

Re:Drupal != Pro (3, Insightful)

theNAM666 (179776) | more than 3 years ago | (#35203844)

You point out a lot of realistic, real problems. Plus you're not an AC!

There is a lot of amateur code. There are a lot of developers who don't understand the framework, or its reasons. There are some Byzantine elements. All of this, needs to be reviewed, and IMHO, the community needs to establish better review practices-- which is going to be hard in a community that has focused on "do it," "do-ocracy." These are real issues.

Self-interview: do I doubt that you could replicate the CCK / Panels more quickly yourself, if you're skilled-- at least, any particular implementation. I don't. And Panels hath its issues -- not least of all, in terms of nomenclature. But the point is, it's an overall framework.

I can deploy Panels / CCK implementations, faster than they could be written -- because I accumulate them, if nothing else. And all these things, inter-operate with each other, relatively. You get a series of websites, written in the same way, working in the same way -- in place of five-hundred kitchen sinks, each built differently, to manage. You get an overall, relatively consistent user experience. You get things such as the Baltimore Usability group looking at the Admin UI with eye-tracking studies, and then improving it.

Is Drupal the best choice in every situation? No, it isn't-- you'll have to evaluate that yourself. But it didn't take Drupal, to get us the clueless boss stuffing a technology he doesn't understand well enough, down the team's throat.

Could your team cook up something on their own, faster? Probably again. Maybe that will be fine. I can't predict that-- you have to look at specifics, details-- but I think it is quite arguable, that in the kind of situation you describe, it might make more sense to work with an experienced "consultant" (darn it, that word must be evil) to find the best Drupal way to do what you wish.

And documentation? Yes, there's a problem there too. The current community prefers "codeslingers" to documented, and that can only go so far. It needs to be addressed. But it's a large FOSS community-- there's time for that to happen.

Re:Drupal != Pro (1)

kikito (971480) | more than 3 years ago | (#35208504)

If the biggest problem you found on Drupal code was the two-spaces indenting, then reading Ruby code will give you a heart attack.

Re:Drupal != Pro (1)

hobo sapiens (893427) | more than 3 years ago | (#35209880)

well, it's good you did read one sentence of my post before replying. Next time, try reading two!

Re:Drupal != Pro (1)

kikito (971480) | more than 3 years ago | (#35212130)

It's more like the fifth line.

But given the fact that you think that two-spaced indentation is a bad thing, you probably are impervious to wasted vertical screen space.

Re:Drupal != Pro (1)

BlortHorc (305555) | more than 3 years ago | (#35202390)

Just my opinion, I wouldnt touch Drupal with a barge pole. Really nasty set of code. Still , if you are forced into using it without looking at other PHP frameworks such as Symfony then maybe this book will help you find your way around it.

Sing it, sister!

The most horrible "framework" I have ever seen, and the worst "framework" code I have ever seen.

No clue about encapsulation. No clue about the object model at all. No clue about MVC. Core code that is random display, with inline SQL to make it look far less professional. There are reasons no one uses Cold Fusion anymore. This is just one of them.

Plus, if you find that tonk who wrote Drupal. Beat him with a typewriter until he says sorry.

Re:Drupal != Pro (1)

Ice Station Zebra (18124) | more than 3 years ago | (#35203166)

Best bring your lunch if you want to beat up the Drupal dev community.

Re:Drupal != Pro (0)

Anonymous Coward | more than 3 years ago | (#35225502)

Seems you're the clueless one. There's been plenty written about the design tradeoffs. Generally, they're all for flexibility.

Encapsulation - Want to see what's going on under the hood? Want to develop a module that does something previous developers didn't anticipate? Nothing's stopping you, you can examine and modify any of the data.

Object Model - left out on purpose due initially to PHP's limited support for OOP, and more recently because Drupal's architecture already provides many of the benefits of OOP with more flexibility. Nowadays, it's being used in modules where appropriate, but there's still no reason to twist the whole system into some convoluted class hierarchy.

MVC - not a very good fit for a web app, which is why Drupal uses PAC architecture instead

Inline SQL - simplicity and flexibility up front are good sometimes, and much lighter than a library of query-builders that just produce the same end result. But Drupal has now moved to using PDO since priorities have shifted to needing more flexibility on the back.

Cold Fusion - You have no clue that we're talking about PHP

Typewriter - I don't have one anymore. Most of us have progressed to using computers to program. Someday maybe you'll catch up to 1981 too.

Re:Drupal != Pro (1)

statsone (1981504) | more than 3 years ago | (#35202708)

I need to disagree with Drupal being a nasty set of code. It is a CMS - content management system and it is made to grow and handle large sites. Using it on my own and like how you can add powerful modules to increase the use of the system. The learning curve can be a little large, but it is a powerful CMS and there is lots it can do. Reading books such as the above may help ( I have not read the book) There is also online resources and local meetings.

Re:Drupal != Pro (0)

Anonymous Coward | more than 3 years ago | (#35203228)

Almost no point replying to someone comparing a framework to a CMS.

Drupal does a lot of things well enough, and so do several other CMS systems that it makes little sense to roll your own with less functionality at a higher cost both in initial outlay and in maintenance / updating. Some people don't see that though, and just see their chosen hammer and everything is a nail.

Re:Drupal != Pro (0)

Anonymous Coward | more than 3 years ago | (#35203666)

I'm not sure your disagreement is warranted. Everything you said does not express why it's not nasty. Rather you're touting about "powerful" modules and that it can do lots. None of this excludes the possibility that the code may in fact be quite nasty (from what I've seen, it is.). I'm also not inclined to believe you in that it's so "powerful" either, you provide no actual example, but I digress. In my experience though, most of those "powerful" modules had not worked as advertised... or at all.

Re:Drupal != Pro (1)

design1066 (1081505) | more than 3 years ago | (#35203734)

by nasty you must mean hard for YOU to wrap your head around.

Re:Drupal != Pro (0)

Anonymous Coward | more than 3 years ago | (#35204188)

Oh I think there is no lie in that its a steep learning curve, and that some of the modules do not play well together, and others don't do much at all. I can take a batch of core modules with a proven track record and create a site with a lot of functionality with little effort. Things that would take months if I was trying to do it all in a framework.

Will Drupal scale? Absolutely. Will it scale as easily as other things? Probably not. Does that matter for 99.9% of the sites out there? Again: nope. Different solutions for different problems IMO. Would you rather write your blogging platform from scratch for the 50 users it will get per day, or just use Wordpress? This question directly addresses the actual issue IMO.

Re:Drupal != Pro (1)

unity100 (970058) | more than 3 years ago | (#35205668)

i second that too. even, third that.

A minor improvement (2, Insightful)

Anonymous Coward | more than 3 years ago | (#35201872)

I got this book because the second edition has been invaluable for all my drupal 6 work. When the going gets tough, you check that book first.

I was a bit disappointed with this one. It wasn't as much of an overhaul as I'd have liked, particularly since my main questions where on how things would be different in drupal 7 versus 6. So if you have the second edition, look for other books (notably those by Packtpub) that focus mainly on the differences. It's a better investment of money.

Of course, if you don't have either of the previous editions, this one is definitely the one you want to get first.

Enough Already. (2, Informative)

Anonymous Coward | more than 3 years ago | (#35201886)

How [slashdot.org] many [slashdot.org] damn [slashdot.org] Book Reviews on Books about Drupal do we need? Enough already, have some damn variety.

Re:Enough Already. (1)

callmebill (1917294) | more than 3 years ago | (#35201938)

Sounds like someone's volunteering to read and review a book on a novel subject! P.S. - That volunteer is you.

Re:Enough Already. (1)

basotl (808388) | more than 3 years ago | (#35202012)

Hey this one includes a brief synopsis about what Drupal is. Finally one submitter got that part right so that commenters wouldn't complain about it. Though after so many reviews I would hope all the Slashdot crowd knows what Drupal is.

Worst "Professional" Book I've Ever Read (1)

Anonymous Coward | more than 3 years ago | (#35202130)

1. It's not been proof-read to the extent that some of the sentences make no sense as printed. Careful reading and imagination is necessary.

2. The examples are very confusing: the simple point the trying to be made is usually hidden within a pile of irrelevant material. And the irrelevant material -- which is required for the example to work -- is not discussed. The over-long identifiers seriously decrease the readability.

3. The text frequently reads more like a series of "notes to myself" rather than something designed to be either instructive or descriptive.

4. There is a great lack of diagrams, flowcharts, or descriptive pictures. The one or two that do exist are very poorly constructed.

5. The one possibly useful part -- Appendix A, the database table reference -- is as sketchy and incomplete as the rest.

The general state of Drupal documentation is very poor, either incomplete or assuming a great deal of pre-knowledge. This book does nothing to raise the level.

I've never felt that I had wasted my money on a technical manual before -- this one is a first.

"Pro Drupal 7 Development" makes you appreciate the real work and care that O'Rielly puts into their books. I'll be very reluctant to get anything else from "apress" again.

Re:Worst "Professional" Book I've Ever Read (0)

Anonymous Coward | more than 3 years ago | (#35203010)

I have not read this book. In general Apress publishes fairly good books, easily on par with O'Reilly.

Now I wonder if this is a one time fuck up, or that Apress is severely slipping...

Re:Worst "Professional" Book I've Ever Read (1)

kc8jhs (746030) | more than 3 years ago | (#35204104)

Except for that fact that this book went to press well before Drupal 7 was close to finalized. (as did almost everyone's Drupal 7 books, except for O'Reilly)

Swiss Army knife (0)

Anonymous Coward | more than 3 years ago | (#35202214)

When you're deploying a CMS for a client who wishes to be able to manage their own CMS' content without the need to overcome a huge learning curve, WordPress is by far the better choice over Drupal. Excellent user-friendly back-end, themes are easily integrated with the CMS API, and hosts a plethora of plugins which make common tasks (think social network integration, linkage to useful SEO tools, whizbang effects, and so on) a cinch.

A pocket knife is beat out by a Swiss Army knife ... except for when you just need a pocket knife.

Re:Swiss Army knife (0)

theNAM666 (179776) | more than 3 years ago | (#35203000)

Ah... the other end of the spectrum, heard from. We have the uber-geeks above, arguing that you need to operate your own knife factory. And we have the AC idiot here, arguing for the "just a pocket knife" WordPress option.

He're the thing. WordPress is dreck. It relies on a series of modules, (plug-ins), published all over the internet-- no central repository, no security review, no consistency, *truly* spagetti code in the sense hated above.

It has no user permissions system, whereas Drupal follows the *nix perms model-- a model, even a small three-person auto parts shop, may very quickly find they need.

When is just a pocket knife bad? When you find you're locked into a pocket knife, that your metaphor sucks, and because you're never used anything else, or paid to much for the pocket knife in the first place, you don't know you need the swiss army knife, that you can't afford it, or that you're just plain stuck.

Oh, by-the-way: SEO sucks in WordPress. The whizbang affects are a lot of flashy, and not much usability. Social network integration? You're kidding, right?

Re:Swiss Army knife (0)

Anonymous Coward | more than 3 years ago | (#35205032)

I assume you've never used WordPress based on the ignorance of your comment:

It relies on a series of modules, (plug-ins), published all over the internet-- no central repository, no security review, no consistency, *truly* spagetti code in the sense hated above.

Drupal does absolutely nothing out of the box without using a module. Absolutely nothing. As for a central repository, maybe you'd care to check: http://wordpress.org/extend/plugins/about/svn/ [wordpress.org] Which is... a central repository for plugin code.

It has no user permissions system, whereas Drupal follows the *nix perms model-- a model, even a small three-person auto parts shop, may very quickly find they need.

WordPress has, built in, a role based permission system. Which, last time I checked, is EXACTLY what drupal uses. Next complaint?

Oh, by-the-way: SEO sucks in WordPress. The whizbang affects are a lot of flashy, and not much usability. Social network integration? You're kidding, right?

Again, you are severely misinformed. WordPress comes with permalink functionality out of the box. It doesn't require a module like drupal does. Additionally, there are a number of truly excellent SEO plugins for WordPress, used by literally millions of people: http://wordpress.org/extend/plugins/all-in-one-seo-pack/ [wordpress.org] If you don't like the WordPress whizbang effects, please don't feel obligated to use them. At least wordpress has SOMETHING built in without having to install an admin module. My clients tend to appreciate the intuitiveness and simplicity of the built in wordpress admin. If they want something more complex I use custom content types. If they want something more complex I used a custom admin. How would you handle that in drupal, exactly?

Re:Swiss Army knife (1)

theNAM666 (179776) | more than 3 years ago | (#35205794)

Sorry-- alas, I do have to convert and manage WP sites. In order:

1) Your idea of a central repository is not my idea of a central repository. Drupal Modules are on Drupal.org, and where issues and code are tracked and tested via both a community model, and an automated check to assure code integrity (etc). WordPress now has a central folder for modules, which is used by some plug-in developers at this point, ignored by many others -- and playing catch up. This folder is not central to the WP model; there are no coding standards etc etc.

2) The levels of WP users is hardly a user permissions system. WP has userlevels. It does not have a groups/permissions system. There's a difference. Plugins can test those userlevels, you can build a permissions system or use a random third-party system, but there's a difference from this and a fine-grained permissions system. And who would enforce those permissions in WP, anyway?

3) I know what permalinks are-- big deal. Drupal has them too, and Drupal's work-- WP's are a good way to create loops in ReWrite rules.
Recently, I converted a WordPress site with 200K plus pages to Drupal, putting the converted site on a new domain. Within two weeks the converted site, displaying the same content, was ranking higher in Google than the WordPress site. Why? Because the right Drupal theme displays content correctly for SEO "out of the box," because a team of people have gone over the problem and found the best solution, or at least a darn good one.
Why? Because WP's SEO stuff is not bad, but there a bit too much smoke and mirrors and guesswork going on, and too little searching for best practices and distributing them.

4) Admin etc: Again, big deal. The WP admin GUI is nice for some things, but big deal. I'd install an appropriate admin theme for the client, after doing needs assessment, which might show they need something quite different than the WP default. But if I want to give them something WP-admin-like, I can. Drupal has custom content types (CCK) and it's about 10 times easier to use them than WP, and you're not making a custom kitchen sink solution, which loses portability.
Can I deploy a simple WP like site from an installation profile if I want, with custom content and views and taxonomy working so much better than in WP? I can. Is that kind of simple site the only place I want to be putting my attention, and do I want my clients to be locked into a solution which assumes they JUST "want a simple site" and makes it a lot harder for them to get much more? Darn sure "NO" to that question.

Re:Swiss Army knife (1)

drinkypoo (153816) | more than 3 years ago | (#35206306)

It has no user permissions system, whereas Drupal follows the *nix perms model

Uh what? Drupal permissions are more like capabilities. Modules publish them under hook_perm and then test for them later. Users have roles but they're not quite the same thing as groups. If you want role-based access control you have to add a module [drupal.org] . Which is not to say that Drupal is not light-years ahead of Wordpress, but it has more complicated access control than Unix (for good and ill.)

Re:Swiss Army knife (1)

theNAM666 (179776) | more than 3 years ago | (#35206560)

I was trying to keep it simple, silly. KISS-- it's V-Day, after all!

Roles in Drupal are not quite UNIX groups, true... and modules do have a bit too much access / ability to ignore roless, as some people point out above; data insulation (or whatever you want to call it) is not hard enforced at all.

Drupal access control (1)

Compaqt (1758360) | more than 3 years ago | (#35208898)

Are you using content_access anywhere? My experience with ACLs was that it runs like a dog (for popular sites), to the point where totally loads up the (beefy) server.

Enough with the book reviews (2)

sirdude (578412) | more than 3 years ago | (#35202458)

Enough with book reviews and enough with Drupal book reviews. Doesn't /. have anything interesting to report? How about a limit of 1 review per month?

Only a "few" errors? (2)

eclipz (630890) | more than 3 years ago | (#35202706)

For a book with "Pro" in the title, I expect more than "...and there are only a few places where the code does not match the narrative, or the code is incorrect in some other way". I'm rather surprised that a book that is attempting to be a learning guide would let *major* errors such as that through. I suppose I'll go for my learning somewhere else.

Re:Only a "few" errors? (0)

Anonymous Coward | more than 3 years ago | (#35203506)

If I were the publisher, I would be inclined to hire you to proofread my next book.....

Re:Only a "few" errors? (1)

Raenex (947668) | more than 3 years ago | (#35203928)

What's the *major* error?

Needs revisions, missing MAJOR new topic (3, Informative)

DamienMcKenna (181101) | more than 3 years ago | (#35202790)

This book was clearly rushed to market for two reasons:

  1. The Drupal coding standards [drupal.org] are not adhered to when every single line should have been poured over for 100% accuracy, given it is such an important part of "the Drupal way" and how this will be many developer's first book.
  2. One of the most important new concepts of Drupal 7, Entities, is not really given any coverage.

Re:Needs revisions, missing MAJOR new topic (3, Interesting)

cultiv8 (1660093) | more than 3 years ago | (#35204568)

There was a huge push from Apress to get D7 books to market; I was under incredible pressure for my [slashdot.org] D7 book and there were many times I just had to tell them "no", yet they didn't want to listen. It didn't help that Dries told them on a conference call that a D7 RC would come in Q3 of 2010...

Roll your own. (1)

design1066 (1081505) | more than 3 years ago | (#35203818)

/. can't accept that a popular project is awesome because its not how they would have done it. Well we are all waiting for your awesome project to roll out. Blah blah object oriented, blah blah complicated table structure, blah blah people who use Drupal blah blah. Drupal Suxors. Blah Blah framework X, blah blah blah. If you don't like it, then don't use it or see above.

Re:Roll your own. (1)

spacepimp (664856) | more than 3 years ago | (#35203902)

With Native C Apps!

Drupal drupal drupal drupal .... (1)

unity100 (970058) | more than 3 years ago | (#35205678)

it hasnt been a month or so since the last article about drupal was posted here. and now this. in retrospect, i dont even remember the time at which something relating to some other bloated (or better) 'cms' system was posted in slashdot.

why ?

is there a connection in between someone at slashdot and drupal ? why the free advertising for a bloated, developer-hostile heap of code, in a place where developers frequent ?

Re:Drupal drupal drupal drupal .... (1)

Foofoobar (318279) | more than 3 years ago | (#35205728)

Bravo... couldn't have stated that better myself.

Re:Drupal drupal drupal drupal .... (1)

kikito (971480) | more than 3 years ago | (#35208558)

Despite hating Drupal a lot, I must point out that your signature makes me think that your comment isn't completely unbiased.

hahahaha definitely it isnt. (1)

unity100 (970058) | more than 3 years ago | (#35211894)

actually, one of the reasons why the code in my signature has come to being, is because i had had the misfortune of using drupal for a client. one good thing that came out of it, was that.

Re:Drupal drupal drupal drupal .... (0)

Anonymous Coward | more than 3 years ago | (#35222338)

Drupal is very popular, and getting moreso. Wordpress is a wonderful system for simple sites but you quickly hit a brick wall when you try to customize. Cake/Zend/Symfony/Rails/etc are all fine for building large custom dev projects, but there's a large ramp-up time replicating fairly standard CMS functionality.

Drupal is ugly, but it gets the job done quickly. It's this decade's Visual Basic - "real engineers" hate it, business types love it, people who can hold their nose and deal with it are rolling in $$. Attended a DrupalCamp event here in Florida over the weekend and you wouldn't have known there was a recession happening.

Re:Drupal drupal drupal drupal .... (1)

unity100 (970058) | more than 3 years ago | (#35222500)

one would think so until s/he tried to modify drupal in a non standard way.

Drupal++ (-1)

Anonymous Coward | more than 3 years ago | (#35205842)

This book is an excellent resource for developers wanting to know more about the powerful Drupal CMS / Framework.

If you think the code is awful, take a look at http://api.drupal.org - looks fine from here!

Down with the haters. Drupal rocks!

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?