Posted
by
samzenpus
on Friday January 21, 2011 @02:43PM
from the read-all-about-it dept.

Michael J. Ross writes "Of all the better-known content management systems, Drupal is oftentimes criticized for having the steepest learning curve. Yet that would only be a valid charge as a result of Drupal's great power and flexibility — particularly in the hands of a knowledgeable Drupal developer. But how can the interested programmer begin gaining those skills, as quickly as possible? One approach is to read and work through the examples of an introductory book, such as Foundation Drupal 7, written by Robert J. Townsend (except for a chapter contributed by Stephanie Pakrul)." Read on for the rest of Michael's review.

Foundation Drupal 7

author

Robert J. Townsend

pages

328 pages

publisher

friends of ED

rating

6/10

reviewer

Michael J. Ross

ISBN

978-1430228080

summary

A guide to getting started building websites using Drupal.

The book was published on 15 December 2010, under the ISBN 978-1430228080, by "friends of ED", which is both a division of Apress and arguably a baffling name for a publisher's imprint. The book's material spans 328 pages, grouped into 12 chapters and four appendices. The publisher's page offers a description of the book, and a link for purchasing the e-book version. Visitors can also read a few dozen of the least interesting pages in the book, using a lame modal interface "powered" by Google Preview's book viewer system. As of this writing, the author's own site for the book appears to have no useful content. In fact, even a few weeks after the publication of the book, the site had no word as to how to use the site or even obtain an account, and there is nothing pertaining to that in the book. Now, it appears to be the beginnings of a demo site.

The book's chapters can be loosely grouped into four parts: The first three chapters provide an overview of Drupal, and explain how to set up a local Web server, install Drupal 7 on it, and configure the new site. The material composes an adequate introduction, but there are some false statements readers should watch out for, such as: newly created blocks are added to nodes (page 15); "Drupal will not run on most inexpensive hosting plans" (pages 19 and 20); "server settings and update notifications must be configured" (page 35; actually, they are optional); "the default Garland theme" (pages 40 and 55; no longer true in Drupal 7); a block can be any shape (page 48; as long as it's a rectangle!). But the discussion on multisite setups — while likely intimidating for Drupal newbies — is well worth reading by anyone who has not yet tried running multiple sites from a single Drupal instance. However, the ."demo.d7" suffix (page 28) should have been explained. In the introduction, the author noted that the book is primarily intended for readers who have little or no experience with content management systems in general, and Drupal in particular. The early chapters hew to that approach, going so far as to briefly present the basics of databases — material that experienced programmers can safely skip.

Node fields, content types, taxonomies, users, roles, permissions, and modules (both core and contributed) are key components in building a site with Drupal — and they are explicated in Chapters 4 through 7. The narrative is quite descriptive, and readers new to Drupal may find some of it tough going; but it will be worth their while to read through all of the material, at least once, while exercising their newfound knowledge on a test installation of Drupal 7. Most of the discussion is clear and straightforward, but a few spots will likely perplex readers, e.g., "all search fields are hidden by default when either search view node is enabled" (page 85; what search view nodes?). Also, on pages 69 and 87, the author advises readers to limit a system name to seven characters, but each example given exceeds that number. Such inconsistencies can prompt readers to begin questioning the author's advice and attention to detail. As a resource perhaps unique to this Drupal book, the sixth chapter explores the purpose and basic usage of most of the core modules not enabled by the standard installation. Drupal newcomers invariably wonder what contrib modules they should first be trying out and learning, and the author presents several of them in the seventh chapter, which includes a helpful comparison of using the Webform module versus nodes for collecting data from users.

Nonprogrammer website creators — who must rely entirely upon the GUI of a content management system to build a site — are strongly influenced by the visual appeal of a CMS's built-in themes, and not necessarily its flexibility or other differentiating factors. (One can only speculate as to how many such people have chosen Joomla over Drupal based upon the former's more attractive default themes.) Thus, theming can be especially significant to non-technical Drupal site creators, and is covered in the next two chapters, the first of which was authored by Stephanie Pakrul. To illustrate the ideas discussed, she uses her own Vibe theme, which is a sub-theme of Fusion. Unfortunately, as of this writing, there are no releases of Vibe, so it is not clear how readers are expected to download it as instructed (on page 174). Consequently, readers won't be able to see on their own Drupal installations what she shows in the screenshots. This is just one more example of how this book appears to be unfinished. Some readers may become frustrated with the way that she often gives instructions but fails to identify the page on which to perform them. Also, the Skinr block settings shown in the book look nothing like what I am seeing using the latest versions of Fusion and Skinr, but that may be due to Vibe missing. Skinr's project page currently warns that it is not stable or functional for Drupal 7; this makes it a poor choice for a book aimed at beginners, who can be easily derailed by such problems. Several details are incorrect, e.g., the Firebug technique shown in Figure 8-14 does not use double-clicking, as stated, but simply mouse hover. Chapter 9 provides advice on using Photoshop and Illustrator CS5 for working with layouts, text, colors, and images in designing Drupal themes.

The last three chapters discuss topics related to deploying a site. Chapter 10, "Going Live," presents the details of the author's strategy for using separate sites for development, staging, and production. This involves executing Linux commands on the command-line, and at one point even deleting the public_html directory and creating a symbolic link. It is easy to imagine readers being hesitant about doing so — especially in a client's account — and for such people, using only an FTP application might be more palatable, even if it takes extra time. The next chapter offers some valuable best practices for maintaining a production site, including techniques to be automatically notified when installed modules become out of date. The last chapter, "Translating Business Requirements to Drupal Functionality," may at first glance seem inappropriately placed at the end of the book, because shouldn't the developer analyze the client's business requirements before beginning any work on their future website? But this chapter does belong at the end, because most of its topics will make a lot more sense to the reader after she has learned the basics of a Drupal site. The only confusing aspect of this material is the author's recommendation to add 25 percent to both the amount of estimated time to complete a project and also one's hourly rate, with no explanation for the rate increase. Nonetheless, the chapter presents some worthy advice on how to be a more effective Drupal site builder.

The book's four appendices briefly cover search engine optimization for Drupal sites; Drush (a command-line shell for Drupal); a survey of more than 50 useful contrib modules; and usage of the Views module to address some common query-building needs. Note that the Views carousel module — which is one of two image slideshow modules listed — was deprecated awhile ago.

All of the chapters except the first are capped off with summaries, which add no value to the book and consist mostly of unneeded reminders that begin with "I talked about," "I then talked about," etc. One of the summaries (page 214) states that a particular website was used as an example, but it wasn't even mentioned in the chapter itself. A strength of the book is that there are plenty of screenshots throughout, and most of them are helpful. But their captions typically repeat information stated immediately before the figure, and thus add unnecessary text.

Readers may become disappointed with an overall sense that the book was not crafted and edited properly, perhaps in a desire to rush it to market in order to cash in on the growing interest in Drupal and the release of Drupal 7. Any such urgency could account for the poor decisions in the production of the book. Some of the material appears unfinished, or at least unpolished. For instance, Chapter 1 ends quite abruptly, with no chapter summary, unlike all the others. The first part of a sentence on page 184 is completely missing.

It is not always clear as to which problems are caused by the authors, and which by the publisher. As a minor example, many of the module names are incorrectly presented in all lowercase (especially in Chapters 6, 7, and 11), in some cases rather pointedly (e.g., "cck") and in others a bit confusingly when in mid-sentence (e.g., "views"). Was that the author being sloppy, or an overzealous copyeditor who did not realize that title case is appropriate for the proper names of the modules?

The pace of explanation varies tremendously, from one section to the next. For instance, several paragraphs might discuss fundamental Drupal concepts slowly, with full explanations, and then only a page later the reader is entangled in fairly advanced topics, with little or no preparation. Many readers will find appealing the informal conversational style — although in a few instances the wording is unintentionally humorous, such as the phrase "most exciting" transformed into "most excitedly" (page xxi).

Other problems can only be laid at the feet of the publisher, such as incorrectly bolded words, even for individual characters in words (e.g., pages 87, 110, 233). The publisher chose to use the smallest font of any technical book I've ever seen, and consequently people with vision limitations may have difficulty reading the text. Also, many of the screenshots are rather pale; in most cases this is not a problem, but some of the images look fuzzy. In contrast (no pun), the image in Figure 9-4 is an unreadable black rectangle containing a stack of smaller gray rectangles, and the background is effectively indiscernible. Readers will wonder how the production team let that obvious problem slip through the cracks. The image used for Figure 4-15 evidently had its right side chopped off. Several of the pages contain small gray and brown lines, dots, and splotches; but those blemishes may be limited to my copy of the book.

Writing and releasing a book prior to the final release of the software, is always fraught with danger. Some of the Drupal-generated warning and error messages mentioned in the book differ from what would be seen using the final 7.0 version, which was not available to the author during the writing of the book. This is likely also the reason why the list of core modules (Table 1-1) is missing the Options module and includes the now-absent Profile module. But that would not explain why the critical System module is missing from the list. Also, the "Secondary menu" mentioned on page 56, is now gone, although secondary links are still part of Drupal 7. In terms of theming, the default site theme is Seven, and not the venerable Garland; also, the Minnelli theme (page 63) — Garland's fixed-width counterpart — was excluded from the final 7.0 release.

In essence, this book was not well executed, and yet it has a lot of promise. A second edition — perhaps for Drupal 8 — could rectify most if not all of these problems. The author's passion for Drupal is evident and inspiring: He shares hard-won and sincere advice for avoiding disaster in working with clients and working on their websites. Also, he notes in the introduction that 10 percent of all profits from the book will be donated to the Drupal Association. Although it is in much need of polishing — and in some places a full overhaul — Foundation Drupal 7 provides information and guidance that would be helpful to anyone who wants to learn how to use Drupal for creating websites.

I briefly tried playing with it as part of my website update project (moving from a custom and very awkward PHP-based system written by someone else), and abandoned it after a couple of days. I'm playing with Joomla now, which isn't a cakewalk but at least seems somewhat sensible (other than the fact that you still have to hand-edit CSS to get the look you want).

I'm no expert on Drupal 7, but in about 5 minutes I got the source for Mollom and found line 599 in mollom.module which shows how they hook mollom function into any form in Drupal which has been configured for it. I would think this is on the trail of what you want as comment submission would I assume be just another form that could be enabled for Mollom or something else you're planning to write. No special comment intercept needed - it's more generic now.

So far as I know, PHP is written in C. Why fuck around with C++ when you can code it all in C, like CGI programmers did twenty years ago, back in the dark ages, when they 100mhz Pentiums with 16mb of RAM and 100mb hard drives and dot matrix printers

I know what you mean. Slashdot, facebook, yahoo, wikipedia, whitehouse.gov, and all those other low-traffic scripting language powered websites are mere amateurish attempts. I demand a professional C++ website like, uh, help me out here...

Most CMSses are built on scripting languages. Scripting languages are typically interpreted -- line for line, byte for byte -- creating overhead.

Ahh, but PHP programmers are cheap and C++ programmers are more expensive.

And hardware is cheap - I can throw another 8 cores + 8GB of RAM at my Drupal installation for $2K, less than a week of a developer's salary. Maybe not the best way to scale to many thousands of users, but most people that are using Drupal only need to scale to hundreds (or 10's) of simultaneous users.

And why stop at C++, C is even closer to the hardware. Assembly language is closer still.

Given that simple job site searches yield a whole lot more results for Java positions first, then.NET then anything else relating to website development, which seems to fall mostly into the scripting languages arena, Ruby, Python, Perl etc. I've never seen a posting for a C++ web dev position in over a decade, and I'd be a candidate if there was, I'm pretty handy in C++.

What operating systems are written in C++? Linux sure isn't, I'm prett

Drupal is uneven, missing features that you would expect from a full CMS and enabling functionality via contrib modules that I have spent months coding in the past. Features show up that are clearly not ready for prime time and are slowly developed into useful modules that become a core part of the Drupal developer's toolkit. It really seems like the archetypal open source/agile project in that way. Unfortunately, that style doesn't work well in a dead tree format. It will be interesting to see if a second edition hits the shelves that fixes some of the glaring problems.

The real bummer about Drupal is that Drupal 6 has all the modules and has been extensively tested, but Drupal 7 has the nifty database layer... and few properly working modules of any complexity. Maybe by Drupal 8 new users will have a good shot with Drupal 7. It is pretty fantastic right now, though, if you want to put a basic site up with content management, and/or if the working modules do what you want done.

Drupal is uneven, missing features that you would expect from a full CMS and enabling functionality via contrib modules that I have spent months coding in the past. Features show up that are clearly not ready for prime time and are slowly developed into useful modules that become a core part of the Drupal developer's toolkit. It really seems like the archetypal open source/agile project in that way. Unfortunately, that style doesn't work well in a dead tree format. It will be interesting to see if a second edition hits the shelves that fixes some of the glaring problems.

The basic problem with Drupal is that most of the contributed code (modules) was written by people as a hobby. Once they've demonstrated their cleverness (hint: no-one cares how convoluted your code is, or how obscure, if mathematically correct, your nomenclature is) to their coding buddies, they lose interest. They stop fixing bugs - some modules have bug lists years long: I've added some myself that never got fixed. They won't or can't write documentation and it's impossible to tell which modules fulfill

A lot of drupal code is written by professional developers and web designers/consultants who build drupal sites for clients. It is more rarely a hobby. When modules are unmaintained, it's usually because it was a one-off module for a site, and the module didn't turn out to be useful for other sites. Maybe the developer or client realized it wasn't even good for the site it was intended for.

Of all the better-known content management systems, Drupal is oftentimes criticized for having the steepest learning curve. Yet that would only be a valid charge as a result of Drupal's great power and flexibility

That, or as a result of the time spent not quite getting that a CMS made it as far as version 6 with no core support for uploading images. Or the time spent installing an entire Russian doll stack of modules, with the whole thing ending up dependent on some dodgy alpha that hasn't been maintained since 2007. It'll do anything you want, but God help you if you want it to do anything.

i had attempted to use drupal 6 for a simple website that the user would use to publish this or that article. it turned to hell, when i learned that i had to conjure an entire module for just changing the looks of a web form that i was going to use, or hack the core files to change the looks of the form, or other horrible workarounds. when i got around that, and proceeded, i had come up against similar issues with other stuff that should be simple in any given platform. eventually, we had left drupal and us

Absolutely agree. If you're not a solid PHP programmer and don't spend the necessary time learning how hooks work, it's easy to run into the exact same experience you had. Drupal really isn't for the plug-and-play hobbyist crowd but a professional programmer can easily make it do what he wants.

FYI, for a snap-together site my best advice would be to try Wordpress next time. It's perfect for both hobbyists and non-technical folks. Hope that helps.

its not about 'skills' or professionalism or learning how things work. its how efficient things are. drupal, is not efficient, at any expertise level. with the time being spent doing things in drupal, much more can be done in some other platform in the same experience level. be it hobbyist, be it professional. time is a resource.

Yes, I can definitely sympathize with your perspective. I was there once too;)

It's similar to a weekend warrior trying to work on a racecar. Because of their lack of experience, the transmission looks inefficient, engine won't tune correctly, etc. It would be very frustrating to them, just as Drupal is to you.

But to the experienced mechanic it's completely different experience because they know it so intimately, and they're working with a top-notch framework to start with.

I have to disagree with your assessment of Drupal. The example you describe, changing the look of a web form, is incredibly easy using Drupal hooks. The fact that you have to create an "entire" module (which is probably all of 20 lines of code) to achieve this is actually one of Drupal's strengths, as it doesn't require any hacking of core code whatsoever. And since you are probably already developing a module to provide whatever custom functionality your client needs, you can just include the ONE functi

For a start, your project website is built using tables. This is enough to turn away most experienced web developers straight away (as it was for me the first time I visited your site several days ago).

My second criticism would be that your project is not set up with upgrading in mind. If I were to use your code for a project, I would expect regular security updates to the core code with a clear upgrade procedure. In mos

For a start, your project website is built using tables. This is enough to turn away most experienced web developers straight away (as it was for me the first time I visited your site several days ago).

and you lost all respect and credibility for the review you are going to make about the code for me there.

there is nothing wrong about tables. tables, stay where they are, in all devices, in the proportions they are set, and do not start changing entire looks of a page unlike when an element of a div/css mesh with relative/absolute positioning combination can do, and differently looking in all browsers due to the phletora of differences in between them. tables are old tech. oldest devices can recognize a

Typical slashdot, I actually take the time to review your code AT YOUR REQUEST, I politely give you my opinion, and you respond with personal attacks. Meanwhile, you fail to actually address my criticisms with any intelligent rebuttal. There are so many points I disagree with in your last post, but honestly, what would be the point of continuing this debate?

You obviously feel that your code is the best there is and any flaw must be in the eye of the beholder. My revised advice would be not to solicit oth

Typical slashdot, I actually take the time to review your code AT YOUR REQUEST, I politely give you my opinion, and you respond with personal attacks.

no, i am thankful that you took the time to review it. and what you read, were not personal attacks, but strong, hard professional criticism. you should also be thankful to me for that, since you seem to be a person who does php coding on the side, not as a professional, or in an environment that is isolated from the hard practicalities of the market.

all the points you raised, were addressed. if you go back and read, you will see that yourself.

Honestly, I have not reviewed your code, but I can tell you that a products homepage design weights heavily into if I look at a product. Using tables for layout is enough for my company to say "next" without even looking at the merits of your product.

Anyone got any web sites made by/with Drupal? Id like to see some of hte outcomes. I dont know anything about it but I want to look into it. Google was not help finding Drupal made web sites. I only assume Drupal.org is made by drupal but I would like to see more.

Here you can fond it: http://php.opensourcecms.com/ [opensourcecms.com]The site hosts a lot of different live-CMSes, so you can try how it feels from user/admin perspective. They're reinstalled every 2 hours, so nobody can mess it really badly.Of course these are minimalist installations without fancy plugins.

Anyone got any web sites made by/with Drupal? Id like to see some of hte outcomes. I dont know anything about it but I want to look into it. Google was not help finding Drupal made web sites. I only assume Drupal.org is made by drupal but I would like to see more.

Because it lets you focus your time on what makes your site unique, instead of on reinventing functionality that's common to 99% of all the sites out there. Throwing away 90 thousand lines of widely used, production tested code to make your own is rarely easier by any stretch of the word.

In addition to the common functionality, sometimes you need to put a website up that will need to be maintained by someone else in the future. You might not want to ever be called about the site again the next time a redesign or reorganization is in order. It takes far less time to put together a Drupal or Wordpress site than it does to custom code one. Believe me, I have done both methods. Once you get a good CMS site setup, less than technical users can usually keep the thing updated both with content and

Crikey mate, have you actually worked with any real users? Most folks don't even know what a security update is, where to get one, or why they would need it. Once they get hacked, IF they have a backup, they'll restore, and most of them will do nothing about it, some _might_ install security updates if they know that's possible, or if it shows up in a Google search for the problem they describe, if they are capable of using the language to describe it.

I have huge website projects with highly complex business logic and external API calls requiring lots of code that isn't typically in a website, and the biggest system I've worked on comes in at about 50k including the templates.

Most places I've worked at who do a lot of website projects that aren't in a CMS, and even some that are, have a standard base build that has all the foundation functionality in it. Basic login pages, database classes f

I kinda liked this book, but it's not as good as the one I'm working on. I am currently writing historical fiction about Sir Phineas "Thousand" Island, the inventory of thousand island dressing. Sir Phineas is a dashing adventurer who uses his signature dressing to fight crime during the Gilded Age. One of the most memorable scenes involves Phineas acting as a stand-in for Chester A. Arthur, and foiling an attempt on the President's life using nothing more than his wits and delicious dressing. Yes, it w

I don't know why the reviewer says the statement "Drupal will not run on most inexpensive hosting plans" is untrue. It's good advice for anyone intending to use Drupal. It is a heavy bit of software and uses a substantial amount of resources, more than most shared hosting plans will let you get away with. I run Drupal on a VPS and it works fine there. It is definitely not recommended for anyone on a shared hosting service. Get more than a handful of concurrent users and you'll most likely get booted for usi

You're absolutely right, drupal has always been a memory hog and while the excellent caching means being able to support oodles of non-logged-in users who are not creating content, trying to support many logged-in users simultaneously is painful.

"Of all the better-known content management systems, Drupal is oftentimes criticized for having the steepest learning curve. Yet that would only be a valid charge as a result of Drupal's great power and flexibility — particularly in the hands of a knowledgeable Drupal developer."

Of all the better-known programming languages, Assembly is oftentimes criticized for having the steepest learning curve. Yet that would only be a valid charge as a result of Assembly's great power and flexibility — particularly in the hands of a knowledgeable Assembly developer.

There. Fixed that for you.

Anytime someone tells me that a system has a steep learning curve, I figure the guy that developed it did it wrong. There's steep, and then there's ridiculous, and if you have to tell me that the learning curve is criticized for being steep, I'm going to assume that there are better solutions out there or that there is an opportunity for a better solution to be created.

I've read a few of these books in hopes of using Drupal for various projects. I always ended up throwing up my hands in frustration and using something other than Drupal.

Steep learning curve is right. I'd rather use something more simple, such as Wordpress, or code it all myself in Rails or PHP.

But I'll probably try once more to figure it out, and I might even buy this book. I mean, Drupal just sounds soooo bloody promising. But every time I try and use it for a project I end up using something els

Sorry to say this, but "Pro Drupal 7 Development" is the worst written technical book I've ever read.
It is very difficult to follow (somewhat like the Drupal code itself) even though I've already spent weeks hacking the internals.
The fact that is has been very poorly (if at all) proof-read makes it even worse: frequently the meaning of sentences is either changed or destroyed through lack of careful review.
All in all, it seems as if it when directly from the writers to print (no editor is mentioned.)

Drupal is terrible. Spaghetti code with global objects everywhere, inconsistent documentation, a complex form processing pipeline with almost no documentation and therefore extremely difficult to extend, and an unnecessarily complicated module API. The CCK is a nice idea in concept, but it's way too slow and unwieldy after a certain number of fields have been added. The amount of memory held by the form object is insane due to redundant data. Try adding or removing a field when you've already got fifty