Posted
by
samzenpus
on Monday February 14, 2011 @02:57PM
from the read-all-about-it dept.

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.

Pro Drupal 7 Development, Third Edition

author

Todd Tomlinson and John K. VanDyke

pages

720 pages

publisher

Apress

rating

9/10

reviewer

Michael J. Ross

ISBN

978-1430228387

summary

A thorough guide to module building for intermediate to advanced Drupal coders.

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.

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.

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.

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.

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

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

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.

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

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 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, pa

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.

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.

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 pra

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.

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, a

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

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 rea

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.

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.

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.

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.

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.

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 so

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.

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

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

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.

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.

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.

One of the most important new concepts of Drupal 7, Entities, is not really given any coverage.

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

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 ?