Beta

Slashdot: News for Nerds

×

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!

Foundation Drupal 7

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

Books 98

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

Some of the problems could only originate from the author. There are countless instances of weird and perplexing instructions, such as "log on and log in" (page 266). On one page alone (127), readers will encounter "Make sure the configure it after saving if applicable" and "Configuration, Languages should be screen text style." There are numerous errata: "postgresql" (page xvii), "blog" (page 15; should read "block"), "minimum the PHP requirements" (21), "Drupal 7-1 to 7-2" (35), "ä" (60), "of [a] single" (68), "of [the] fields" (74), "per-configured" (76), "a decimal [point]" (77), "be round[ed]" (77), "by [a] user" (83), "how which fields" (85), "requires updated or not" (131), "delimeter" (163), "ie" (175), "This [is] where" (196), "comments are will" (198), "aka" (226, 270, and 278), "is usually means" (240), "site to bake" (243), and "described in earlier in the chapter" (248).

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.

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

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

cancel ×

98 comments

Drupal (2)

Frosty Piss (770223) | more than 3 years ago | (#34957772)

Spaghetti code.

Cock lovers (-1)

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

Fuck Dupral, whatever it is...

Re:Cock lovers (1)

MightyMartian (840721) | more than 3 years ago | (#34958110)

That certainly explains your conception.

Re:Drupal (0)

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

Spaghetti code.

The retort:

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.

In a nutshell, Drupal is a pain in the ass because it has been built upon over time and seriously needs to be redesigned and rewritten to incorporate all of the "great power and flexibility". it's kind of like the "great power and flexibility" of a lot of object libraries that are a nightmare to actually use because they've gained their "great power and flexibility" from the hap-hazard add-ons over the years - there's nothing like trying to use a feature that won't work because namespaces clash - YUMMY!

Re:Drupal (0)

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

Don't worry, they've made it far worse in Drupal 7. Among other great ideas:

* They removed the ability for third party modules to validate comments. Apparently no one at Drupal has ever had the idea of writing a spam filter.

* You can no longer write SQL queries directly. Instead you must use their library, which bloats what used to be a single SQL query into at least three lines of object calls. More if you want to do joins. Which you almost certainly will if you're doing anything useful.

That's all I've run into so far. If you have the option, stick with your existing working Drupal, or just use a better CMS.

Re:Drupal (1)

MightyMartian (840721) | more than 3 years ago | (#34958360)

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

Re:Drupal (1)

sprior (249994) | more than 3 years ago | (#34959390)

Mollem (written by Dries himself) implements a spam filter and has a Drupal 7 release - wouldn't your first statement make this impossible?

Re:Drupal (0)

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

The bug report where the Drupal devs basically said "fuck you" to the guy trying to validate comments mention Mollem too. The issue is that Mollem doesn't just filter comments, it filters every single user-submitted block of text anywhere on the site. This happens to include comments.

I'm not sure how it does that since as far as I know there's no way to hook into that, so however it works, it's doing something that involves modifying Drupal's core. There's no API for filter comments any more. It was removed "by design" and will not be added back.

Essentially, if you're willing to hook into non-public APIs, you too can filter comments. But there is no official way to do it - there used to be, and it was removed.

Re:Drupal (2)

sprior (249994) | more than 3 years ago | (#34960050)

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.

Re:Drupal (1)

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

I guess things like hook_comment_update, hook_comment_insert are not good enough for you, you'd rather have a conspiracy theory that Drupal is somehow hiding its api ala Microsoft.

http://api.drupal.org/api/drupal/modules--comment--comment.api.php/function/hook_comment_insert/7 [drupal.org]
http://api.drupal.org/api/drupal/modules--comment--comment.api.php/function/hook_comment_update/7 [drupal.org]

Re:Drupal (0)

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

Those don't work for filtering comments, since those happen AFTER the comment has already been accepted. The best you can do with those is cause a server error, but you can't do anything USEFUL like return, say, a useful error message. (Since if you try, the comment will be submitted anyway once your hook completes.)

Let me guess, you must be one of the Drupal developers who declared removing existing functionality that people still used to be "working as designed." Because, after all, it's possible to hack something together that doesn't actually work.

Re:Drupal (0)

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

1. Use hook_field_attach_validate('comment, $comment, &$errors)

2. No one is forcing you to not be able to use db_query() and write the damn SQL yourself.

Try running into it harder.

Re:Drupal (0)

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

+5 true

CMS only half the issue... (0, Funny)

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

As a longtime Internet designer, I've seen any number of technologies come and go. Many of them only paper over glaring problems to today's developers, and CMS (or Content Management Systems) are no exception.

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

Enter C++. Today's best developers use C++ to build their webpages. It's the same language used to make operating systems and video games for a reason: it's fast. Even scripting languages are written in it. So why accept a redundant layer when you can make your home page the way the pros do? Use C++, and never look back!

Re:CMS only half the issue... (1)

MightyMartian (840721) | more than 3 years ago | (#34957866)

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

Re:CMS only half the issue... (1)

miknix (1047580) | more than 3 years ago | (#34958264)

Why fuck around with C++ when you can code it all in C, like CGI programmers did twenty years ago

Why to program webpages in C when you can do it in ASM?

Oh wait! I know where this is going...

Re:CMS only half the issue... (2)

cpu6502 (1960974) | more than 3 years ago | (#34959488)

Pentiums didn't exist 20 years ago (1990). People would have been using 80486s or 68040s (Macs,Ataris,Commodore Amigas) with a top speed of 33 or 40 MHz.

Re:CMS only half the issue... (0)

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

Uh, yes, CGI is a pain in the bum. But there's no reason a truly hardcore programmer would have to use the klunky CGI mechanism -- just write your own webserver in assembly/C/C++ !! Now that's speed!

Re:CMS only half the issue... (2)

kbielefe (606566) | more than 3 years ago | (#34958482)

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

Re:CMS only half the issue... (1)

JonySuede (1908576) | more than 3 years ago | (#34959662)

like... like google ?

Re:CMS only half the issue... (1)

musicmaker (30469) | more than 3 years ago | (#34962266)

Yeah, cos that's a typical use case... NOT.

Re:CMS only half the issue... (3, Interesting)

musicmaker (30469) | more than 3 years ago | (#34962270)

Have you looked at some of those folk infrastructures and white papers on 'cool' things they've invented to get around the unbelievable limitations of scripting langues and MySQL?

Re:CMS only half the issue... (1)

hawguy (1600213) | more than 3 years ago | (#34958752)

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.

Yeah, but it's Drupal. (0)

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

I can throw another 8 cores + 8GB of RAM at my Drupal installation for $2K

Multiply that by a few dozen boxes and you just might be able to scale!

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.

Having worked extensively with Drupal sites attempting to scale to thousands of users, no, by god, it is not. But it *is* doable. It involves being rather selective with contrib modules, not writing crap PHP, properly indexing and maintaining databases, and most importantly: Not having a core that's been hacked to hell by cheap 'developers' in random third world nations.

Supporting infrastructure certainly helps. You can't go wrong with having CDN offload, lighttpd/nginx over Apache, Varnish or some other solution for caching; potentially memcached (which more often than not, does NOT help and makes things worse - sorry, conventional Drupal community wisdom!)... But no matter what additional sexiness and what additional hardware you throw at Drupal, if you want any sort of viable scalability, it all comes down to code.

Re:CMS only half the issue... (0)

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

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.

PHP programmers are cheap? That's not what my paycheck shows.

Re:CMS only half the issue... (1)

musicmaker (30469) | more than 3 years ago | (#34962326)

I'm not sure if you're being sarcastic or not.

Assuming you're not:

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 pretty sure most of OS X is C, then Objective-C then some C++. Pretty sure BSD isn't, and looking at the Open Solaris site, looks like C, AIX, nope, True64, nope, OS400, nope. Windows, I'm fairly sure they sucked in a good chunk of BSD, which is C, and honestly, who cares about the rest of it, it's a piling of stinking shit, not too many folks who would disagree.

I think the only popular web framework I recall that used C++ to build modules was ColdFusion, and about a year later, they switched to Java.

Yes, but what we really want to know... (3, Funny)

XxtraLarGe (551297) | more than 3 years ago | (#34957832)

Is Robert J. Townsend a programmer's programmer?

Re:Yes, but what we really want to know... (1)

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

A programming programmer's programmer, programming programs?

Steepest learning curve ? (1)

foobsr (693224) | more than 3 years ago | (#34957850)

Up until now, I thought that Plone/Zope deserve this attribute.

CC.

Re:Steepest learning curve ? (1)

freedumb2000 (966222) | more than 3 years ago | (#34958468)

Oh yes. My theory is only the developers them selfs actually know how to use it.

Re:Steepest learning curve ? (1)

qpqp (1969898) | more than 3 years ago | (#34964040)

...and Typo3.

drupal compicated? (0)

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

LOL
what ever
It's more like useless as anyone can write their own CMS with PHP as PHP is set up for things like this

Re:drupal compicated? (1)

hazah (807503) | more than 3 years ago | (#34965478)

Right, cause writing a CMS is sooo bloody easy. You've only said this because you've never made an attempt to.

Sounds Like Drupal (2)

howlinmonkey (548055) | more than 3 years ago | (#34957950)

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.

Re:Sounds Like Drupal (1)

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

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.

Re:Sounds Like Drupal (1)

Hognoxious (631665) | more than 3 years ago | (#34963298)

Are you saying it's like the Star Trek movies, but backwards?

Re:Sounds Like Drupal (1)

kkruecke (540019) | more than 3 years ago | (#34962626)

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.

What opensource CMS's are good?

Re:Sounds Like Drupal (0)

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

How bout E107?

Re:Sounds Like Drupal (1)

kkruecke (540019) | more than 3 years ago | (#34968142)

Thanks, I'll take a look at it.

Re:Sounds Like Drupal (2)

petes_PoV (912422) | more than 3 years ago | (#34963960)

that style doesn't work well in a dead tree format

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 their hype and which ones are simply turkeys.

The dead tree format is a good way to separate the amateurs from people with a professional outlook. If people can't be bothered to describe what they've done, then what they've done is in all practical terms useless.

Re:Sounds Like Drupal (1)

loxosceles (580563) | more than 3 years ago | (#34965102)

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.

Learning cliff (3, Insightful)

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

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.

Oh yes, I've done the Drupal thing. Never again.

ditto (1)

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

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 used a custom code to implement the project. i wouldnt have even entered that route if client didnt want it, being recommended by hearsay that goes around the net through its zealots.

Re:ditto (1)

theskipper (461997) | more than 3 years ago | (#34961776)

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.

Re:ditto (1)

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

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.

Re:ditto (1)

theskipper (461997) | more than 3 years ago | (#34962584)

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.

Drupal is similar with respect to your experience level with computers. But in time, as you gain more experience with programming languages, try it again. It's a much different view once you see if from the big picture.

Best of luck.

Re:ditto (1)

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

best would be to illustrate the issue with an example. the code below in my signature, is a code that i have programmed just because of such stuff with various 'frameworks'.

check it out. and tell me how do you evaluate drupal's strength as such, as compared to the ease of use, curve and modifiability of the code you see in the signature.

Re:ditto (1)

RagingMaxx (793220) | more than 3 years ago | (#34962808)

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 function required to achieve this in your existing module. If you aren't developing a custom module for your client, it's likely that Drupal wasn't the best choice of CMS for the project.

In my experience Drupal is an incredibly flexible starting point for a medium/large web project. However, to take advantage of the major features of Drupal there is a significant learning period required as the system is designed differently from any other PHP framework I've had experience with. Whether you consider this learning period wasted time or a knowledge investment I suppose is a matter of opinion which will differ from web developer to web developer.

Personally I found it a very worthwhile "expenditure", and now use many Drupal concepts even in completely custom PHP projects where Drupal isn't a practical choice.

Re:ditto (1)

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

then check out the code in my link below at sourceforge, and tell me what you think about learning curve, modifiability, ease of use and expandability.

Re:ditto (1)

RagingMaxx (793220) | more than 3 years ago | (#34969682)

Since you've asked my my opinion I'll be honest with you, I'm not terribly impressed.

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 most cases for PHP frameworks this just involves extracting an archive into the proper directory and writing over any files that need to be updated. However in the case of your code that would mean writing over the config file, erasing my project's settings. I am aware that it's simple to backup a file before upgrading, but that's not the point. The point is that I shouldn't have to modify any core code to use your codebase in my project.

My third criticism would be code quality. Even in the brief reading of your code I found a bug (line 70, application_header.php) and I found that your files have closing php tags which in my experience is very bad practice.

All of these are criticisms of the code itself, and ignore the elephant in the room when it comes to Drupal: community. Drupal is in its 7th actual version. Experienced web developers have re-designed that project 6 times, keeping the successful concepts and replacing the ineffective ones with better solutions. There are scores of community maintained modules already available, some of which themselves are on their 4th or 5th version. Security updates are released regularly, as well as bug fixes and feature updates.

Even if your project were superior in quality, it would take a mammoth effort by a large group of people to make it more "efficient" to start a new project with your code than Drupal.

Kudos for putting the effort in, but you have a long road ahead of you and a large number of competing PHP frameworks that many people are already familiar with. If you are really keen to help people you might consider shifting your efforts to contribute to an existing PHP project? Just a suggestion, and coming from someone who has actually taken the time to look at your project.

Re:ditto (1)

unity100 (970058) | more than 2 years ago | (#34971970)

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 and present tables properly. it is proper for people who work in big corporate salary jobs, dealing with whatever their i.t. department is able to pass from management, which in turn generally end up the 'latest hottest', therefore not having to deal with very curious and intricate, odd requests of dev clients. however as someone who makes his pay in the trenches, i have seen that the caprice of many browsers + div+css can mean going into loss in a project whereas you could pass the hurdle easily by just implementing tables. client does not give a flying fsck about what's in there in behind, rightfully too - they are ok as long as their thing looks the same in as much devices and it can, and - note this part down - they dont want to spend much money for it. and no, you cant make them spend more money on browser compatibility with any reason or justification either - our justifications and self-righteousness as programmers in our own world, have little importance for the people outside it.

MOREOVER, and more importantly, despite it is clearly stated on the project website that code separates ALL design from tables, you still went on to link the oh-so-bad table usage on the website with the code and concept. which shows further shallowness. i could have made the project site one big whopping centered blinking text page, and it still would be separated from code.

The point is that I shouldn't have to modify any core code to use your codebase in my project.

and you dont have to. the core code stays as it is. you create new functionality through modules. i am translating an entire website that serves 10,000+ content from database for 6 years into that system, in just that fashion. i can lump the entire functionality of the website into a single module, or multiple modules, and all still would be totally self contained complete with their language, code, template files.

My third criticism would be code quality. Even in the brief reading of your code I found a bug (line 70, application_header.php) and I found that your files have closing php tags which in my experience is very bad practice.

further proof of your extreme elitism, which doesnt work well in the trenches. just like tables 'just work', closing php tags, also, just work. as for bugs, bugs are normal for weekend projects and BETA code.

Even if your project were superior in quality, it would take a mammoth effort by a large group of people to make it more "efficient" to start a new project with your code than Drupal.

doubtful. you talk of elephant in the room, yet you forget that what huge a mess and pile the drupal code has become over the years. just like any other code which was started as a hobby, but, was developed rather rapidly without any direction, guideline by many people. yes, there is huge functionality, yes there are a lot of modules, a lot of community support, and the code is still INEFFICIENT.

your concerns you expressed, apart from elitism, had centered on totally irrelevant things than the code you have seen was produced of - efficiency. as said, i am translating an entire website code, which was built more than 5 years ago, and with register globals, magic quotes and so on, in procedural fashion (no oop at all) into a module in this codebase, with mainly copy-pasting. and, whats important is, all the problems like register globals, spaghetti code and so on, are going away while im doing it, automatically. compared to running around jumping through hoops (!) in drupal for a single fscking web form look change, this is major efficiency.

If you are really keen to help people you might consider shifting your efforts to contribute to an existing PHP project? Just a suggestion, and coming from someone who has actually taken the time to look at your project.

there are enough people doing what you are talking about. i havent seen any people doing what i have done. and i have seen the need for it for over 7 years, during my professional career. i think you havent read the website's project description attentively.

Re:ditto (1)

RagingMaxx (793220) | more than 2 years ago | (#34972074)

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 other professionals for their opinions, and if you do, perhaps try to retain a modicum of courtesy in your response.

Re:ditto (1)

unity100 (970058) | more than 2 years ago | (#34972660)

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.

i do think that my code is better than drupal, joomla et al for hard practicalities of production environment in which you have to deal with small businesses or individuals' demands and needs. understandable - if i had been working in corporate environments or i.t. divisions in which i would be isolated from the demands and needs of clients in direct form, and had an i.t. manager or division fighting for what i think was right, i would also be approaching these like you do.

take the table versus div/css example. you can easily argue that it is better for usability to have less elements in a webpage, and then easily use div/css for positioning elements in such a clean interface and make sure it looks the same in many browsers and old devices as a corporate i.t. unit justifying it to management, but, as a professional who deals with clients directly, there is no way in hell that you will be able to do the same to a client who wants to put hundreds of elements, content items, listings in a single webpage. justifications, rationalizations dont matter at this point. client wants it, s/he will have it. even if you argue and persuade a few clients to what you think as the correct practice in your eyes, the third client will want it, and will have it. moreover, it is their right. and, you will end up having to place innumerable elements in the shifty div/css format, and will need to fight discrepancies here and there that may come up in random browser+device whenever you change something somewhere. in comparison, tables will stay where they are, as they are put, regardless of device, platform, software.

may sound ugly and unprofessional to you, in your current mindset. it is neither ugly, nor unprofessional. as i have said, the biases, justifications and rationale of us programmers do not have much importance in the eyes of the public.

the codebase you have reviewed, has been built to solve these problems. but, you have reviewed it with your conventional wisdom, which apply little in the world of practicalities.

Re:ditto (1)

FictionPimp (712802) | more than 3 years ago | (#34994370)

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.

You might disagree, but it's a harsh truth.

Re:ditto (1)

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

thats your unprofessionalism then. and your company's fault, if your company chooses what it will use based on the compliance of the websites of any solution with the established memes and fads.

not so much different from still logging in with wheel user to a *nix box and and then su ing to root.

Foundation (1)

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

Will the next book be titled Foundation and Empire: Drupal 8?

What does Drupal look like (1)

merlock18 (1533631) | more than 3 years ago | (#34958120)

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.

Re:What does Drupal look like (2)

theskipper (461997) | more than 3 years ago | (#34958202)

Seriously? http://www.whitehouse.gov/ [whitehouse.gov]

Re:What does Drupal look like (0)

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

That's not Drupal. If it were Drupal, http://www.whitehouse.gov/node [whitehouse.gov] wouldn't 404. But it does. Likewise, you'd be able to pull up nodes using URLS like http://www.whitehouse.gov/node/1 [whitehouse.gov] , but again, you can't.

Re:What does Drupal look like (1)

hawguy (1600213) | more than 3 years ago | (#34958820)

The Whitehouse claims (or at least claimed) that it's running Drupal:

http://techpresident.com/blog-entry/whitehousegov-goes-drupal [techpresident.com]

Perhaps Akamai helps hide some of the drupal-isms?

There are some Drupal tags in the HTML for the home page, but of course that doesn't prove anything.

Re:What does Drupal look like (1)

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

You realize it takes only 3 lines of code to hide http://www.whitehouse.gov/node [whitehouse.gov] ?

Re:What does Drupal look like (0)

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

There's a module that will disable any duplicate links if you're using clean urls or pathauto.

Re:What does Drupal look like (1)

cpu6502 (1960974) | more than 3 years ago | (#34959372)

From the front page:

Sites Made With Drupal
http://drupal.org/cases [drupal.org]

Re:What does Drupal look like (0)

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

http://drupal.org/cases

Re:What does Drupal look like (1)

FictionPimp (712802) | more than 3 years ago | (#34958234)

Whitehouse.gov comes to mind...

Re:What does Drupal look like (1)

sourcerror (1718066) | more than 3 years ago | (#34958292)

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.

Re:What does Drupal look like (1)

armanox (826486) | more than 3 years ago | (#34958408)

www.whitehouse.gov [whitehouse.gov] comes to mind.

Re:What does Drupal look like (1)

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

technically yes. But the back end? Not at all Drupal.

Re:What does Drupal look like (0)

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

Well in addition to the other links, here are a few of my own sites:

http://pauldarr.org
My personal tech/political blog. Drupal 6.

http://sbclp.org
The website for my county Libertarian Party that I admin. Also Drupal 6.

Re:What does Drupal look like (0)

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

I developed the Gabby Jack Ranch website using Drupal 6. It was chosen over other CMS systems because Drupal 6 allows for Multi-User / Multi-Roles / Multi-Blogs. In other words, you can have different users with different roles. And you can have a separate blog assigned to each user. I don't know if Joomla supports that feature now, but we moved away from Joomla because previously it didn't.

http://www.gabbyjackranch.org

Currently I am redeveloping the site using Drupal 7 and updating the style of the site a little.

http://www.gabbyjackranch.org/new

Still have a long way to go on that one. Only the front page has a template assigned to it. Still need to design and prepare the base template and other special templates. But, there is what I have.

House of Reps just standardized on Drupal (1)

snowwrestler (896305) | more than 3 years ago | (#34960020)

http://washingtontechnology.com/articles/2011/01/11/house-websites-go-to-drupal.aspx [washingtontechnology.com]

The House of Representatives will be moving all their sites to Drupal; the freshmen of the 112th Congress get theirs first. Here's one example:

http://brooks.house.gov/ [house.gov]

Re:What does Drupal look like (1)

gujjuguy (825157) | more than 3 years ago | (#34960142)

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.

Plenty of drupal sites listed here on Dries's website http://buytaert.net/tag/drupal-sites [buytaert.net]

Re:What does Drupal look like (1)

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

A Drupal site doesn't have to look like anything in particular (especially a stock Drupal site with a blue theme and "Drupal devil" icon).

Here's

a newspaper: http://observer.com/ [observer.com]
a magazine site: http://www.economist.com/ [economist.com]
a discussion site: http://dailypaul.com/ [dailypaul.com]
a parody site: http://www.theonion.com/ [theonion.com]

And some more: 45 Drupal Sites Which You May Not Have Known Were Drupal Based [socialcmsbuzz.com]

Re:What does Drupal look like (1)

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

the Onion is no longer a Drupal site.

I wonder why.

Whats up (1)

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

with the drupal hate on /.
Its a CMS people. If you hate it soooooo much then don't use it.

Re:Whats up (0)

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

The question is why use it at all? Why read a book about developing for Drupal when you can learn about developing for a language that can do what you want just as easily and so much more? If the CMS doesn't work out of the box with maybe some plugin installation, just forget it and make your own to do what you want. Its much much easier and don't let anybody tell you otherwise.

Re:Whats up (1)

kbielefe (606566) | more than 3 years ago | (#34959096)

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.

Re:Whats up (1)

kenrblan (1388237) | more than 3 years ago | (#34960758)

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

Re:Whats up (1)

musicmaker (30469) | more than 3 years ago | (#34962382)

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.

Re:Whats up (1)

musicmaker (30469) | more than 3 years ago | (#34962368)

90 thousand lines? Wow, what the hell are you writing in? ASM?

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 for usual constructs like Users and Roles, a database configuration and a base set of graphics.

Those 90 thousand lines of production tested code? Everybody's use case is different, and everybody pretty much has to write a custom extension at some point. As they say, a chain is only as strong as the weakest link, and anyone writing a module for a CMS is likely to produce a pretty weak link, no matter how well tested the base system is.

again? (2)

HeavensTrash (175514) | more than 3 years ago | (#34958190)

are /. contributors reading nothing but drupal books these days?

Re:again? (0)

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

Yup, it is money in the bank as far as I'm concerned.

My opinion having read that book (1)

Gizzmonic (412910) | more than 3 years ago | (#34958368)

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 will be a read for the ages, unlike this 'Drupal' nonsense which is clearly a fad.

Steepest Learning Curve?? (1)

ModernGeek (601932) | more than 3 years ago | (#34958760)

If Drupal has the steepest learning curve, what are they comparing it to? Myspace? Blogger? Wordpress?

Long gone are the days of the true Systems Engineers.

Learning Curve (3, Insightful)

lymond01 (314120) | more than 3 years ago | (#34959048)

"Drupal is oftentimes criticized for having the steepest learning curve."

That award goes to Plone. The curve looks almost like a backwards C.

Re:Learning Curve (0)

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

That award certainly goes to Plone, I worked with Plone for 3 years, the learning curve of Drupal is nothing in comparison! Just to theme plone 3 on the file system is incredibly convoluted.

Re:Learning Curve (1)

rgviza (1303161) | more than 3 years ago | (#34982786)

Agreed... Drupal is one of the easiest of CMSs to figure out.

Try dealing with interwoven...

Hosting Plans (1)

gorzek (647352) | more than 3 years ago | (#34959378)

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 using too many resources.

Re:Hosting Plans (1)

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

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.

Why the Drupal pushing ? (1)

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

i dont see other cmses get pushed here in slashdot. yet, its drupal every other month ? if not its version, its a book written on drupal.

why is this cms being pushed all over others in slashdot ? is someone from the admin crowd participating in drupal (gasp) development ?

In other words (2)

tgrigsby (164308) | more than 3 years ago | (#34959582)

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

That's just 21 years of programming talking...

Re:In other words (1)

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

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.

There is certainly opportunity for a superior CMS. Problem is, nobody seems interested in actually doing it.

Re:In other words (1)

Hognoxious (631665) | more than 3 years ago | (#34963472)

Furthermore, it's a given that anyone who was interested would be incapable.

This, of course, wouldn't stop them.

GROAN! Drupal -- never got into it (1)

pacergh (882705) | more than 3 years ago | (#34959584)

/rant

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 else. Still, like a moth to the flame I go . . .

Pro Drupal 7 Development -- (bad review) (1)

unil_1005 (1790334) | more than 3 years ago | (#34960110)

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.) Makes one really appreciate the work O'Rielly Press does.

Re:Pro Drupal 7 Development -- (bad review) (1)

Hognoxious (631665) | more than 3 years ago | (#34965886)

Well it got a below average score - usually everything scores 7/10.

I've read this book before. (1)

fucket (1256188) | more than 3 years ago | (#34960452)

In the end, it turns out that Drupal is the Mule.

Drupal Sucks (1)

LS (57954) | more than 3 years ago | (#34964056)

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 of them, and you'll be waiting a while. I18n is a disaster. No support built in, and the 3rd party module sucks. You have to have a separate node for each language, so multiple languages can not be edited simultaneously. So much seemingly core functionality is only provided by 3rd party modules, and the quality of the modules varies greatly. If you want to do anything more complicated than a blog or a magazine style website, you will be writing a ton of code.

Unless you want to use Drupal as is, avoid it at all costs. If you are going to use PHP, just build your site using a framework instead, such as Zend or Code Igniter or Yii or Agavi. You will have more freedom with the structure of your site, it will be faster, and you will understand how it works.

LS

Check for New Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...