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!

Drupal 7 Module Development

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

Book Reviews 31

Michael J. Ross writes "While it is possible to create a simple website using a base installation of Drupal, the real power of this content management system is achieved through the use of modules, which can be thought of as add-ons that extend the capabilities of Drupal in specific ways — oftentimes in conjunction with other modules. These modules are developed and contributed by PHP programmers who understand how to use one or more of the Drupal application programming interfaces (APIs) to access information stored in a Drupal database, such as content, user profiles, and theme settings. These APIs have changed with Drupal version 7, and thus Drupal coders could benefit from a book that explains how to create Drupal 7 contrib modules." Read on for the rest of Michael's review.One such resource, titled Drupal 7 Module Development, was made available by Packt Publishing on 3 December 2010, under the ISBN 978-1849511162. It has half a dozen authors, all of whom are highly experienced Drupal programmers and contributors to this burgeoning open source project: Matt Butcher, Greg Dunlap, Matt Farina, Larry Garfield, Ken Rickard, and John Albin Wilkins. This team effort spans 420 pages, organized into a dozen chapters, and two appendices. Angie Byron, the Release Manager for Drupal 7, starts it off with an interesting and upbeat foreword that concisely summarizes the primary goals of this latest release of Drupal. Following it is a preface whose chapter summaries are poorly written — almost as though the writer knew nothing about Drupal. Speaking of technical knowledge, readers are expected to be familiar with Drupal, PHP, HTML, and CSS — the more so, the better. For the jQuery material, an understanding of that library and JavaScript itself would be valuable. Packt Publishing hosts a book Web page that offers a detailed description of the book, links for purchasing the print and electronic copies of the book (or the two combined, for a large discount), and the example source code for nine of the chapters (also available from the book's GitHub repositories). As with all of its other titles, the chapters end with summaries, which provide no value and simply waste space.

This book's first chapter, "Developing for Drupal 7," provides an overview of the purpose of custom modules, the practical approach that the authors will take in explaining how to create such modules, the Web technologies underpinning Drupal, the Drupal architecture, its major subsystems, and various tools commonly used for Drupal programming. Oddly, the authors hope "that the code mentioned in this chapter can serve as a foundation for your bigger and better applications," and yet no code per se is mentioned. Nonetheless, the chapter does serve as a decent introduction for PHP programmers new to "the Drupal way." The second chapter, "Creating Your First Module," shows the reader how to do exactly that, using a very simple module to illustrate the basics, such as the files that typically compose a Drupal module, as well as some Drupal coding standards. Unfortunately, regarding the code on page 38 that checks whether the $path variable is "admin/help#first," no explanation is provided as to why the "#" is not a "/," given that the URL path in the reader's browser will be "/admin/help/first," and the "#first" does not refer to a page anchor. After a worthwhile detour into Drupal internationalization and the t() function, the authors introduce both the Block API and the Testing module, through example. Incidentally, readers trying out the sample code will want to add "static" to "public function getInfo()" in first.test — as is done in all of the other Drupal 7 core test files — to avoid a PHP "strict" warning of a static call to getInfo() in simpletest_result_form().

The next two chapters focus on theming — specifically, Drupal's theme layer and techniques for theming a custom module. The material in both chapters is arguably comprehensive, and thus ideal for a reader already well-versed in Drupal 6 module development. But, for anyone else, it will likely be overwhelming in its dense detail and in the fast pace at which it is presented — and thus will discourage most newcomers. The former chapter presents numerous high-level concepts, while the latter is intended to illustrate those ideas by focusing on module theming. Yet even if the reader carefully examines and implements the sample code — usually the best way to learn any sort of programming — these chapters will probably prove quite difficult for readers to comprehend thoroughly, unless they have prior experience along these lines. Oddly, the Chapter 4 summary tells the reader that she should have "learned a little bit about contributing your experiences [sic] and knowledge back to the Drupal community," but the material does not explain how to do so. (More on that topic later.)

Chapter 5, "Building an Admin Interface," provides a detailed survey of the Drupal menu system, the Form API (including how form data is saved, which is inadequately covered by some other books), Drupal's built-in e-mail system, and the use of tokens therein. The coverage is again detailed, and would be even better had the remaining commonly-used HTML form elements — such as list boxes and radio buttons — been shown in the example code. For those readers whose heads are still spinning from the previous two chapters, this material may be a welcome change, in that the explanations are slower paced, with seemingly greater attention given to whether the Drupal newbie will be able to learn what is being taught, step by step. However, any reader who is using this chapter as a reference when creating a custom implementation of hook_menu(), will doubtlessly become frustrated by the inadequate advice on determining the valid possibilities to be used in the access arguments array: "[check] the hook_perm() implementation of the module in question." But what module? The reader is presumably creating a new one from scratch, with no permissions already set; so the authors must be referring to an existing module — but which one? If the reader were to search through all of the core and example modules, he would find no hook_perm() functions. Do the authors mean hook_permission()? This illustrates how critical it is for authors and technical editors of books purportedly for beginners, to strive to put themselves in the shoes of the poor reader, who does not possess their knowledge and experience.

As with any CMS, "content is king" for sites built using Drupal. Thus it is critical for Drupal module developers to know how to dynamically create and manage all of the elements required by a module working with content: node, entities, fields, etc. In earlier versions of Drupal, the familiar "node" concept did not encompass all of the non-node data types, such as users and comments — forcing developers to create workarounds in their modules and in their sites as a whole. Version 7 introduces "entities" and "bundles" (which can be thought of as sub-entities), to allow greater flexibility for programmers. Chapters 6 and 7 delve into these concepts, with plenty of example code and explanations thereof. Readers learn how to create database tables indirectly using the Schema API, define new entities, give users the capability to manage them, encapsulate multiple database operations into transactions, and define new field types, widgets, and formatters.

Chapter 8, which focuses on how to set and use permissions within modules, is straightforward, and includes sections on the secure use of regular form processing, as well as AJAX callbacks (for interactive form behavior that avoids the necessity of reloading the current page). Incidentally, there appears to be an error in the code on page 221: "function example_menu() example_menu() {." Chapter 9 continues in the same realm of security, specifically, use of the Node Access system within Drupal. The coverage is quite thorough, and the only problem is that some of the "tips" blocks repeat information found in the regular text. The chapter concludes with some valuable advice on how to test and debug node access modules, which can be especially difficult.

The last three chapters of the book cover some interesting and worthwhile topics: JavaScript, file management, and installation profiles. Readers learn how to add JavaScript and CSS to a site, how to use the Drupal Library API, and related matters. Sadly, readers may be perplexed by the numerous poorly-constructed sentences — especially near the beginning Chapter 10 — such as "JavaScript within a group and within the sub-group of being or not being included in every page are ordered by weight" (page 291), which sounds like a joint effort by Hamlet and the IRS publications department. The next chapter demonstrates how to use the new files and images API that was introduced in Drupal 7, and which allows developers to reduce the number of contrib modules required for building even the most basic website. Confusingly, the reader is told that, when installing Drupal (presumably version 7), he will probably see three error messages resulting from missing sites/default/files directories; but I certainly did not see this when installing any of the beta or release candidate versions, nor heard this from anyone else. The authors also explain stream wrappers, the Image API, and image styles (and the effects they can utilize). The last chapter shows how to set up custom Drupal profiles, their tasks, and the distributions that can make use of them. The reader is told that "input formats" are now referred to as "text filters," but Drupal 7 appears to have standardized on the term "text formats." The book's two appendices discuss Drupal 7's improved database layer, and security techniques applicable to all versions.

Packt's website states that there are no known errata, so one can only assume that the publisher's editors failed to spot many obvious flaws: "a[n] introduction" (page 1), "eXtensible" (page 10), "However, Not" (page 16), "it's own data" (page 17), "though means" (page 18), "architecture advanced" (page 25; it presumably should read "advanced architecture"), "( a," (page 28), "an[d] equal sign" (29), "the the" (41 and 146), "exercising [of] every" (49), "test[,] absolutely" (53), "a child element[s]" (78), "its" (84; should read "their"), "short-coming" (85), "then" (90 and 98; should read "than"), "you will be passed to" (108), "lets" (120 and 129; should read "let's"), "FormsAPI" (235), "to post spam [to] the site" (254), "ever[y] page" (291), "html" (311; twice), "is to" (318; should read "to"), "how to we" (326), "let's make create" (326), "is [a] result" (365), and "many [of] types" (376). The reviewers section lacks page numbers, but does not lack errors: ", (," "and [a] bug," and "including[,] reviewing."

The writing quality varies from chapter to chapter, and some passages are awkwardly phrased and confusing, such as "each of these two lines were split on to one line" (page 57). Scattered throughout the book, one will find cases of semicolons used where dashes are called for, commas where semicolons are called for, title case used when inappropriate or missing when appropriate (the book's preface is a veritable minefield), compound adjectives missing hyphens, adjectives incorrectly tied to nouns using hyphens, needed commas missing (Appendix A has some egregious examples), and the term "was" used where the subjunctive "were" is called for — in other words, the usual grammatical flaws found in books written by techies. Fortunately, the material is livened up with a few welcome bits of humor, and not the overreaching kind found in many programming books. Even more admirable is the attention to internationalization, unit testing, and other good practices.

The example code within the text may be intimidating to those new to Drupal, but it really helps demonstrate the concepts discussed in the text. The downloadable source code is helpful for avoiding retyping that code from the text, but needs to be cleaned up. For instance, the code for Chapter 4 is in a directory named "1162_04_All code," which suggests that it contains all three versions, but it does not. The code for Chapter 5 is split between a subdirectory named "old," which contains the newest code, and in another directory, "1162_05," which contains older code. The directory "1162_07_Code" contains no fewer than six different (and possibly differing) copies of its example module. How can the reader know which is the correct copy to use for following the book's discussion? Moreover, for some of the chapters, such as 5, the source code listed and discussed in the book does not fully match that provided in the downloadable archive file.

Overall, this book is a substantial contribution to the Drupal literature, but it is weakened by two obvious problems: Firstly, it lacks a chapter or appendix to explain how the reader could contribute a newly-created module to the Drupal community — specifically,'s Modules section. This is a glaring omission, particularly in light of the (laudable) encouragement to the reader to participate in the community, as well as the authors' many contributions to the same. Secondly, because this book is supposedly suitable for Drupal beginners, and given the complexity of Drupal's APIs and their code requirements, the authors should have presented the concepts in more digestible chunks, at a slower pace, so as to be easily comprehended by someone new to Drupal programming using APIs. This is especially true of the second and third chapters.

The aforementioned problems could be corrected in a subsequent edition, which would be well worth the effort: Drupal 7 Module Development is an information-packed and wide-ranging resource for experienced Drupal programmers who want to enhance their existing module-building skills, and transfer them to version 7.

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

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

cancel ×


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


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

Going to Drupal, man ?? Can I get a lift ??

What a surprise (-1)

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

Yet another 8 out of 10 book review.

Re:What a surprise (1)

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

Yeah, Packt sure is buying lots of shill reviews lately. They used to space them out more. Apparently they are having revenue problems recently so they are trying to bolster their book sales.

Re:What a surprise (2)

Kilrah_il (1692978) | more than 3 years ago | (#34702530)

I really liked your comment. Very insightful. I think I'll give it... 8/10.

The review[r] appears confused (3, Insightful)

Magic5Ball (188725) | more than 3 years ago | (#34702772)

The numeric rating and the text of the review seem to disagree. The reviewer generally finds that the book lacks good editing, content flow, and accessibility for its intended audience, yet assigns it a rating that would put it above most of its competitors.

But perhaps, I just don't understand the review. Having developed modules, plugins, themes, etc for WP, Joomla, Drupal, and other CMSes--but not recently--this review provides me almost no useful information on which to make a purchasing decision about the book reviewed. I don't know whether it attempts too much by attempting to tackle the differences in the new version specifically, and Drupal modules in general, and security and database concepts, project managent, and whatever else, or whether it attempts too little by only regurgitating material elsewise available online without overarching context.

The reviewer does not even present the single useful item of technical information in the review about poor indexing in a useful way. Does the volume /require/ a topical index to be appropriately useful to the reader, and is the content searchable or indexed in some on-line form? The answer--obtainable if the reviewer took the time to understand the volume s/he reviewed--makes a great difference as to whether this book is suitable as a desktop companion, commuter reading, or for some other purpose.

Most book review guidelines, including /.'s, implore the reviewer to provide more than just a summary of the volumes reviewed. In this review, I see many individual nit-picky criticisms and praises (applicable to almost any volume when read by particular kinds of reviewers) but almost nothing about whether this stands as a good book.

Meh (1, Informative)

thePowerOfGrayskull (905905) | more than 3 years ago | (#34702498)

Another sycophantic (and self-promoting) Michael J Ross review of a Packt Publishing book. Color me surprised.

Re:Meh (0)

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

Packt has a great history of supporting open source projects and the book is written by a number of semi-famous, super skilled Drupal developers. I have been looking forward to this book, pre-ordered it, and would guess the positive book review has at least something to do with it being a great book.

Re:Meh (2, Interesting)

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

And yet it's entirely coincidental that almost every single Packt Publishing review is an 8/10 no matter how many flaws are pointed out in the review? Seems to be highly fishy.

Re:Meh (1)

Rogerborg (306625) | more than 3 years ago | (#34703334)

Also, I love how he doesn't even bother to explain what Drupal is or why anyone should care. I mean, all the cool kids are already using it, right?

Re:Meh (0)

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

No surprise in mediocrity there. The author's web page and portfolio remind me of Geocities or Tripod or Fortunecity.

Drupal isn't user-friendly at all (0)

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

Have you ever seen a secretary or someone who only knows word processors try to update a website? Things like image aspect ratio, alignment, links... it's a nightmare. How often have we all seen links to files that end up pointing at something like "H://server/files/xyz.pdf"?

Not to mention that using WYWIWYG in a browser to edit the content always end up as HTML spaghetti which isn't only invalid, but can barely display within the compliant framework of the website itself.

Re:Drupal isn't user-friendly at all (1)

herojig (1625143) | more than 3 years ago | (#34706366)

>>Have you ever seen a secretary or someone who only knows word processors try to update a website? Yes, lots of them for the drupal sites that I develop. The cons u noted are just misleading. There is a drupal module that handles image aspect ratio, and the other "nightmare" adjustments you mention without the end user ever having to worry about any of that. As for editing content in a browser window, well, welcome to 2010.

Re:Drupal isn't user-friendly at all (1)

Rhaban (987410) | more than 3 years ago | (#34711154)

I don't understand your point... are you complaining that drupal without a wysiwyg editor is too complicated because a non-tech user can't be expected to, for example, properly put a file on a server then link to the correct url of that file?
Or that drupal with a wysiwyg editor allows a non-tech user to do what he wants (or what he thinks he wants...), resulting in auto-generated html that is not as efficient than if someone competent in html had hand-written it?

In short, what do you expect from a CMS exactly?

Drupal is user-friendly if properly set up. It is indeed very difficult to do so, as it requires a fairly good knowledge of the CMS.
But a properly set up drupal site is really easy to manage even for non-tech users. The problem is, very few sites are properly set up.

Re:Drupal isn't user-friendly at all (1)

yelvington (8169) | more than 3 years ago | (#34730670)

Have you ever seen a secretary or someone who only knows word processors try to update a website? Things like image aspect ratio, alignment, links... it's a nightmare. How often have we all seen links to files that end up pointing at something like "H://server/files/xyz.pdf"?

Not to mention that using WYWIWYG in a browser to edit the content always end up as HTML spaghetti which isn't only invalid, but can barely display within the compliant framework of the website itself.

What are you talking about? Oh... you don't know.

Drupal has awesome image-manipulation tools and filters that can clean up even the most heinous WYSIWYG Microsoft paste-bombs.

We are deploying Drupal to all of our newspaper sites in order to enable everyone to update appropriate parts of our sites. Our journalists don't know, don't care, and don't need to know any HTML. Our images are automatically sized, thumbnailed, positioned, lightboxed. Our links are automatically managed and validated.

Drupal is as user-friendly as the sitebuilder cares to make it. This is possible because there's a huge global community of developers contributing improvements all the time. Drupal 7 introduces major UI improvements and API changes that need to be thoroughly understood by this community of coders, which is why the reviewed book is significant. It is definitely not a book for beginners, or for you.

The problem is scripting. (0, Troll)

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

As any veteran of contemporary CMS (Content Management System) websites will tell you, they've still got a long way to go to match the performance and feature set of custom-coded websites.

Behind the scenes, most of these programs rely on a scripting language. These must be interpreted, which means memory is consumed and time wasted on processing the scripts time and time again, line for line, byte for byte.

The revolutionary new approach to creating a high-performance scalable website is to write it in C++ with hand-optimized assembler language algorithms. Yes, that's the same language game programmers and operating system designers use and for good reason: it's fast and it's ubiquitous. Let yourself be bound no longer by the limitations of statically-typed languages; use what the pros use and watch those hits fly.

Re:The problem is scripting. (2)

Lunix Nutcase (1092239) | more than 3 years ago | (#34702730)

write it in C++

Let yourself be bound no longer by the limitations of statically-typed languages

Ummm... what?

Re:The problem is scripting. (1)

mikestew (1483105) | more than 3 years ago | (#34704110)

Weird, huh? It's like the guy's selling something while not having a clue ("assembler language", huh?), yet...there's no sales pitch.

No - the problem is custom coded sites (1)

Bozovision (107228) | more than 3 years ago | (#34705698)

As any veteran of website Content Management Systems (CMS) will tell you, the problem is that custom coded sites are a nightmare in waiting for most customers. Unless you have a mega budget, and a team of developers, and the guarantee of the ongoing budget and team, you are much better off using a existing CMS. The security is likely to be better than with a custom CMS especially if there are lots of people contributing, the opportunities to grow the site through new functionality will be better, especially if it's open source, and the cost is likely to be less for more.

Behind the scenes most of CMS there is a database. Often, but not always, it's coupled to a scripting language, and usually it's organized in such a way that it's modular. This modularity is what gives non-custom CMSs their teeth, but compared to custom CMSs, the cost is that the queries on the database are non-optimal. Often data is read twice or more by different parts of the CMS because they aren't able to directly work together to retrieve the data in the way that a custom CMS can. It's this explosion of database queries which is usually responsible for any drop in comparative speed, and not the cost of executing scripts.

The revolutionary approach is not to waste time redeveloping stuff that other people have already built, but to reuse at low or no cost through the power of open source. It's almost always quicker, easier and cheaper to buy faster hardware and use a scripting language than it is to develop software in C++.

Some games and operating systems may be written in C++, but they have different needs and requirements, and operate in different environments; a formula 1 car is optimized for traveling around a race circuit, but it is useless when there are speed bumps.

Drupal represents tens of millions of dollars investment and is built by some of the world's best CMS developers. It takes a lot for a custom CMS to compete with that.

Disclosure: I'm involved in the Drupal project. I develop for Drupal. I've been developing for Drupal for 6 years. I have programmed in C++ and scripting languages. I have built custom CMSs. I've built sites in other CMSs. I threw away my CMS framework when I discovered Drupal, not because it was better, but because, even where it wasn't, the rate of growth of Drupal meant that it soon would be. The rate at which Drupal is developed far outstrips anything that all but the very largest companies can sustain. I would say that I'm a CMS veteran of contemporary CMSs. Whatever that means.

Re:No - the problem is custom coded sites (1)

sco08y (615665) | more than 3 years ago | (#34706608)

Disclosure: I'm involved in the Drupal project. I develop for Drupal. I've been developing for Drupal for 6 years.


So is Drupal 7 coming out (1)

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

before or after Duke Nukem Next?

Re:So is Drupal 7 coming out (1)

Arancaytar (966377) | more than 3 years ago | (#34702878)

They just put out a third release candidate, so I guess they're ahead. Took long enough, of course.

Re:So is Drupal 7 coming out (1)

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

OK, that's good to hear. It was taking so long, I stopped watching for updates.

Re:So is Drupal 7 coming out (1)

/dev/trash (182850) | more than 3 years ago | (#34727228)

Dries's birthday is the rumour.

No kidding (2)

sco08y (615665) | more than 3 years ago | (#34703212)

"modules, which can be thought of as add-ons that extend the capabilities of Drupal in specific ways — oftentimes in conjunction with other modules"

Just another day's work for... CAPTAAAAIIIIIIIIN OBVIOUS!

Stay tuned for our next episode where Michael explains what hypertext is and how to use a mouse!

I suppose, but haven't drupal devs already figured (1)

herojig (1625143) | more than 3 years ago | (#34706386)

I suppose, but haven't drupal devs already figured all this out? All the modules that I have put into a drupal site have a v6 production version, and a v7 development version out for testing. I guess I don't get the description here: "These APIs have changed with Drupal version 7, and thus Drupal coders could benefit from a book that explains how to create Drupal 7 contrib modules." Most already have!

Coder module (1)

Slur (61510) | more than 3 years ago | (#34708188)

I've been keeping up with the indispensible help of and the coder module [] !

Re:I suppose, but haven't drupal devs already figu (1)

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

*most* Drupal coders don't contribute modules back to They quietly make their own modifications, sometimes in the form of modules. I've contributed changes to Drupal modules but never actually a whole module, simply because I wouldn't want to maintain one. I've been waiting to mess with D7 until the RCs came out specifically because I don't want to try to hit a moving target. I would assume I'm not the only one. D6 works fine, D7 is already much nicer though, and I look forward to this new era of figuring out what they meant from the new documentation.

hook_perm() (1)

Slur (61510) | more than 3 years ago | (#34708182)

Hey man, the book does mean hook_perm() - but maybe it skipped over the part where it explains what the "hook_" part of "hook_perm" means. The "hook_" part is replaced by the name of the module. So, "user_perm()" is the "user" module's implementation of hook_perm(). Cheers!

Test 123 [sorry] (1)

owlstead (636356) | more than 3 years ago | (#34709540)

Trying desperately to post but /. letting me down. Using this uninformative article to test. Sorry sorry sorry, mod me into oblivion if you want to.

Nice! (1)

/dev/trash (182850) | more than 3 years ago | (#34727264)

A book about a unreleased version of Drupal. I'm sure it'll be simple to follow along.

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?