Beta
×

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

Thank you!

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

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

Book Review: Drupal For Designers

samzenpus posted about 2 years ago | from the read-all-about-it dept.

Books 77

Michael Ross writes "Of all the open source content management systems used for building websites, Drupal has a reputation for being one of the most flexible and powerful available, but not the easiest for web designers to use. Drupal version 7 has made some strides in alleviating those flaws, but there is still much progress to be made. During the past few years, a number of books have been published that explain how Drupal designers can do custom theming, but they tend to focus on the technical details of the theme layer, and not the practice of web design when using Drupal as a foundation. That rich yet neglected subject area is the focus of a new book, Drupal for Designers: The Context You Need Without the Jargon You Don't." Keep reading to see what Michael has to say about the book.The book's author, Dani Nordin, is a Massachusetts-based web designer and the founder of The Zen Kitchen, a UX design business. The book was published by O'Reilly Media, on 1 August 2012, under the ISBN 978-1449325046. The publisher's page offers a description of the book, the table of contents, an author bio, and some free sample content (the first chapter). This publication is a compilation of three previously-released short guides — Planning and Managing Drupal Projects, Design and Prototyping for Drupal, and Drupal Development Tricks for Designers — with additional material. All of these books were written by Dani Nordin, and comprise the "Drupal for Designers" series by O'Reilly Media. (My thanks to the publisher for a review copy of this particular title.)

The book's material spans 328 pages, and is organized into seven parts, which do not include the introduction or the first chapter. The seven parts — each comprising at least two chapters — are largely presented in the same order that a typical reader would want to learn and implement the recommendations: Discovery and User Experience; Sketching, Visual Design, and Layout; Setting Up a Local Development Environment; Prototyping in Drupal; Making It Easier to Start Projects; Working with Clients; and Sample Documents.

Unlike most introductory Drupal books, this one wisely begins with a helpful dictionary of Drupal terminology. The first chapter also discusses the phases that compose a typical Drupal project lifecycle. Sandwiched in between is some guidance on where to place custom code in a Drupal directory system. The author advises that "Any module, theme, or other customization that you create for your site should always reside in sites/all" (page 2, and also reflected on pages 1 and 5). That may be true of contrib modules and themes, but certainly not custom ones, which are better located in sites/default or sites/[domain name]. She states that a child theme should be "stored separately in sites/all/<client_name>" (page 4). Actually, they should be placed in "sites/default/themes" or the themes subdirectory of a domain name directory. Finally, she recommends that for a multisite installation, one should keep "everything in sites/all" (page 5). Lumping everything into the "all" subdirectory would defeat the fundamental mechanism of multisite, which allows one to host multiple sites on a single Drupal installation, with their custom files and settings separated by domain name.

The first part of the book is loaded with valuable counsel on how to conduct the discovery phase of a website project, including coverage of project goals, user experience (UX), mockup tools, user personas, wireframes, prototypes, and the key components of a short-form project brief. It is evident from the narrative that the author is drawing upon a great deal of real-world experience, as well as lessons learned from other veteran web designers. The only blemish is where the author refers to "the project brief in Section 8" (page 45, repeated on page 254), and yet there appears to be no such section in the book. Perhaps she means Appendix A, which has an example project brief.

Once a design team has completed and received sign-off on a project brief — as well as any wireframes and other helpful preliminaries — a logical next step is to build the initial visual design. In the second part of the book, the author demonstrates how she uses sketches, style tiles, layout elements, greyboxing, grid systems, and Fireworks templates for crafting a visual design for a website. Throughout these chapters, she uses a redesign of her own personal website to illustrate the material. Both this part and the previous part of the book contain little information that is specific only to Drupal; thus, it could be useful to designers building websites using other CMSs.

Some readers of the book may already have up-to-date Drupal environments installed and configured on their development web servers. For those who do not, Part III will likely be appreciated, especially if the reader is using a Mac machine, because that is the environment to which the text and screenshots are geared. The author contends that "Windows seems to add an annoying layer of complexity to most of the command-line stuff" (page 102). Yet from my own experience, installing and using Git and Drush on a Windows PC is largely the same as in a Linux environment. Most developers complain that the main hurdle is Git's unintuitive workflow, which is independent of the operating system. The author touches upon some other tools, such as LESS and phpMyAdmin. Chapters 9 and 10 focus on Drush and Git, respectively. The last chapter in this section steps the reader through installing MAMP and Drupal. The discussion is generally comprehensible, except for the first paragraph on page 132, which is arguably the most confusing in the entire book. For instance, echoing a misstep seen earlier, it advises that all changes to your Drupal site should be stored in the sites/localhost directory, which contradicts the advice on the previous page, that all customizations to the site should be located in the sites/all directory.

The fourth part of the book covers prototyping in Drupal: gleaning from the client the information needed to define the content types for the website; choosing the appropriate modules for implementing the desired functionality; using views for displaying data; improving the HTML generated by views; creating custom Drupal themes; and using LESS to better manage the CSS within a theme. The advice is on target, except for the recommendation to use the Submit Again module, which does not have a Drupal 7 release, and has been replaced by the Add another module. Readers who are having difficulty locating the User Reference module mentioned by the author (page 187), can find it as a submodule in the References project. Lastly, the author instructs the reader to enable any base theme used (page 217), but actually it does not need to be enabled; installation alone is sufficient.

Part V, the briefest of them all, explains how to utilize the Features module, as well as Drush Make and installation profiles. Part VI comprises three chapters which offer guidance on how to propose an estimate for new projects, how to push back on unreasonable client requests, and how to learn from and document a finished project. This material is so closely related to that presented in the first part of the book — project discovery, planning, project briefs, etc. — that these final three chapters should have been incorporated into that earlier part. In fact, the first paragraph of this part states that it describes a phase of the discovery process that should be conducted prior to the phase described in Part I. Nonetheless, the author provides smart tips on some of the more difficult aspects of project management. The last part of the book comprises three appendices with sample documents — specifically, a project brief, a work agreement, and a project proposal.

On the publisher's page for the book, no errata have been reported, at this time. That is likely because the book appears to contain remarkably few errata: "What if there was" (pages 81 and 245; "was" should be "were"); "get familiar [with] the command line" (page 108); "a couple of" (page 172; should be "a few," as it is referencing three bullet points); ".less" (page 208, twice; should be "LESS"); "carpal tunnel[s]" (page 231); "original code [for] a feature" (page 242); and ".tpl" (page 266; should be ".tpl.php"). This is certainly a low number of errata for a technical book of this size. Kudos to the author and the O'Reilly editing team.

Overall, the book's style is clear and conversational, with only a few rough patches. Incidentally, the terms "directory" and "folder" are synonymous, but newbie readers who do not understand this could be confused when the two terms are used interchangeably, especially within the same sentence (e.g., page 109). Interspersed at various points in the text are interviews with people involved in web design, entitled "From the Trenches," which add perspective from designers other than the author. The reader will also find some natural humor and humility, which is always welcome in a technical work.

The author and publisher have made good use of the many screenshots, showing sample designs, Drupal user interface pages, etc. Unfortunately, for the Drupal pages, the admin theme used is the default, Seven, which results in black text on a gray background — a poor choice for such wide screenshots being compressed into small images on the page. Consequently, much of the text is barely legible, especially for anyone with imperfect eyesight.

From a technical point of view, the information provided is accurate and worthwhile. The only serious problem is the misleading advice, noted above, concerning the placement of custom modules and themes within the directory structure of a Drupal project — which was undoubtedly unintentional. The reader will encounter some HTML markup, a lot more CSS, and a minimal amount of PHP code. All of it is neatly formatted, and the only apparent problem is where a snippet of example code includes invalid nested "<?php" tags (page 188).

Despite these minor blemishes, this is one of the better-written Drupal books on the market. Web designers who will be working on Drupal projects, should be well rewarded in choosing this book as a solid starting point for their studies.

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

You can purchase Drupal for Designers 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 ×

77 comments

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

Drupal Logo (4, Funny)

Evelas (1531407) | about 2 years ago | (#41171779)

The Drupal Logo is formed from the tears of unsuspecting developers forced to use it.

Re:Drupal Logo (0)

Anonymous Coward | about 2 years ago | (#41171831)

I would much rather use Drupal than Wordpress.

Re:Drupal Logo (1, Insightful)

fiannaFailMan (702447) | about 2 years ago | (#41172157)

I would much rather use Drupal than Wordpress.

Bully for you.

Drupal is the James Joyce's Ulysses of CMSs. A small group of people (usually with too much time on their hands) have mastered it and like to blow about how great it is (implying their own greatness by extension). But most people who have tried it have fought their way through one chapter before coming to the conclusion that it's a load of unintelligible, over-engineered, pretentious crap, and then giving up in favor of something more accessible since there is a limited amount of time in this life and stuff still has to get done.

Re:Drupal Logo (1, Troll)

hazah (807503) | about 2 years ago | (#41172929)

Insightful?! Hardly, more like hateful and without anything to back the strawmen. Sounds like this man failed to use Drupal. Disclaimer: I do work for a small print/web media shop, and for web, we consistantly choose (that's right, we have options) Drupal (7 for every new site). A small number of sites are of other systems (Wordpress, CakePHP, custom, ...). Since we can't afford to dick around (time is money) we use the tools that are within our reach and that deliver. Now, I don't exactly know where he's coming from, but I'll admit that I had that attitude towards Drupal. I didn't like (and still don't, but can respect) Drupal 6 and below. It didn't take long to actually appreciate it for what it is: The right tool for a great many tasks.

If you genuinely dissagree, perhaps you should point out an actual deficiency so that, I don't know, it could be improved or something... just a thought.

Re:Drupal Logo (1)

fiannaFailMan (702447) | about 2 years ago | (#41173117)

I already have pointed out the glaring deficiency. It's over-engineered and so complicated that it's almost unusable. In fact I have a site in Drupal (I was able to muddle through eventually) but I still want to migrate it to Wordpress.

Re:Drupal Logo (2)

hazah (807503) | about 2 years ago | (#41173335)

What aspects are 'over engeneered'? What aspects are 'so complicated'? You haven't pointed anything out. You have made general, blanket statements without actually discussing what, concretely, you mean. I find a lot of the 'complicated' tools to be extremely powerful in what they do, so I'm not sure what makes you justify that point. Therefore, I have asked.

Re:Drupal Logo (0, Troll)

fiannaFailMan (702447) | about 2 years ago | (#41173715)

What aspects are 'over engeneered'? (sic) What aspects are 'so complicated'? You haven't pointed anything out. You have made general, blanket statements without actually discussing what, concretely, you mean. I find a lot of the 'complicated' tools to be extremely powerful in what they do, so I'm not sure what makes you justify that point. Therefore, I have asked.

Asked and answered. All of it is collectively over-engineered. Not one particular feature. The whole bloody lot. The overall architecture. The overall structure. The fact that you can't do anything useful with it until you understand all of it. Sure UNIX can seem complicated to the first-time user, but at least you can still do useful stuff even if you only know one or two commands. But Drupal? Forget it! It's a big steaming pile of over-rated shite.

Re:Drupal Logo (0)

drinkypoo (153816) | about 2 years ago | (#41176895)

Asked and answered.

Emphasizing the "Fail" in your nickname, eh?

All of it is collectively over-engineered.

You need to provide a supporting argument. Also known as "put up or shut up".

The fact that you can't do anything useful with it until you understand all of it.

What? You're full of shit. You download core, you unpack it and read the install files, you can have a working site up and running within fifteen minutes. I did under Drupal 4.7, and it's only gotten better since. You can be up and creating content like pages and blog entries in that time without any trouble.

Sure UNIX can seem complicated to the first-time user, but at least you can still do useful stuff even if you only know one or two commands.

To suggest that Unix is more apprehensible from the login prompt than Drupal is from the documentation is pathetic at best.

Forget it! It's a big steaming pile of over-rated shite.

You're a big steaming pile. Drupal is simple to use and extend. I am a totally crap programmer and even I can do it.

Re:Drupal Logo (1)

LS (57954) | about 2 years ago | (#41178567)

I spent several months trying to port a site to Drupal. And it didn't work. There you go: One great example of where Drupal fails. If you want to build something in Drupal, you gotta do it from scratch, and you gotta do everything the Drupal way. And there's a lot of shit you can't do in Drupal. I have node types on my site that support 100 fields. Do you know how much memory Drupal takes when you load up a CCK form with 100 fields? And how does drupal support multiple languages? Instead of supporting multiple languages per node, you have some hacked up shit where multiple nodes are tied together (At least when I was working with 6). And if you want to edit two languages at once, you have to dig into the heart of the mostly undocumented form engine and load two nodes at once. Which didn't work because it maxed out my PHP install's memory. Why the fuck is Drupal taking several tens of megabytes for only 100 fields?

And then you get to the code structure. It's not object oriented. There are global variables everywhere. The names of variables are completely unintelligible and the depth of data structures is heinous. It's the definition of spaghetti code.

Ok, if you are a CMS jockey and every $3k site you build is pretty much the same with a different skin, then yes, Drupal is great. But if you are an actual developer, and need to do a lot of custom things, then try a real framework like Zend, or Codeigniter, or Laravel, or Yii, or even another CMS, like ModX or TomatoCMS or Pimcore. But for god's sake don't waste your short life by dipping into the cesspool that is Drupal.

I ported my site to Zend in under two weeks. While it's not the least resource intensive framework, it is rationally designed around OO patterns, and the code comes out beautiful and maintainable.

Is that specific enough for you?

Re:Drupal Logo (1)

drinkypoo (153816) | about 2 years ago | (#41179033)

n't do in Drupal. I have node types on my site that support 100 fields. Do you know how much memory Drupal takes when you load up a CCK form with 100 fields?

If you're collecting that much data you use a webform via that module.

And then you get to the code structure. It's not object oriented. There are global variables everywhere. The names of variables are completely unintelligible and the depth of data structures is heinous. It's the definition of spaghetti code.

I'll agree that the code could be less impenetrable. It's gotten better, it's getting better.

Is that specific enough for you?

Yes, that's much more informative than "it didn't work for me and I didn't like it".

Re:Drupal Logo (1)

mmsimanga (775213) | about 2 years ago | (#41179059)

In short, use the right tool for the right job.

Re:Drupal Logo (1)

hazah (807503) | about 2 years ago | (#41186397)

If you want to build something in Drupal, you gotta do it from scratch, and you gotta do everything the Drupal way. And there's a lot of shit you can't do in Drupal.

I'm very curious about this... honestly this does not describe any experience I've ever had. Once the design of the site was completed, thus far I've only encountered minor obsticles. What couldn't you do?

I have node types on my site that support 100 fields. Do you know how much memory Drupal takes when you load up a CCK form with 100 fields?

If you had bothered to note, a 'field' within drupal translate to an entire table. It's a rather important implementation detail. You modeled something to contain 100 joins, so what is so surprising about the performance hit?

And how does drupal support multiple languages? Instead of supporting multiple languages per node, you have some hacked up shit where multiple nodes are tied together (At least when I was working with 6). And if you want to edit two languages at once, you have to dig into the heart of the mostly undocumented form engine and load two nodes at once. Which didn't work because it maxed out my PHP install's memory. Why the fuck is Drupal taking several tens of megabytes for only 100 fields?

Perhaps you should have realized you were using the wrong tool for the task? Seriously. Drupal had been built with a veriety of use cases in mind. There are plenty, but they hardly cover every single case. Quite obiously nodes did not fit the data model you needed. Frankly neither was Drupal. I sincerely appologize that you had to discover it the hard way, the failure was yours, however.

Ok, if you are a CMS jockey and every $3k site you build is pretty much the same with a different skin, then yes, Drupal is great. But if you are an actual developer, and need to do a lot of custom things, then try a real framework like Zend, or Codeigniter, or Laravel, or Yii, or even another CMS, like ModX or TomatoCMS or Pimcore. But for god's sake don't waste your short life by dipping into the cesspool that is Drupal.

Now you're just insulting. I'm no jokey. And it doesn't take much to make something interesting. You simply lack imagination, and probably, education.

Re:Drupal Logo (1)

LS (57954) | about 2 years ago | (#41200491)

If you had bothered to note, a 'field' within drupal translate to an entire table. It's a rather important implementation detail. You modeled something to contain 100 joins, so what is so surprising about the performance hit?

After several months of effort I dug in quite deeply, but didn't make it to the point of realizing that there were 100 joins occurring, because I realized that drupal was a piece of shit before I had to figure that out. Seems like an idiotic way to implement it in any case. Any insight into that design decision?

Perhaps you should have realized you were using the wrong tool for the task? Seriously. Drupal had been built with a veriety of use cases in mind. There are plenty, but they hardly cover every single case. Quite obiously nodes did not fit the data model you needed. Frankly neither was Drupal. I sincerely appologize that you had to discover it the hard way, the failure was yours, however.

Unfortunately that is not how it is sold by most drupal advocates. During my many months of experimentation, I asked dozens of questions and read thousands of forum threads, and everyone seemed to push that anything could be done in drupal if you knew the right way to do it. This "right tool for the job" thought process is something I haven't heard in regards to Drupal until very recently. But in that case, why not use a much less obtuse CMS like Pimcore or TomatoCMS or Symfony or ModX? A hammer is the right tool for hammering nails, but some hammers are made from glass, and they are not the right tool for ANY job. They are shit.

Now you're just insulting. I'm no jokey. And it doesn't take much to make something interesting. You simply lack imagination, and probably, education.

Interesting that you take this as a personal insult when I don't even know who you are. I've got a degree in computer science and engineering from a top 10 university in the US. I've worked on antivirus for symantec, printer firmware and drivers for HP, and have built websites with over 30 million uniques per day. I've built CMS systems used by 27 different hotel brands. I'm not saying that makes me better than you. But it just goes to show that you have serious judgement problems, especially when you are so willing to tie such a sorry excuse for a framework to your personal self worth.

Re:Drupal Logo (1)

hazah (807503) | about 2 years ago | (#41206309)

Interesting that you take this as a personal insult when I don't even know who you are.

A mistake on my part. As slashdot's crowd contains pretty much every single type of asshole on the spectrum, I think the back of my mind I gravitate towards a harsher stance than I intend. My appologies for jumping the gun, it's obvious that you are neither unimaginative nor ignorant. Let me put to bed the notion that my self worth is somehow involved. My foot is squarely in my mouth, my friend :)

After several months of effort I dug in quite deeply, but didn't make it to the point of realizing that there were 100 joins occurring, because I realized that drupal was a piece of shit before I had to figure that out. Seems like an idiotic way to implement it in any case. Any insight into that design decision?

Yes, I have some insight. It would probably warrant a very lengthy discussion. The TL;DR version is basically that it's meant for being a generic building block. One the one hand you can have a table per node type, on the other one table with joins to the auxhillery data. From a system maintanance perspective, the trade off is for the most common use case -- a content type with a number of fields, potentially. With this in mind, fields are not the right tool for a 100 columns, but, as you've noted, there's still a way provided by Drupal to tie in another table into the mix. So you could have had your 100 fields without all the overhead of custom fields. That, my friend, is why the lot of them tell you that actually can do this. Figuring out how is a whole different story.

At any rate, I will deny that Drupal is an "obtuse" CMS. It hardly functions as one, I find working with it is closer to working with a framework. We never dropped the system on a client without taking the time to create a simplified admin interface.

I will not argue whether "everything" can be done in Drupal... Honestly I don't know what kinds of things you're building. But I will say that if you can do it in PHP, you can do it in Drupal. The whole module system it has is actually quite flexible in this regard. You yank out everything but the core (or even the core -- as some distributions have), and apply a number of lean modules that do only what you need them to do (no extra queries, nothing behind the scenes, just the hooks system). You can completely do away with practically all of the stock modules. Chances are you would still find a few useful ones though.

I hope this puts some perspective on what I'm trying to get across. By no means do I come from a 'fanboy' position. I used to hate the bloody thing too. I stopped once I saw what I could do with it. Now, with a number of completed projects under my belt, I get things going pretty quickly these days so that the rest of my team has something to style.

Cheers

Re:Drupal Logo (0)

Anonymous Coward | about 2 years ago | (#41173395)

Drupal is not really "over-engineered" in any useful way. It's a actually huge pile of old-school unstructured PHP code, with no real data structures and an inscrutable execution model. Surely there's a happy medium between AbstractFactoryFactories and passing around multi-dimensional arrays and hitting MySQL hundreds of times per page because "MySQL is fast".

Re:Drupal Logo (0)

Anonymous Coward | about 2 years ago | (#41176807)

Drupal = poo pal

I've used it and its more crap than this site.

Re:Drupal Logo (1)

hazah (807503) | about 2 years ago | (#41180233)

How frigging informative of you. Good job. Go pat yourself on the back now.

Re:Drupal Logo (1)

manu0601 (2221348) | about 2 years ago | (#41174773)

But most people who have tried it have fought their way through one chapter before coming to the conclusion that it's a load of unintelligible, over-engineered, pretentious crap

As someone who gave a try to Drupal, I would mod you up 'informative".

This thing is fine if you want to do a community website. If you are looking to customize it for something else, you will suffer. And you will never upgrade because you fear everything will colapse. We now use SPIP [spip.net] with much more satisfaction.

Re:Drupal Logo (1)

LS (57954) | about 2 years ago | (#41178711)

Thought you might appreciate this [blogspot.com]

I agree, Drupal is a steaming load. The only people who dig it haven't actually worked with maintainable well-engineered OO systems. Drupal seduces you with a facade of broad functionality but turns out to be a morass of bad architecture underneath. It is useful for run of the mill CMS sites, but anything slightly custom and you are fucked.

Re:Drupal Logo (1)

Anonymous Coward | about 2 years ago | (#41171935)

Hey, customizing a Drupal installation is only twice as hard as writing your own CMS.

Re:Drupal Logo (0)

Anonymous Coward | about 2 years ago | (#41172153)

It's also 1/2 as hard as using Plone or one of those J2EE abominations tho (but at least Plone is bulletproof and doesn't eat webserver resources like peanuts). It's a nice tradeoff between 'robust', 'secure' and 'cheap to host' and userbase reflects it. Most Java and .net CMS-es are heavily leaned from the latter two (and not so great in the first one) but are still popular. Most people use Joomla which, from a security standpoint, is a slice of ementaler and still not THAT easier to theme.

Re:Drupal Logo (1)

girlintraining (1395911) | about 2 years ago | (#41171977)

Actually, it's made out of previous failed Java projects where the design team thought it'd be a good idea to code the server portion of the app in it as well. The tears are what the Logo is thrust into after it has been forged in the hell furnaces below the marketing department. But I can understand how you were confused; The Drupa Loompas do not often tell the tale to younger developers. You have to grok the full meaning of the phrase "a simple matter of programming" in a rite of passage known as the Annual Meeting before you're initiated into the Drupa's inner circle.

Re:Drupal Logo (1)

fiannaFailMan (702447) | about 2 years ago | (#41172075)

I wrestled with that Drupal crap for six months before giving up and trying Wordpress. I had my Wordpress site up and running and doing everything I needed within 20 minutes. I don't know why people put themselves through Drupal. Having to understand "vocabularies" and "taxonomies" and all the other baffling entities - by the time you get as far as that level of defining everything down to the last atom you might as well have used Dreamweaver or hard coded the site by hand.

Re:Drupal Logo (2)

Hewligan (202585) | about 2 years ago | (#41172317)

If you seriously couldn't work out how to produce the equivalent of a Wordpress site using Drupal in six months then - and I hate to be the one to break this to you - I don't think Drupal was the problem.

Re:Drupal Logo (-1)

fiannaFailMan (702447) | about 2 years ago | (#41172801)

If you seriously couldn't work out how to produce the equivalent of a Wordpress site using Drupal in six months then - and I hate to be the one to break this to you - I don't think Drupal was the problem.

No. Drupal was the problem. Like I said elsewhere, it's a load of over-engineered shite and anyone who sings its praises is a stuck-up condescending twerp.

Re:Drupal Logo (0)

Anonymous Coward | about 2 years ago | (#41172855)

Incorrect. The gp was right, bad carpenters blame their tools.

Re:Drupal Logo (0)

fiannaFailMan (702447) | about 2 years ago | (#41173099)

Incorrect. The gp was right, bad carpenters blame their tools.

No he's not. Some tools just suck. Period.

Re:Drupal Logo (2, Informative)

Ice Station Zebra (18124) | about 2 years ago | (#41174463)

Yep, some tools just suck, until you find that it really is better to have the right tool than using your hammer for everything. In the web world, wordpress is like the first php script you wrote and told all your friends (from your basement), "Hey I connected to a mysql database." Joomla is your first attempt at making it better. Drupal is when you finally get smart, it is the toolbox you always open when you want to get work done.

Now that the Drupal core is going to incorporate a lot of the Symfony2 framework in version 8 it is going to rock even more. This is another reason I like Drupal, they aren't afraid to shake things up rather than just piling shit on top of shit (wordpress/joomla).

Re:Drupal Logo (0)

Anonymous Coward | about 2 years ago | (#41175393)

Not a huge fan of either Drupal or Symfony, but that sounds like exactly what Drupal needs to stop being such a clusterfuck.

Re:Drupal Logo (1)

Elminster Aumar (2668365) | about 2 years ago | (#41177129)

Yet another comment / response that it full of empirical data.

Re:Drupal Logo (1)

Skadet (528657) | about 2 years ago | (#41173415)

You sound like a real gem.

Re:Drupal Logo (1)

fiannaFailMan (702447) | about 2 years ago | (#41173725)

You sound like a real gem.

Ouch. That hurts. That is like a dagger through my heart.

*snore*

Re:Drupal Logo (1)

Elminster Aumar (2668365) | about 2 years ago | (#41177153)

Is that all you have? I mean, is that your thing? Nothing but a bunch of baseless crap responses meant to stoke your ego and act as a smokescreen to hide the fact that you can't overcome your pride and admit to knowing nothing about a system you accuse of being a mess? Instead of being another petulant little visitor of this website who goes around and leaves a mess of their own, why not shut the hell up and ask mature questions about the issues you struggled with prior when you used Drupal (or any other system even)? Maybe that way, you can get your head out of your ass long enough to learn something that can help you have better replies on here?

Re:Drupal Logo (1)

fiannaFailMan (702447) | about 2 years ago | (#41182955)

Yes dear.

Re:Drupal Logo (3, Informative)

Algae_94 (2017070) | about 2 years ago | (#41174187)

My biggest problem with Drupal is that it constantly breaks module backwards compatibility when a new version comes out. Then you can only hope the team that made modules you need migrate to the new version. In this manner, you can have first hand knowledge of something easily done with Drupal 6, but when you try and implement it on Drupal 7, something is broke.

Re:Drupal Logo (0)

martin_dk (1368035) | about 2 years ago | (#41176377)

Sometimes compatibility breaks when core or some interdependant module is enhanced. It's usually not a big deal.

You may compare the problem to bleeding edge/stable linux distributions. If you want a stable platform then go for some of the very nice Drupal install profiles outthere. If you want the newest features, be prepared that some modules not yet are fully compatible. This development model has proved extremely effective for many platforms, would you like to suggest some better development model for a project of this size?

...when you try and implement it on Drupal 7, something is broke.

I take it you're not a serious nor recent user of Drupal 7.

Re:Drupal Logo (1)

drinkypoo (153816) | about 2 years ago | (#41176879)

My biggest problem with Drupal is that it constantly breaks module backwards compatibility when a new version comes out.

You mean, when a new version of Drupal comes out? You have years and years to upgrade to the next version. If your site is working, don't upgrade it. Only a few modules from D6 don't exist on D7, so I chose to upgrade anyway... but there was no reason for me to do so except wanting to be more familiar with D7.

In this manner, you can have first hand knowledge of something easily done with Drupal 6, but when you try and implement it on Drupal 7, something is broke.

Yes, it's called progress. Sometimes things change, to make them better. Don't be afraid, this is normal. It's the CMSes that don't change things and simply continue to suck that are the failures. This is why Drupal is so widely adopted. That, and that if you do everything through the framework it will support AJAX page updating and autocompleting fields and all that jazz, but it will also degrade gracefully to HTML without JS or cookies if the user has that stuff disabled. Unless, of course, you go around it for some functionality like they did on the whitehouse site, which absolutely requires js for some functions. As if I trusted my government to run scripts on my computer...

Re:Drupal Logo (1)

courtTheBee (2647691) | about 2 years ago | (#41180133)

Um, so what's so difficult? Create a vocabulary called "Blog Categories" and add terms. Create a content type called "Blog Post". Further customization through cTools' page manager and possibly panels and views. Theme - start with Basic or Omega. Either way, you have a working blog. What sort of documentation were you reading or are you the sort that doesn't read?

Re:Drupal Logo (1, Informative)

theskipper (461997) | about 2 years ago | (#41174953)

Drupal is a standard CMS, taxonomy is a baffling word only if you're not a programmer. If you want to build a lolz kittens site or the like, Wordpress is probably what you should have started with. It's plug and play and designed mainly for non-technical end users like yourself. For even quicker results, try tumblr.com or the blogger.com platform. It has most of what you'll need to get a site working painlessly.

Best of luck.

Re:Drupal Logo (1)

Anonymous Coward | about 2 years ago | (#41176955)

Taxonomy is a word from biology, you stupid fucking pedo.

Re:Drupal Logo (1)

drinkypoo (153816) | about 2 years ago | (#41176853)

I tried to install Wordpress, followed the directions precisely, and failed.

I installed Drupal 4.7 and the install went by the book and everything worked.

I have since upgraded to 5, 6, and more recently 7.

Vocabularies are taxonomy. If you don't understand English, may I suggest the dictionary?

Drupal is awesome. I am a crappy programmer and even I can extend it.

Re:Drupal Logo (1)

rubikscubejunkie (2664793) | about 2 years ago | (#41177343)

Brilliant! Great book about an overhyped technology.

Fuck yeah!!! (0)

Anonymous Coward | about 2 years ago | (#41171911)

DRUUUUUUUUPAL! FUCK YEAH!!!

Web designers should stick to what they know (4, Insightful)

ilsaloving (1534307) | about 2 years ago | (#41171913)

For a while I worked with someone else to put together websites. They would come up with a design mockup in photoshop. Then he gave me a PDF and I did the actual implementation. I would ask him for specific graphical elements when needed. The results were very nice. They looked good and worked well and reliably.

I have seen the results of several 'designers' who made websites themselves, I must emphatically say that they have no business making websites.
I can write a book for web designers too. It would be composed of a single page that says:

If you want to design a website, go ahead. But for the love of $(deity) please then hand it off to an actual programmer. You do not understand the underlying technologies to make it work. You do not understand the security implications of what you are doing. Just because you know how to uncompress a drupal or wordpress archive doesn't mean you know WTF you're doing. Even if you manage to get a working site put together, there is a good chance that it will run poorly because you bolted on way too many plugins, and it is almost guaranteed that you've left gaping security holes that will bite the client in the rear down the road.

So please, get an actual programmer to help you with implementation.

Re:Web designers should stick to what they know (0)

Intrepid imaginaut (1970940) | about 2 years ago | (#41172009)

Are good programmers incapable of good design and vice-versa in your country?

Re:Web designers should stick to what they know (1)

rubikscubejunkie (2664793) | about 2 years ago | (#41177475)

what countries do NOT have that problem?

Re:Web designers should stick to what they know (1)

ilsaloving (1534307) | about 2 years ago | (#41179813)

If good programmers were also good at design, then the "Year of the Linux Desktop" would have happened by now. Some programmers do have design talent as well, but the majority certainly don't.

Re:Web designers should stick to what they know (4, Insightful)

Anonymous Coward | about 2 years ago | (#41172087)

Disagree, by far the best designers I've worked with all knew HTML and CSS and were designing for the medium, even if they were working in Photoshop.

The Adobe jock designers were by far the worst, they create inconsistant layouts, designs that were squeezed to fit into 8.5x11 pages, and custom impossible widgets everywhere. Most of them have zero UI knowledge (not even understanding the difference between checkboxes and radios) If Adobe jocks had their way, the entire web would be gigantic 50MB flash applets with inscrutable mechanics.

Re:Web designers should stick to what they know (2)

micheas (231635) | about 2 years ago | (#41172501)

I tried solving this by sending the designer grid psd template files to start from.

The designer than said that it using a 960 grid, despite the only two grid lines that were hit were the far left and far right. Not a single element in the middle of the page hit a grid line.

I think I need to find a pair of tutorials:

  • Grid design in theory and practice: what you need to know;
  • and Responsive web design, why you need to make multiple mockups of the same page, and how to recycle elements from different sizes and media.

Not that they would result in any changes, but at least it would give me hope (however misguided) when starting a new project.

Re:Web designers should stick to what they know (1)

Count Fenring (669457) | about 2 years ago | (#41177629)

Aren't those tutorials just "the articles on AListApart?" http://www.alistapart.com/articles/responsive-web-design/ [alistapart.com] http://www.alistapart.com/articles/fluidgrids/ [alistapart.com] They don't quite cover the mockup aspect, but I think they're at least a baby step in the direction of comprehending the issues you're talking about.

Re:Web designers should stick to what they know (1)

ilsaloving (1534307) | about 2 years ago | (#41179893)

Ugh... seriously. I *despise* flash-based sites. I have yet to see one that isn't a usability nightmare.

However, web design is far far more than just knowing HTML and CSS. For anything more than the most trivial of sites, you also need javascript, SQL, some kind of backend language whether that's PHP, Python, Perl, Java, etc.

And heaven forbid you do something more enterprise-y, cause they you need Java, J2EE, JSP, taglibs, and a family-sized can of alphabet soup for the various other technologies with TLAs.

And then there are the softer development skills you need like an understanding of security issues (cross site scripting issues, data validation, buffer overflows, etc).

Nowadays most decent websites are no less complex than desktop applications, with a developer skill set required to match.

Re:Web designers should stick to what they know (1, Insightful)

girlintraining (1395911) | about 2 years ago | (#41172185)

But for the love of $(deity) please then hand it off to an actual programmer. You do not understand the underlying technologies to make it work.

First, that's "document.getelementbyid('deity').value". Second, why the hate, man? They may very well understand the underlying technologies, quite possibly even better than you do. But if you've ever done design work then you know that it's constrained by the oft-heard adage, "Done right, done fast, done cheap. Pick any two." That last one is especially relevant: Even when I was going to school for graphic design, there were already a lot of people doubling up with a web design degree as well, which touches on programming. The reason is "cheap". That's what the managers are, not your poor besodden designers. They want sophisticated and elegant design at $16 an hour, and then they expect that same person to impliment the design (at $16 an hour). You and I both know the disciplines of design and programming, while often going together, are not the same thing. And the training alone to master both far exceeds what you can hope to pay back in your lifetime in student loans if that's all they're paying you.

Not to mention that the mindsets required to design (as in, art design), and the mindset to program, are not compatible. There are very few people that can expertly accomplish both; Steve Jobs (WAIT! I'm not a fan boy. Put down the axe!) was one such person -- he was an asshole, but he also was able to understand both design and engineering requirements to create products that were both elegant and functional. I only bring him up as one example -- if he were easy to replace, Apple would have done it, and they're one of the largest companies on the planet. If they have difficulty finding people who can do both at an expert level, you can bet your sweet ass so will everyone else.

So please, don't hate the player, hate the game. Designers are good people -- they're just often put into roles they aren't suited for by bad managers.

Re:Web designers should stick to what they know (1)

hazah (807503) | about 2 years ago | (#41173005)

I support. Nicely put.

Re:Web designers should stick to what they know (1)

ilsaloving (1534307) | about 2 years ago | (#41179929)

The hate is because I've seen too many results from designers who think they are also programmers. And those results invariably are not pretty at all from a code and/or security standpoint.

When I look at said results, I get the same feeling one would get if they declared that they were a Christian and then someone asked them if they were good friends with Fred Phelps.

Re:Web designers should stick to what they know (1)

ilsaloving (1534307) | about 2 years ago | (#41180011)

Sorry, I didn't give your post the response it deserves. Yes, you are right that the results are entirely dependent on the management handling the project, but my sympathy drops precipitously when said designer happily states that they can do that no problem.

I mean, I recently had to hand-hold someone through getting wordpress installation files onto the server because they had never even *heard* of FTP, and had no concept of what a public_html directory was. I'm not sure if I was entirely successful in hiding the contempt from my voice as I explained things to them. Apparently they had never used anything besides cpanel to manage websites.

Re:Web designers should stick to what they know (1)

rubikscubejunkie (2664793) | about 2 years ago | (#41177361)

Agree w/ what you wrote 100000%

Typo (1)

cornface (900179) | about 2 years ago | (#41172033)

The reviewer accidentally typed O'Reilly in the spot where Packt should go. Otherwise another solid 8/10 Drupal review.

Tried It (2)

CanHasDIY (1672858) | about 2 years ago | (#41172197)

As a noob in the web programming world, I like to try out a lot of the different tools offered that are supposed to ease development.

I tried Joomla! and the results were... less than satisfactory (less of a learning 'curve,' more like a learning free-fall).

I gave Drupal a shot; not terrible, I think if I work with it enough I'll understand the system well enough to make some damn fine looking blogs... if I were interested in making yet another blog site (I'm not).


Long story short, I ended up hand-coding everything anyway.
So it goes.

Re:Tried It (1)

MightyMartian (840721) | about 2 years ago | (#41172347)

Tried only briefly to work with Drupal, found it very complex. Moved to Joomla, which despite some serious documentation holes, was marginally easier. Doing my second big project in writing a Joomla component and naturally it is a bit easier, so I've probably already compromised myself as far as using Drupal.

What I have to say in both cases is by and large the documentation sucks, the examples not going much beyond Hello World, the default plugins breaking so many of the "rules" that they cease to be all that useful, and you end up having to sort it out for yourself anyways. Frankly, I hate CMSs, but that's the way the world is going, so vive la PHP crapfest.

Re:Tried It (1)

CanHasDIY (1672858) | about 2 years ago | (#41172481)

That lack of documentation is pretty much what turned me off of CMSs in general. Like I said, I'm still learning the languages (my last experience was with HTML 1.0), so throwing myself into a complex system like Joomla or Drupal without any real, thorough documentation (that isn't pure jargon) is an instant no-go.

Frankly, I hate CMSs, but that's the way the world is going, so vive la PHP crapfest.

I suppose if I were doing large projects for major clients, I'd probably pretty much have to learn at least one of the CMS systems... fortunately for me, the whole reason I'm getting back into web development is to build simple sites for family businesses (like the one in my sig), to whom fancy widgets and overgrown databases are of no significant importance.

Plus, none of them are "techie" types such as myself, so as long as I don't totally bork the site, they think it's the coolest thing they've ever seen!

Re:Tried It (1)

hazah (807503) | about 2 years ago | (#41173231)

To be honest, I find all of these tools to be extremely expert oriented. That, in of itself isn't a bad thing. These systems are big. Real big. And the main thing to remember that it's not just unpack it and go. Frankly, I don't know where that idea comes from. It's knowing how other people are already using it. There are best practices, idoms, and other, invaluable lessons that come with experience and education. At this point, if I were to take Drupal (I only deal with 7), and my standard, go to modules, I find it hard to imagine a type of site that a client would want that couldn't be built. The main obsticle is coming up with a good design for the site to begin with, but that isn't really what Drupal is used for. There are a TON of special purpose modules out there that make things confusing, but I almost never use them. The modules to use are the ones that give you general tools to build things with. I suggest, if you're still interested to investigate these: Rules, Views (and Views Slideshow, Draggable Views), Panels, CTools (page manager), Display Suite, Context, Heartbeat, Flag, *all of the desired fields*, and Commerce (with it's extensions). Yes. I realize this sounds like a commercial, for that, I appologize. I mention these for only one reason. I hardly ever have to code. Sometimes, yes, it happens, rarely. You yourself are hand-coding, and have only your eyes, perhaps a couple of others, checking things over. Long story short, the wheel has been already invented. There's almost nothing that you'll need to do that hasn't been already done and provided by these frameworks. The difference is your education.

Re:Tried It (0)

Anonymous Coward | about 2 years ago | (#41174857)

Two years ago, I made a web site for our winds band, where we have a calendar of concerts and rehearsals, a little forum, a DB with all our repertoire and a list of recordings. When a musician logs in, he sees all the pieces that will be played in next concert and he can download the parts for their instrument. It is quite neat although now I would do some things slightly different if I had to start from scratch.

At first I looked at Joomla, as it was said to be much better than anything else, but I could not get it working as we needed, with different roles and permissions depending on the content type, fields, etc.

Surprisingly, when I approached Drupal, the way it is designed fit my mind perfectly: I had no trouble understanding its basics at all, unlike Joomla. Using modules, I was amazed how I could do everything I wanted without writing a single line of code. The site structure is clean, with clean URLs, google likes it too, and it fulfills our needs very well. Since I suck designing, I just used the default theme with a different color, but it is good enough.

One of the issues I had was choosing the 'right' modules for the jobs, which involved trial and error and googling more than I wanted.

Re:Tried It (1)

hazah (807503) | about 2 years ago | (#41180319)

That one issue you had, I would say is the hardest one to resolve. There are a number of them that I like to call my "go to" modules. They are exclusively of the building block type. Panels and Views, for instance (there are a number of others). They tend to offer the right tools to replace effectively all the other niche modules that are out there. It takes time, but it has definately been more rewarding than annoying.

Re:Tried It (1)

drinkypoo (153816) | about 2 years ago | (#41176911)

I gave Drupal a shot; not terrible, I think if I work with it enough I'll understand the system well enough to make some damn fine looking blogs... if I were interested in making yet another blog site (I'm not).

While it is the work of minutes to install Drupal and make a blog site out of it, it can also be used to create absolutely any kind of site you want. This is because the themes are scripts, so you can control precisely what is output and what is not both at the page level and for each individual content type. It also has an XMLRPC module so you can use it to backend a flash-based site or what have you. In fact, Drupal is satisfactory for making absolutely any kind of website from the simplest to the most complex. With the caching in D7 it can actually handle the load of being used for a large site, too.

Re:Tried It (1)

CanHasDIY (1672858) | about 2 years ago | (#41178205)

I gave Drupal a shot; not terrible, I think if I work with it enough I'll understand the system well enough to make some damn fine looking blogs... if I were interested in making yet another blog site (I'm not).

While it is the work of minutes to install Drupal and make a blog site out of it, it can also be used to create absolutely any kind of site you want. This is because the themes are scripts, so you can control precisely what is output and what is not both at the page level and for each individual content type. It also has an XMLRPC module so you can use it to backend a flash-based site or what have you. In fact, Drupal is satisfactory for making absolutely any kind of website from the simplest to the most complex. With the caching in D7 it can actually handle the load of being used for a large site, too.

*Most* of what you said there I get, but some of it (specifically the terms 'XMLRPC' and 'caching in D7') went right over my head - apparently you missed the part where I mentioned being a total noob in terms of web programming. I get what you're saying, though - one of the things that attracted me to Drupal in the first place was the apparent ease with which all manner of websites can be created, assuming the person at the controls has more of a clue what they're doing than I currently possess.

Once I get to a point where I'm being asked to set up an eCommerce or other more complex site, I'll probably revisit Drupal, maybe even get a book or two; but for the sites I currently maintain, hand-coding is way easier for me.

Re:Tried It (1)

drinkypoo (153816) | about 2 years ago | (#41178547)

Once I get to a point where I'm being asked to set up an eCommerce or other more complex site, I'll probably revisit Drupal, maybe even get a book or two; but for the sites I currently maintain, hand-coding is way easier for me.

What attracted me to Drupal in the first place is that I don't really consider my programming skills to be "programmer" level, and I wanted an extensible web framework that would give me lots and lots of functionality without writing code. I narrowed my choices down basically to what would run on PHP and MySQL to be compatible with the cheapest available web hosting options, and then chose to mess with Wordpress and Drupal. As I have mentioned elsewhere, either the WP install failed or I failed the WP install, and I seriously tried following the instructions twice. Drupal worked on the first go so that was pretty much the end of the story. I don't really know how one compares to the other. I only know that Drupal is simple to use to do basic things.

This was some time ago (Drupal 4.6, maybe? Or 4.7) so there wasn't a lot of credible competition. There were some frameworks but no complete CMSes which were also frameworks. Along the way I have contributed patches which have been accepted, where I cobbled the code together out of lines of other people's code from other modules solving a similar problem. But because for me the web thing is just a hobby it can be quite some time in between spates of attention, and I don't really have any other use for PHP in the interim so I get a bit rusty.

One criticism that has been leveled somewhat successfully against Drupal is that theming it can be a bit of a challenge because you're basically writing PHP. But there are so many themes today which can be tweaked to produce the results you want, and so many ways to get out of writing code for your displays (like judicious use of the absolutely indispensible views module) that this is not a serious impediment to almost anyone being able to produce a site that is really close to what they want.

Re:Tried It (1)

CanHasDIY (1672858) | about 2 years ago | (#41178859)

Interesting... If you have a line on any writings geared towards helping an absolute beginner learn to use Drupal effectively, I would much appreciate being pointed in that direction.

Re:Tried It (1)

drinkypoo (153816) | about 2 years ago | (#41179093)

My sincere advice is to just install it and start playing with it. Enable a module, read its help, etc. For instance activate the blog module and see what changes that makes on the site, just poke around. Enabling it creates new permissions, a new content type, and so on. It's all stuff you could do within the drupal interface, but it's wrapped up in one module. And if you do create a body of functionality which should essentially be a module you can install the features module and actually make it into one without actually having to write any code at all. For example, the views, content types, and informative pages about some feature of your site can all get bundled up.

Vast amounts of the functionality of many common sites are embodied in the views module, so you want to install that and start playing with it very early on. You can add different types of fields to any content type and then you can display groups of them in lists, tables, calendars, and so on. These views can then be inserted right into documents without writing a line of code with the insert view module.

Designers should design (2)

thetoadwarrior (1268702) | about 2 years ago | (#41172337)

I wouldn't ask a softwre engineer to do web design. Why do designers think they can code? I've yet to see an example of a web designer coding that has ended well. It's only that most of them do small unknown sites that they don't get hacked constantly or go tits up all the time.

Animal? (1)

denvergeek (1184943) | about 2 years ago | (#41172361)

What the fuck is that animal on the cover? I remember "The Camel Book" and "The Owl Book", but seriously, what the fuck is that thing?

Re:Animal? (0)

hazah (807503) | about 2 years ago | (#41173291)

It's a fish.

Re:Animal? (1)

Saija (1114681) | about 2 years ago | (#41174527)

It looks like Zoidberg in his teeny stages...

Generic tools for generic sites. (3, Interesting)

VortexCortex (1117377) | about 2 years ago | (#41173563)

I did some benchmarking and discovered that C or C++ is really great for developing websites with. Everyone moved to Java and Perl and PHP before C++ web development had a chance... OOP > Templating Language > Generic CMS. I found that some shared hosting providers even have GCC installed, and otherwise you can install it yourself, or just upload the binaries and Apache will execute them for you. They run faster than compiling / interpreting PHP or Perl, and I don't have to implement an entire server. I also get access to a huge assortment of software libraries.

I agree CMSs like Drupal or Wordpress have their place. That place is as far from me as physically possible: Anything that runs on PHP invariably requires me mucking about in PHP -- Sorry, I just can't live with that, I'd rather use Java. If PHP is the future, I'll just keep living in the past -- It's actually quite nice here!

Re:Generic tools for generic sites. (0)

Anonymous Coward | about 2 years ago | (#41175355)

Who gives a shit about code execution speed when 95% of the time the bottleneck is database or connection latency, and multiple caching layers exist?

Maybe facebook or twitter i guess..

sand making plant (-1)

Anonymous Coward | about 2 years ago | (#41175959)

Shanghai Shunky Machinery Co.,ltd is a famous manufacturer of crushing and screening equipments in China. We provide our customers complete crushing plant, including cone crusher, jaw crusher, impact crusher, VSI sand making machine, mobile crusher and vibrating screen. What we provide is not just the high value-added products, but also the first class service team and problems solution suggestions. Our crushers are widely used in the fundamental construction projects. The complete crushing plants are exported to Russia, Mongolia, middle Asia, Africa and other regions around the world.
http://www.sandmaker.biz
http://www.shunkycrusher.com
http://www.jaw-breaker.org
http://www.jawcrusher.hk
http://www.c-crusher.net
http://www.sandmakingplant.net
http://www.vibrating-screen.biz
http://www.mcrushingstation.com
http://www.cnstonecrusher.com
http://www.cnimpactcrusher.com
http://www.Vibrating-screen.cn
http://www.stoneproductionline.com
http://www.hydraulicconecrusher.net

Summary (1)

Bozovision (107228) | about 2 years ago | (#41182259)

Drupal haters say:

"Documentation is a problem".
Answer: we have an active documentation team. Documentation is not as good as it could be, but it never is. It's put together by volunteers, which makes it easy to contribute. Every module has a readme.txt. And there's a huge amount of documentation at . There are hundreds of videos - just last week all of drupalcon.org held in Munich was videoed and put online. And I note that the OP is a book review on another Drupal book.

"It's spaghetti code"
Answer: The code is hugely well structured. It works on a callback-by-naming system, so there's no need to register callback functions, it happens automagically. Mostly, I think that this criticism comes from people who don't understand the architecture. It's not perfect - there is cruft - for instance there hasn't been a settled standard for code-level plugins - e.g. I want to rewrite the standard paging through lists, so that it works better for my site. That uses one style of plugin code. There are others. This is part of growing pain, and is ironed out with each version.

"It's not Object Orientated"
Answer: Much, but not all of the code is OO, but was designed to work on PHP4 as well as PHP5. In time it will all be OO. But more importantly, OO is an idea to promote modularity and extensibility, which are notions that are built into the architecture. For instance, a pattern that is repeatedly used is the system of overrides by putting a well named piece of code in the right place.

"It's written on PHP"
Yep. It's not as fast as C++. Or Java. It's also cheaper to write, easier to learn, runs on almost every webserver, and is a mutt of languages, rather like English. There are hundreds of developers who contribute to the core development and thousands who contribute to modules. I don't know of any open-source C++ CMSs with the same rate of growth. Hardware is cheaper than developers. Turns out that PHP is good enough for Facebook. (Yes, I know: Hiphop. That's optimization.)

"It's complicated and over-engineered"
If you want a tool that is just a blog, then Wordpress is excellent. If you want a tool that grows with you, and can do anything you want then Drupal is probably going to work out better for you than many other tools. That's not to say that there aren't great Drupal blogs, but out-of-the-box, Wordpress is better than Drupal as a blog. But Drupal also has distros/install profiles, which are versions specialised for a particular job. And maybe one of those is a better match for your needs than the core version of Drupal.

"I'm a Joomla/Silverstripe/Wordpress/Perl/whatever user"
Those are all excellent tools. You should carry on using what works for you. But if you are interested in what's happening elsewhere, then come by drupal.org and have a look around. Have a play with one of the pre-packaged versions like drupalgardens.com.

"I can make a CMS. Why do I need someone elses?"
I too made and sold CMSs. Turns out that you can't compete with the rate of growth, the rate at which maintenance is done, or the availablity of add-ons.

"I've always been fine with my hammer and nail and plain HTML."
Yep. You don't make websites that work on mobile phones. Or large websites. Or ones that change frequently. Or you make something which for which a completely custom solution is better: Drupal is never going to be the best forum software. If you just need a forum, then use specialist forum software. But if you need forums, and to put some pages up, and to have an image gallery, and to send SMSs on update, and...etc, then start with a tool that can grow.

"It looks terrible"
It will look exactly how you want it to look. It's true that some other systems have many more off-the-shelf templates. And it's true that Drupal could be more designer-friendly, but shouldn't how your site looks reflect you?

"It does hardly anything - it doesn't even do Wysiwyg"
When you install it, you get a bare-bones system, to which you add parts. The core is a framework to build out on. So you download and enable the bits that you need for your site, which lets you pick and choose your Wysiwig editor as well.

"It constantly breaks module backwards compatibility"
Yes, when we release major versions, about every 18 months to 2 years, we do not guarantee that the modules from the previous version will work. They may only need a small upgrade, but they will almost certainly need _some_ changes. We do however guarantee that for core modules, your data will be ok. You'll put in an updated module, run the upgrade routine, and voila! For modules which are not core, this is almost always true too. Where this sometimes falls down is when there is no longer a need for a particular module, because it's become part of the core. We always support 2 versions (and it doesn't stop working just because it's no longer supported), so there's at least 36 months before you need to think about upgrading.

"James Joyce's Ulysses of CMSs. A small group of people (usually with too much time on their hands) have mastered it"
There are thousands of contributors. Conferences on your continent once a year. Local events all the time. Thousands of user groups. Runs some of the largest and smallest sites on the internet. I guess Ulysses was pretty good.

"There are global variables everywhere. The names of variables are completely unintelligible and the depth of data structures is heinous."
It turns out that there aren't. $node and $user are probably the two that are everywhere, which is not surprising since they carry information about the current page and the user, and the callback system lets each module interact with the aspects of the system that interests them. I guess that some variable names are unintelligible, if you don't understand the architecture. Regarding the depth of data structures: this is a fair comment in a way... the system builds up a picture of the requested page in a data structure, giving each module the chance to decorate or alter it, then it renders each piece, and combines the output into a page. So yes, the data structure that represents a page _is_ big. And it's well structured, so that the decentralized system of modules can reliably interact.

"Why the fuck is Drupal taking several tens of megabytes for only 100 fields?"
It could be that you were using hundreds of modules. It could be you were storing a lot of data in those 100 fields. It could be you had a massive menu structure which needed to be rendered. You can use a GUI tool, which has to cater for lots of flexibility that you won't ever need, or you can write a very tight custom module, that only uses the memory you required. It's a trade-off usually, and usually it's cheaper to use the general purpose tool. Drupal needs between 8 and 16 MB for a starter site. If you add more modules, then you use more memory.

"..If you are an actual developer, and need to do a lot of custom things, then try a real framework like Zend, or Codeigniter, or Laravel, or Yii"
This is definitely true sometimes. But this is the minority of users. Most people are not developers. And most sites, while needing custom things, fit inside a range that has mostly been done before - for instance a slideshow; adding one in Drupal is as easy as downloading and switching on a module. Writing your own slide player, whilst fun, is not a productive use of time for many of us.

Drupal lovers say:

Drupal is not the best at everything. If you have a very specific need, and a specific tool deals with it, then use that tool. Drupal will never be the best game platform, for instance, but I'm sure there is a game platform built on Drupal which is also used for community interaction.

It's a big system, and like any large system, there are annoyances, but one of the benefits of open source is that annoyances get solved quickly.

It's used by mom & pop, and by multinational corporations and governments, micro sites and some of the largest. It can start small and can grow.

There are conferences and events and groups constantly talking - look at #drupal on twitter or look at drupal.org. Last week 1,800 people got together in Munich for a week of Drupal, and in about 6 months time Portland, Oregon will host the next US Drupalcon, with around 4,000 to 5,000 attendees expected, I think. Between now and then, there will be hundreds or Drupal camps and meetups.

If you are thinking of developing a website, then Drupal is a good place to start, and we'd love you to be part of our community.

Oops (1)

Bozovision (107228) | about 2 years ago | (#41182309)

Doesn't matter how many times I check my writing, the moment I post, I discover something wrong. :-(

"And there's a huge amount of documentation at " http://drupal.org/documentation [drupal.org] .

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?

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>