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!

Front End Drupal

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

The Internet 68

Michael J. Ross writes "Content management systems (CMSs) are created largely by Web developers using back-end programming languages (such as PHP, by far the most common choice). The free CMSs are built as open source projects, by volunteers who have many demands on their time. As a result of both of these competing factors, far less time is devoted to the front-end aspects of these CMSs. In turn, the "themes" that define the appearance of a CMS-based website are typically substandard, in the eyes of many Web designers and, most likely, countless users of those sites. This criticism has been leveled even against Drupal, although the situation is improving. A new book, Front End Drupal: Designing, Theming, Scripting, is intended to help Drupal designers everywhere speed up that process of improvement." Read on for the rest of Michael's review.The book was written by Emma Jane Hogbin and Konstantin Käfer, and published by Prentice Hall on 15 April 2009, under the ISBN 978-0137136698. As suggested by its title, Front End Drupal "is designed to help both experienced designers and rank novices get an understanding of how Drupal theming works," to quote from the book's foreword, written by Dries Buytaert, Drupal's founder and project lead. He notes that creating a Drupal theme requires knowledge of "XHTML, CSS, JavaScript, and PHP, all within the context of Drupal." These are some of the key technologies addressed in the book's eleven chapters, and it assumes that the reader is at least familiar with all four of them. The first of the two appendices explains: how to install Drupal and contributed modules on the three different platforms supported (Windows, Linux, and Mac OS X); basic configuration and administration; and installation troubleshooting tips. The second appendix comprises some of the more important example code used in the book, and brief overviews thereof. At the end of the book's 456 pages, there is a coupon code for a 45-day free subscription to read the online edition in the Safari Books Online library

All of the sample source code and themes can be downloaded from the authors' book website. The site also has the author biographies, as well as reported errata, of which there are two, as of this writing. What is most striking about the site is its styling — or lack thereof. One would think that the authors of a book on Drupal theming would have put a commensurate amount of effort into crafting an attractive custom theme for their own website — one that demonstrates their own theming skills and, more importantly to the reader, what is possible using the principles taught in the book. Remarkably, the authors appear to have done nothing more than take the Drupal 6 default theme, Garland, and change the color scheme from shades of blue to shades of brown (matching the book cover); only the blue Drupal icon is unchanged, and its color clashes with the rest of the site.

Prentice Hall makes available their own Web page for the book, where visitors will find a description, two Amazon.com reviews, the table of contents, and a sample chapter ("The Drupal Page") as a PDF file. The entire book is also available in electronic form.

In the book's preface, the authors briefly summarize the chapters and appendices, and define the target audience and technologies with which the reader should be knowledgeable (noted above). Readers should also be familiar with how Drupal works, have some experience administering a Drupal site, and ideally possess some knowledge of website design and development; but that last one is not a hard requirement, since the authors promise to explain the basic concepts as needed.

Any reader who begins the book by skimming the table of contents or the preface's summary of Chapter 1, may be tempted to skip that chapter, especially since it discusses team workflow — something freelancers generally ignore, and employees leave to management. Yet the earlier material is worth reading, if only that it begins to establish a baseline of terminology used throughout the rest of the book. It also provides some basic information on content structure, layout, and naming on a Drupal page. For illustrating the ideas under discussion, the authors use a number of existing websites. In fact, too many different sites: Readers probably would have found it more useful for each idea to be presented in the context of a single neutral subject area, and without distractions such as toilet birthdays (no kidding). Even better, the ideas could have been illustrated through example pages — each page illustrating one or several ideas — built from the ground up. By focusing on pages that a reader could quickly create on his own, the authors could have eliminated the screenshots of those various websites. One example is Figure 1.1, which combines two images, with the topmost one largely obscuring the one below. Most of the topics are covered at a very high level — possibly higher in some cases than readers will find valuable. Nonetheless, there is much solid advice, including some recommended theme resources later in the chapter. In the earlier section on "Topical Organization," there is a brief but excellent discussion on the relative merits of limited versus unlimited tag vocabularies.

The second chapter continues to lay the groundwork, by introducing basic Drupal theme strategies and terminology, three major modules that veteran Drupal developers use frequently (CCK, Views, and Devel), and some valuable browser-based development tools. The definitions of Drupal terms are useful — especially for newbies confused by the Drupal handbooks. One exception is the authors' alternative metaphor for "weight," which proves more confusing than the original. Readers then begin learning how to use the aforesaid modules and tools. However, several of the authors' statements are misleading: On page 43, they are instructed to install the CCK module, and then given a list of additional modules needed; the first one on the list is... CCK. On the next page, the authors state that the FileField module requires the Token module, but it apparently does not. On the page after that, the "manage fields" link is given as the "add field" link. Those last two discrepancies suggest that the book is based on outdated versions of Drupal and/or the contributed modules under discussion, even though its publication date is just a few weeks prior to this writing. Any version differences are likely impossible to confirm, since the authors fail to mention which versions they are using, or provide any guidance to the reader as to which versions to use — unusual for a programming book. At the beginning of the chapter, the reader is told he "will learn step-by-step how to create a mini portfolio Web site," but the process peters out not long after a new content type is created, and the reader finishes the chapter with no such portfolio site.

Chapters 3 and 4 move the reader one step closer toward the ultimate goal of being able to create a new theme with confidence. The first one explains how to find, install, and configure prebuilt themes — also, how to create a very basic theme from scratch, and a subtheme using the Zen starter theme. This material comprises a generally thorough introduction to the topics, compared to most documentation, with plenty of step-by-step explanation. An exception is the Zen section, in which the reader is instructed to place the directory into the themes folder; but it is not made clear whether this is the primary Drupal themes folder, or sites/all/themes (as advised several pages earlier). Secondly, in step 3, readers can only guess as to what is meant by "the main CSS file," as there are several. On the next page, the authors mention "configure" links next to the Zen and Zen Classic themes, but no such links exist for those starter themes. The fourth chapter discusses page template files, site-wide variables, menus and navigation, regions and blocks, search results, templating different sections of a site, aliased URLs, taxonomy templates, and styling for output to printers, PDF files, and mobile devices.

The fifth chapter explores the details of how to modify existing node templates, or create new ones, for all content types. This is what makes it possible to develop highly customized page content, including summaries, embedded images, image galleries, and content based upon output from the Views module. The subsequent chapter focuses on one of the most problematic types of content — forms — and how they can be created using the CCK. The authors recommend TinyMCE as one's WYSIWYG editor module, but that has apparently been replaced by the Wysiwyg API. User editing of content is a key element in building an online community using a Drupal-based site, and it is the topic of Chapter 7, which discusses user profiles, permissions, access, comments, blogs, forums, wikis, spam, CAPTCHAs, and how to make content private for members only. The next chapter addresses the theming of the administrative interface, which the typical site user will never see, but can have a significant impact upon the productivity of the developers and maintainers of a site. Readers learn about RootCandy (a refreshingly different admin theme), and how to theme error pages.

The final three chapters focus on JavaScript and jQuery. Consequently, they compose a stand-alone resource of their own, and could even have been used as the basis for a separate book. Chapter 9 provides an overview of the language, while the other two chapters cover jQuery and how it can be used as part of a Drupal-based site.

Scattered throughout the manuscript are tips, each indicated with a pencil tip icon. These help to break up the text visually, and provide valuable guidance. The contrast between the black text and the dark gray background could certainly be improved; but most of the tips are fairly short, so this does not pose a major problem.

Every chapter ends with a summary, and not a single one of them is useful or needed. Any unique information conveyed in them should have been merged with the introductory paragraphs for the respective chapters, which is where readers would be looking anyway to see what each chapter addresses.

The book has numerous minor problems, including grammatical and stylistic errors, such as dashes incorrectly performing the duty of semicolons, some URLs missing the root directory slash, and excessive use of exclamation marks (more than a dozen before even reaching the second chapter). When stating the sequence of menu items to choose in order to reach a particular admin page, the authors should use ">" or ">>" to separate the menu choices, as is done in most computer books. Instead, the authors opted to use commas, which of course turns every sequential menu path into a list of menu items, which is nonstandard and disconcerting. As is typical in a first edition, the book contains several errata: "Partnership" in Figure 1.7 (page 10), "the GiMP" (page 14; should simply read "GIMP"; after all, this isn't Pulp Fiction), "only focus only" (page 26), "Modification / Date" in Figure 2.1 (page 37; should read "Modification date"), "Content Creation Kit" (throughout the book; should read "Content Construction Kit"), "of [the] view" (page 56), "http:jigsaw" (page 66), "INSTALL [is] present" (page 79), "of [a] page" (page 100), and "to to" (page 125) — in the first quarter of the book alone.

A lingering disappointment is that some of the promised examples are not finished in the narrative, such as the portfolio site mentioned earlier. Secondly, the downloadable source code is incomplete, apparently missing the example code in the first few chapters, such as the Bolg theme files. Furthermore, the downloadable code is not organized by chapter, making it difficult to even determine what example code is missing.

On the other hand, the book has much to offer. For the most part, the explanations and step-by-step instructions are clear, and the diagrams and screenshots are all neatly presented and helpful — though some sections of the book could have benefited from more such figures. With its extensive coverage of all the key technologies, and its wealth of valuable tips, Front End Drupal is an essential resource for learning how to create Drupal themes, and fills a long-standing gap in the Drupal literature, better than any other book currently available.

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

You can purchase Front End Drupal: Designing, Theming, Scripting 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 ×

68 comments

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

At first I thought it said the end (3, Insightful)

diskofish (1037768) | more than 5 years ago | (#28000731)

and I said "Good Riddance". Drupal is powerful, but not really that fun to develop with.

Re:At first I thought it said the end (0, Flamebait)

MrEricSir (398214) | more than 5 years ago | (#28000941)

Fun? It might be fun to screw around with Booby on Brails all day, but in the end you need something stable that actually works and does everything you need.

And whether that's fun or not is largely a matter of perspective.

Re:At first I thought it said the end (1)

koutbo6 (1134545) | more than 5 years ago | (#28001621)

You lost me at booby...

Re:At first I thought it said the end (1)

queenb**ch (446380) | more than 5 years ago | (#28016241)

The biggest issue is that many of the CMS developers lay the page out for you. They hard code all of these little boxes. This one goes here at the top left. Under that is a banner.

It's *not* up to the designer to decide what goes where or even if its appropriate for the site to have even a given little box. All the designer can do with it is to try to "deal with it".

Worse yet, to move them around or remove them becomes a hideously painful exercise in hacking someone else's code base.

We are using Drupal constantly (-1, Offtopic)

Anonymous Coward | more than 5 years ago | (#28000849)

It's a year now since we hired Drupal and I'm now convinced that investing the money for the H1B was the best idea ever.
Drupal can not only program Java, he also can make coffee, make copies, massage the back of boss Celmentione, cook curry, clean the floor, cook more curry, clean the toilet, park the car of boss Francone, wash the car of boss Spirelli
and many more noone really loves to do.

I must admit that first I've been quite sceptical about hiring an Indian for a family business like ours, but Drupal was the best bargain we could ever get (perhaps after Scallo "The squeezer" Canellioni, who could open beer bottles with his nose).

Content management without content (3, Funny)

shoppa (464619) | more than 5 years ago | (#28001027)

What's most intriguing, is that 90% of the sites fronted by content management systems actually have no content!

Re:Content management without content (4, Funny)

operator_error (1363139) | more than 5 years ago | (#28001111)

You mean like Slashdot?

Re:Content management without content (1)

sgbett (739519) | more than 5 years ago | (#28001143)

Furthermore (and the most glaring mistake, as mentioned in TFR) the website for a book about Drupal themes, has virtually no theming.

Re:Content management without content (1)

yareckon (1236270) | more than 5 years ago | (#28003223)

Knowing both Emma Jane and Konstantin personally, I would say that they are both developers and drupal community members first and marketing people second. Making a flashy site may just have been the last step that didn't quite happen. I believe it is each of their first books.

It is definitely a weak spot for the image of the book that the companion site only uses garland (Drupal's default theme) but please try to see this in context. This is two insiders in the drupal community trying to give the rest of the world the keys to the kingdom of Drupal theming, not two experienced marketers swooping in to take advantage of the next tech trend.

A good way to laugh this off might have been to just joke that if you don't buy this book your website might stay looking like this! :)

CIA = Murderous Liars (-1, Offtopic)

Anonymous Coward | more than 5 years ago | (#28001033)

The CIA lied to all of us about Iraq.

Why wouldn't it lie to Nancy Pelosi?

And why would anybody believe anything that a sleazy ass Republican says??

These guys have done nothing but lie to us and murder the innocent.

Fuck the Republican party. Never again.

I thought Drupal was a... (2, Funny)

GottliebPins (1113707) | more than 5 years ago | (#28001135)

female impersonator? Or was he that libertarian that ran for president?

Re:I thought Drupal was a... (-1, Troll)

Anonymous Coward | more than 5 years ago | (#28001165)

And what is this about "Front End Drupal"?

I'm pretty sure it's his back end [wikipedia.org] that he prefers to use.

Real men... (0)

Anonymous Coward | more than 5 years ago | (#28001653)

Real Men (TM) should use web frameworks named after western movies [imdb.com] !

Tired of crappy CMS' (4, Interesting)

Anonymous Coward | more than 5 years ago | (#28001171)

I'm so tired of taking over sites where the former "developer" used a Drupal or Joomla installation.

It is inevitable that the requirements of a custom web app will eventually exceed the capability of these systems. Knowledge of a particular CMS does not a developer make! These are tools in a toolbox and should be used as such. I hate it when people sell themselves as freelance "programmers", but really they only know how to use a particular CMS. So lets write a book and encourage this behavior - bluagh..

--that's my 2 cents, but then again, I'm just an anonymous coward :-)

Re:Tired of crappy CMS' (-1, Troll)

Anonymous Coward | more than 5 years ago | (#28001435)

I don't use CMSes for the same reason. I write my own to suit the specific needs of the project I'm working on, and add capability later on.

Re:Tired of crappy CMS' (0, Troll)

Frosty Piss (770223) | more than 5 years ago | (#28001873)

I don't use CMSes for the same reason. I write my own...

I'm sure the hackers love you...

Re:Tired of crappy CMS' (0)

Anonymous Coward | more than 5 years ago | (#28006615)

Because stopping SQL Injections, Remote File includes and XSS attacks etc. is sooo difficult...

Re:Tired of crappy CMS' (5, Insightful)

revjtanton (1179893) | more than 5 years ago | (#28001481)

I installed a Joomla site for a latino non-profit in Baltimore who's previous site was a mess. It was a mess because my "predecessor" threw a bunch of random things together (directory using a database and articles in plain html only) and those who run the charity don't know anything about web design at all. I came in and installed Joomla and designed a few things to work in that installation because it is easy for someone to use AFTER I step away.

If your argument is that Joomla and Drupal have no place because web apps will outpace their development then why is the Joomla extension repository so extensive and growing? For every new app or site that comes along someone will develop a module or plugin for the CMS's because a CMS is easier to handle for a business that doesn't conduct even 50% of it's business online and so there will be a market for easy to use plugins.

If your main argument is your other one: freelancers who install a CMS and call themselves programmers are frauds then I can't really argue with you. For someone to call themselves a developer or programmer simply because they've installed a CMS is silly, but there are plenty of us who are programmers of one type or another that still use a CMS because there is no need to completely redesign the wheel every year. I'm all for people learning to write code, but if everyone wrote code then my abilities would be worthless...

All I'm saying is that the capability threshold of any CMS is irrelevant in terms of web applications because anything can be branded obsolete by anything else at any time (see Wolfram|Alpha [wolframalpha.com] vs. Google [google.com] ); and while installing or administrating a CMS doesn't make you a developer on its own, plenty of us developers give a CMS it's value and that's what this book is pointing out!

Re:Tired of crappy CMS' (1)

Spy Handler (822350) | more than 5 years ago | (#28002849)

I'm all for people learning to write code, but if everyone wrote code then my abilities would be worthless...

Well, everyone (practically) drives nowadays, but that doesn't mean YOUR ability to drive is worthless. And there's still a need for people like bus drivers, taxi drivers, etc.

Re:Tired of crappy CMS' (1)

revjtanton (1179893) | more than 5 years ago | (#28003705)

I don't think that analogy works exactly...what I was saying is that coding, unlike driving, is more specialized. It would not be beneficial for everyone in society to take the time to learn PHP or Java, however it would benefit everyone to know how to transport themselves great distances in a small amount of time. It would not benefit anyone for everyone to learn how to code, it would only cheapen it all.

Also drivers did get paid well until driving was common...and I don't mean to sound elitist but software development is a bit more technical than cab driving...

Re:Tired of crappy CMS' (0)

Anonymous Coward | more than 5 years ago | (#28007075)

...and people call themselves 'programmers' when they don't know the first thing about the width of an accumulator and how it affects your software.

I've learnt to live with the fact that people who only do websites call themselves a developer.

Re:Tired of crappy CMS' (1)

Shados (741919) | more than 5 years ago | (#28001497)

The more mature CMSs (such as those you mentionned, Alfresco, Sharepoint, etc) can be extended programmatically to do pretty much anything and everything, so its just a foundation. Unlike prebaked web packages of old, where if you hit the limit, you were screwed, these are just a starting point that can be extended indefinately. Usually they're selected by the developers once the requirements are excessive to begin with :)

Re:Tired of crappy CMS' (1)

drinkypoo (153816) | more than 5 years ago | (#28001985)

It is inevitable that the requirements of a custom web app will eventually exceed the capability of these systems.

Citation? What percentage of these systems outgrow their CMS? I'm not much of a programmer but even I've extended drupal.

Re:Tired of crappy CMS' (3, Insightful)

hobo sapiens (893427) | more than 5 years ago | (#28002789)

Ah the ever popular Request for Citation, the easy but ultimately ineffective method of deflecting anecdote.

What, do you expect someone to have some case study that considers which percentage of all websites ever created outgrow their CMS? Argh, as if! Anecdote is the best you'll get in this type of discussion. Guess what? IT pros get paid based on their knowledge of anecdote; it's called experience.

I agree with OP. Many of these CMS have fairly limited use cases. As soon as you outgrow that you have to hack its core, which often produces less-then-stellar results. Then you have to learn the (in the case of Drupal) byzantine and poorly documented API.

Use Drupal if you want a blog or some kind of a news site where content is published for people to read and comment on. If you want something more, then creating software to fit your need IS NOT reinventing the wheel. It's building for your particular use case. Don't use a hammer when you need a sawzall.

If you want a skyscraper you wouldn't make the mistake of piling prefab houses on top of one another to reach the desired height (after all, the walls are built! Why, it'd be reinventing the wheel to build walls!) If you want an eCommerce site or some other relatively complex or specialized app, then don't make the mistake using an overgrown blog site. The time you save doing things that *are* wheel reinvention (authentication, user profile, other plumbing functions) will be lost when you need to kludge something together to stay withing the framework and still fit your needs, and then have to support said kludge.

Re:Tired of crappy CMS' (1)

rho (6063) | more than 5 years ago | (#28003683)

Then you have to learn the (in the case of Drupal) byzantine and poorly documented API.

This is where I stopped using Drupal.

Well, sort-of. I also had a GPL issue where I had to keep arms-length from a proprietary system in order to integrate with a Drupal system, but mainly it was trying to make Drupal scale. I don't mean scale in the sense of multiple servers, but "scale" in the sense of keeping track of a system of sufficient size. At some point you've got dozens and dozens of modules of varying quality, everything is written in Drupal-ese PHP (two-two-two varieties of crufty functions for the price of one!), and a database that looks like a dog's breakfast. When it comes time to upgrade your Drupal core now you've got a fun game of whack-a-old-and-busted-module.

Drupal is great if your needs are simple or OTS. I still use it for such things. Once you cross a line of sufficient complexity, Drupal can certainly still work, and will get your site off the ground faster--but it's not necessarily better. You're just delaying the inevitable, which is you need a more formal look at your Web site's structure and design. The professionalism required to maintain a Drupal site of a certain size is nearly indistinguishable from that required to build a site from scratch using PEAR modules or something more robust like the Zend framework.

Re:Tired of crappy CMS' (1)

krasmussen (891165) | more than 5 years ago | (#28008841)

I agree with OP. Many of these CMS have fairly limited use cases. As soon as you outgrow that you have to hack its core

Or write a module that has the functionality you're looking for. It's not that much harder than writing it for your homebrew web app, plus other people will be able to benefit from what you've developed afterwards.

Re:Tired of crappy CMS' (0)

Anonymous Coward | more than 5 years ago | (#28013861)

There is no anecdote here, just a blanket statement with absolutely nothing to back it up. Not one single anecdotal example.

Sad but true (-1, Offtopic)

Anonymous Coward | more than 5 years ago | (#28001387)

Most women as they get older will suffer from this, unless of course they have silicone. ;)

Higher Quality Systems (-1, Troll)

Anonymous Coward | more than 5 years ago | (#28001407)

Fuck them niggers. Sending this country to hell in a handbasket they are. Look it that top nigger Saddam Heusain Obamma, pulling the nigger wool over everyone's eyes. That fucker couldn't fool me, nope

The community isn't really vibrant. (3, Interesting)

haeger (85819) | more than 5 years ago | (#28001427)

Looking for answers or reporting bugs is somewhat unsatisfying in drupal. To be honest not really drupal but the modules but since they're actually what makes sites useful. Bugs and supportrequests go unanswered for months unfortunatly.
I love drupal and use it for my own site but finding support is quite hard. Usually it means going into irc and bothering people there which is a bit sad since most answers aren't searchable later. Yes I do try to add the answers I get to drupal.org in case you were wondering.

Ok, so this wasn't exactly on topic but hey, not many drupal stories show up on slashdot so I thought I'd grab the chance to whine a little.

Re:The community isn't really vibrant. (3, Informative)

drinkypoo (153816) | more than 5 years ago | (#28001943)

I've found that if you're using more or less mainstream modules, there's plenty of activity. If you're off on the fringes, be prepared to fix problems yourself.

Re:The community isn't really vibrant. (1)

ari_j (90255) | more than 5 years ago | (#28003713)

I've found that asking questions is a great way to avoid getting answers. Perhaps things have improved since my last attempt at getting into Drupal (n years ago for n on [2,4]), but at the time it was impossible to even find enough API documentation to develop an extension for such eccentric fringes as wanting a sane work flow for content writers.

Re:The community isn't really vibrant. (1)

drinkypoo (153816) | more than 5 years ago | (#28006935)

These days there are modules which provide a sane workflow. I guess other people were working on them. I am somewhat dismayed at how long it is taking to bring out D7, on which I am waiting for any number of projects. D7 has the database refactoring in it.

Re:The community isn't really vibrant. (0)

Anonymous Coward | more than 5 years ago | (#28012665)

This is the classic response to any Drupal query: "There's a module to do that." But what they never tell you is that the module does not work properly with D6 yet, or that the module is just a stub and requires you to create all your pages with Views or CCK or both (which is more complicated than writing the whole site from scratch yourself,) or that the module is not compatible with one of the 17 other modules you already had to install just to be able to put images on your site.

Re:The community isn't really vibrant. (1)

hobo sapiens (893427) | more than 5 years ago | (#28007665)

which is another way to say what I said above: Drupal is fine as a blog or a news site. For everything else, look elsewhere.

Re:The community isn't really vibrant. (0)

Anonymous Coward | more than 5 years ago | (#28014107)

Looking for answers or reporting bugs is somewhat unsatisfying in drupal. To be honest not really drupal but the modules but since they're actually what makes sites useful. Bugs and supportrequests go unanswered for months unfortunatly.
I love drupal and use it for my own site but finding support is quite hard. Usually it means going into irc and bothering people there which is a bit sad since most answers aren't searchable later. Yes I do try to add the answers I get to drupal.org in case you were wondering.

Ok, so this wasn't exactly on topic but hey, not many drupal stories show up on slashdot so I thought I'd grab the chance to whine a little.

you obviously haven't posted anything in CCK, views, or adv forum issue queues. Earl, Michelle and Karen can be pretty damn quick on the replies.

I don't really get what makes going into irc sad, and for it not being searchable later, that's 100% ur own fault. If u take a while to find a solution, but u find it eventually... how about you document it hm? or do u rly expect every1 else to do everything for u?

but yea, trolling IRC pretty much 24/7 has made me come to understand that 95% of the questions posed there, can be googled in 5 mins

the only issue with (-1, Offtopic)

nimbius (983462) | more than 5 years ago | (#28001765)

front-end drupal ive found is that in a no-fault state your insurance still goes up if you have one. i guess thankfully headrests and airbags prevent your drupal from causing any long-term damage to the head neck and back.

Front End Drupal (0)

Anonymous Coward | more than 5 years ago | (#28002025)

I had front end drupal once. But it's amazing what Viagra can do!

Drupal cannot currently be taken seriously (5, Informative)

message144 (1246846) | more than 5 years ago | (#28002181)

I have been developing for Drupal for 5 years, with a portfolio of many large scale projects. I am also the author of some popular Drupal modules.

With all that said, in my experience, Drupal offers zero TCO or ETA advantage over Django or Symfony on any medium to large project. A lot of the great things you may hear about Drupal are coming from either (a) Non-developers or (b) People who have staked their careers on Drupal.

A few reasons why Drupal cannot be taken seriously include...

1) Lack of unified model layer and no ORM. The recent efforts to implement schema definitions are still, unfortunately terrible. All content types should be able to be defined as a model, including CCK fields.

2) Over-reliance on Views and CCK modules. These are just fancy interfaces for a model layer. They are great for non-developers, but in no way compare to a proper model implementation. At the end of the day, you will save zero time by implementing a Drupal View over implementing a simple ORM call. Views and CCK slows down development.

3) Lack of any solid deployment procedures. Ever tried merging changes between different Drupal configurations?

4) Using native PHP as the templating language. This causes more headaches than one you can possibly believe. A proper templating language should be used instead which will prevent lazy or incompetant developers from adding business logic into templates.

5) An army of incompetant, unexperienced developers contributing sub-par modules.

6) Lack of any kind of namespacing whatsoever. "De-Facto Namespacing" is a pile of shit.

Re:Drupal cannot currently be taken seriously (3, Interesting)

timothyf (615594) | more than 5 years ago | (#28002969)

I won't comment on the ORM, Views and CCK stuff beyond agreeing that it could be a lot better (though what we have now is much better than where we were). I'm not sure what would constitute solid deployment procedures for you, so without an example I can't comment.

4) Using native PHP as the templating language. This causes more headaches than one you can possibly believe. A proper templating language should be used instead which will prevent lazy or incompetant developers from adding business logic into templates.

I can't say that I agree with you on that--most of the template engines I've seen end up replicating a high percentage of core PHP--but in any case, it's a problem that has been fixed already by theme engines. Don't like phptemplate? Use Smarty: http://drupal.org/project/smarty [drupal.org] or develop your own theme engine.

5) An army of incompetant, unexperienced developers contributing sub-par modules.

I would say that's not so much the problem as that there isn't a good way to separate the wheat from the chaff currently, though it sounds like that's in the works for the next iteration of drupal.org.

6) Lack of any kind of namespacing whatsoever. "De-Facto Namespacing" is a pile of shit.

Heh. Agreed, though I think that this is somewhat a function of the lack of namespacing in PHP influencing the design.

Re:Drupal cannot currently be taken seriously (0)

Anonymous Coward | more than 5 years ago | (#28003645)

I still don't understand why so few PHP developers still don't know about PHPTAL, or the Midgard CMS(which is propbably one of the most sexiest PHP CMS's for developers).

Re:Drupal cannot currently be taken seriously (1)

ari_j (90255) | more than 5 years ago | (#28003841)

The debate between "template languages end up implementing most of PHP anyhow, so just use PHP for your template language" and "you should maintain model and view separation, and using PHP for your template language makes it too tempting and easy to break that separation" will never end. One thing to keep in mind, for both sides, is that PHP is nothing but a template engine that has outgrown its britches. Using it to develop a CMS is bound to end up breaking model/view separation by having templates with business logic in them and business routines with display logic in them. Only developer discipline can really maintain cleanliness in that department. A large, distributed project with many user-contributed modules is guaranteed not to have such discipline on a global scale.

Re:Drupal cannot currently be taken seriously (1)

dahmak (1247438) | more than 5 years ago | (#28003483)

I have been playing around with drupal among other crappy content management systems such as Joomla 4 years ago I gave up and that is when we decided to build our own content management system from scratch, what we wanted to achieve was an extremely easy way to integrate templates without having to be a rocket scientist, we decided to use Smarty for that, we wanted to build our own plugins that were guaranteed to work with each other without introducing security issues, now 4 years down the line we have a content management that is mature and rich but is still simple enough to use without having to read through a library of documentation to get it to do what you want it to do. We have been thinking of open sourcing objectCMS but decided against it because of the problems that can arise with 3rd parties developing modules, so we decided to keep all development within Systrix (http://www.systrix.com ).

Re:Drupal cannot currently be taken seriously (1)

gobbo (567674) | more than 5 years ago | (#28006559)

Karim, your site looks great at first but it has a huge navigation bar with mostly non-functional links -- a show-stopper. The site does a great job of promoting objectCMS up to the point where it 1) fails to describe its licensing in any way and 2) doesn't offer a way to download it.

That's completely amateur, with slick gradients and rounded corners attached, especially for a SEO company.

Too bad, I was intrigued, hoping to find a CMS for a large media archive.

Re:Drupal cannot currently be taken seriously (3, Insightful)

Anonymous Brave Guy (457657) | more than 5 years ago | (#28003497)

Would you be willing to elaborate a little on your concerns, please?

Some colleagues and I are about to start a major overhaul of a moderately large site (a few dozen pages, a few thousand users, a few hundred visitors per day). It seems like the first choice is basically between "standard framework with some plug-in custom features" (CMSes like Drupal) and "custom architecture with some standard plug-in features" (using things like Django and some common libraries).

So far, we've been forming the opposite view to you: a lot of the site we'll be producing is static content, but a few parts will require moderately structured data (the equivalent of a few tables and some simple SQL queries), and for that balance Drupal seems like the best tool we've considered so far. We don't have much experience with these particular tools, but the guys building the system will be proper designers/developers, while the guys maintaining some of the content will be entirely non-technical. Is our situation just different to what you're describing, or are there really a bunch of problems waiting for us a little way down the line?

Re:Drupal cannot currently be taken seriously (1)

hobo sapiens (893427) | more than 5 years ago | (#28007873)

I am a LAMP developer who was kind of thrown into doing Drupal development. Maybe I can offer some insight.

If you don't have *Drupal* developers, forget it. Drupal's famous learning curve will prevent your guys from working for a while (its been frustrating for me). Documentation isn't great. There are a few books, but...it's *very* complex.

Drupal is more than a mere MVC. It does some cool things, like Inversion of Control (via its hooks) and it does some things I feel a pretty lamebrained (it's so modular you lose performance, sort of like what happens when you over-normalize database tables. Or the way it handles error messaging, forms, and stuff that could be a LOT simpler) Personally, I think in software design simplicity should almost always win out over complexity. Drupal isn't simple. Many will say that's a result of it's flexibility. It is flexible, but that's a cop out. Plus, in spite of it's flexibility...you'll still hit limitations of some kind. Guaranteed. Why? Cause the Drupal developers aren't a bunch of omniscient galactic entities. Yes, they cannot possibly foresee every use case. Drupal is often painted as the panacea for all of your website needs. Shocking as it may seem, it's not quite that.

If you have a blog or some kind of news site that will allow you or others to publish stories and comment on the stories, go for it. If you need something else, you'll be busy cajoling Drupal into cooperating. If you have a LOT of data and you requires users to manage data in bulk fashion (or some other data-heavy operation), forget it.

If you don't fit neatly into that box, here's how you find out if Drupal is for you: install it. Find modules that do roughly what you want. Make them do what you want without doing any coding, and be prepared to make concessions on functionality. If you have the features you need, load your data. If this doesn't kill Drupal (or the modules, to be precise) then bang on it for a while. Any features you cannot make work via the admin panels you should probably forget about unless you want to 1) write your own modules, or 2) make code changes which will probably render your site unable to be easily patched. After all that, replicate the site you set up on another server. If after all of that, it still works, then it might be a good solution. That sounds like a lot, but one sharp person can probably get a good feel for it in a month or two.

If you like all that, then make a decent theme for yourself. All of the existing ones I have seen (and I have looked at the most touted ones) have had serious usability and accessibility issues, as well as a very generic and unimaginative looking design.

Have fun. After I leave this job, let's just say I won't be putting Drupal on my resume. If one day I decide to set up a blog, though, I'd give Drupal a go. But I hope to never have to deal with it again at work. It's way too amateur in too many places, it's convoluted, it's frustrating, and for all it buys you out of the box, there are a lot of limitations to deal with. The more you customize, the denser of a web you weave and it can get really really bloated and complex really fast.

Oh, and totally with you on the user page here on /.

Re:Drupal cannot currently be taken seriously (1)

Anonymous Brave Guy (457657) | more than 5 years ago | (#28009455)

Thanks for sharing your experience and insights. It sounds like both your background before Drupal and your general views of development are pretty similar to most of our guys.

We've reached the first test you described so far: we've got a test install, and established that much of what we need can be done with the core plus a few modules built around CCK and Views for the custom data. Some of it is indeed not as simple as with just writing a bit of database code, to be sure, but so far it's been close enough in our case.

What sounds like the deal-making feature for us is essentially the inversion of control you mentioned: we are moving from an eclectic system with numerous individual scripts in more than one language, and having a systematic framework where we know exactly where each bit of custom code we've written hooks in has a lot of value in itself. But as a result of your comments, at least we know to look out for the performance, replication and bulk data issues as we start more detailed trials, so thanks again for the contribution.

Re:Drupal cannot currently be taken seriously (1)

railbaron (1116003) | more than 5 years ago | (#28011713)

I think Drupal can be taken seriously, but I'm just a casual user. I'm learning how it works in my spare time by setting up a web site and seeing what works and what doesn't. One resource I've found that has made it easier to separate the wheat from the chaff (as far as modules go) is the book Using Drupal [usingdrupal.com] , reviewed here [slashdot.org]

Maybe Drupal is an amateur CMS and all I'll get out of it is a beautiful blog, wiki or image gallery, but it seems to have a lot of potential. There are modules for e-commerce, file handling, security, and many others. It works well with PostgreSQL (my database choice) and other databases. There's a lot of capability here. One just has to proceed cautiously - reading, planning and testing - as with any big project.

Re:Drupal cannot currently be taken seriously (2, Interesting)

yareckon (1236270) | more than 5 years ago | (#28004017)

I disagree about the importance of many of your points in the grand scheme of things (when considered against the benefits of a very capable core platform with literally thousands of plugins).

However, some of what you say is important, is widely acknowledged, and is being actively worked on. Deployment and change management for content and configurations in particular has been a weak point of drupal to this point, but there are now several major projects underway that attack this from different angles. I think the tools will get dramatically better in the next year if the presentations at drupalcon DC 2009 were any indication.

Also, I think your overall approach to web development is way over on the cathedral side (which may be because of your focus on the needs of large projects, granted). Drupal's community ecosystem flourishes on building on other folks's work. The hook system, allowing modules to exchange events and pass control back and forth, performs the same function in code. It's a very bazaar model once you get out into the contrib repository. You will need to wade into the community to get the most out of drupal, IMHO.

Re:Drupal cannot currently be taken seriously (1)

hobo sapiens (893427) | more than 5 years ago | (#28007941)

"Deployment and change management for content and configurations in particular has been a weak point of drupal to this point"

I'd agree, and that in itself makes Drupal a real pain for any kind of real development shop (dev, test, prod servers which should be more or less in sync after a release.)

"You will need to wade into the community to get the most out of drupal, IMHO."

Another thing I dislike. I like community, don't get me wrong. I have been working with a few developers of some popular Drupal modules, and they have been very helpful. But to someone who is evaluating Drupal, why would they want to jump into a community if they aren't going to go with Drupal? Drupal needs some decent "How to get started..." documentation. By that, I mean not just how to install it. I mean a more condensed version of the book "Pro Drupal Development". I should be able to read up on how to implement a hook without having to read API documentation that makes too many assumptions on what I know about Drupal. You'll probably provide a link to counter my last statement, but I think you know what I mean here ;)

Personally, anytime a CMS needs a few books dedicated to it, that means that it's grown too large. Don't you think it'd be better to do one or two (or three or four) things really well, and leave the rest alone? Honestly, comparing Drupal with other CMS packages, I think Drupal's strength isn't that it's great at anything. It's more of a matter that it does some things reasonably well and doesn't do anything remarkably horrid like roam the countryside at night eating babies like some other CMS do. That's not a good way to be the "best"; it's called being the tallest midget.

This comment is bunk (1)

Ice Station Zebra (18124) | more than 5 years ago | (#28004321)

Drupal is not RoR or Django, so don't compare apples and oranges. First, a Drupal view is not equivalent to ORM. A Drupal view is on a higher level. It takes drupal content, lets you slice, dice and display it. Maybe you meant CCk. As to not using PHP as a templating language, you can always use the smarty engine if you want, but then you are just adding another layer of stuff that could break or cause security issues.

Now, Drupal is not perfect, but what it does it does well.

Re:This comment is bunk (0)

Anonymous Coward | more than 5 years ago | (#28019029)

The problem is that Drupal alone does almost nothing unless you add on a large number of low quality, poorly documented modules which often are incompatible with each other.

Author Names (0)

Anonymous Coward | more than 5 years ago | (#28002207)

Is it just me or do the names of the authors sound made up? It must've been rough growing up with name like "Hogbin". And "KÃfer" is German for "bug".

And I thought working with Drupal made life miserable enough...

;-)

Re:Author Names (1)

yareckon (1236270) | more than 5 years ago | (#28003295)

At one presentation I attended, Emma Jane joked about trying to marry out of her name. And I assure you Konstantin is real enough too, but they are both pretty memorable as far as names go :)

heh... (2, Funny)

Gabbermatt (1120399) | more than 5 years ago | (#28002537)

And here I thought this was going to be a book about what happens to women when they grow older...

Re:heh... (1)

cerberusss (660701) | more than 5 years ago | (#28011131)

Ahh if it happened to women only... *sniff* here I am, 56 years old, and the proud stallion is now a tame pony :D

CMSes and my opinion (5, Interesting)

Vamman (1156411) | more than 5 years ago | (#28002779)

Let me take a step backwards for a second and explain my situation. I've been developing for the web for many years now and I've seen technology come and go but I've never seen an idea of an OpenSource web portal take such a strong hold as Joomla! has. PHPNuke was close but even then you rarely randomly stumbled upon a Nuke site every second search. However, unlike Nuke, Joomla seems to have taken over like a bad storm.

I still have some websites lingering around that use Joomla but I am very much dissociated with that CMS, infact any CMS nowadays. I find the issues that these systems bring to the table far outweigh any little added productivity that a small group can sustain. There are teams of script kiddies from Asia and elsewhere scouring online websites for these systems to prove just how easy they are to hack into. If you have an online database with confidential client information, you are in trouble.

The largest website I manage is my own and it ran Joomla for 2 years while I was working on my MSc degree. I had to deal with repeated attempts by hackers to break into this website. It was very frustrating after scouring logs on my linux server to find out that they came in through one of the "secured" CMSs. SQL injections, cross site scripting hacks, upload/media vulnerabilities, you pretty much name it that so called secure web server had one big gaping hole in it and that was Joomla.

I peruse Joomlancers sometimes when looking for some spare cash (freelancing site dedicated to Joomla) and try to encourage local North American companies to ditch this disaster of a CMS. Not only do you have to deal with bugs and exploits at the core but when people load up this CMS with extensions that are mostly all crap (even Community Builder can't seem to get it right) you put together a nice looking template (like this guy with his book from Drupal suggests) and then put it out there for the "Mad Dogs of Vietnam" to hack into and make your online reputation look like shit.

I salute the chap that pointed out how vastly the Joomla community is growing with its extensions and micro-economic community, its a good point really. But if you take a look at whose running these communities (Joomla Art, a popular Joomla template company, Joomlancers, and others) are all owned by a Vietnam company that has less than stellar ethics when dealing with clients - Just search the Joomla forums. I have to wonder why the top contributors and hackers are all from the same city Hai Noi =) Birds of a feather I suppose or is that just job "security"?

I got out as fast as I got into looking after websites running Joomla. Last year we had 13 clients running Joomla and what a headache I developed looking after these sites. The previous freelancers knew how to use a CMS and after that they knew nothing. Even their half-assed attempts at building in additional functionality was more of a joke than anything. I had clients breathing down my neck over issues that were really out of my control. One day I woke up and realized that the real issue was Joomla and thats when I drew the line with it. Now a days I only work for clients that will develop from the ground up. I no longer have to deal with the types of security issues that these open CMS systems bring to the table. They are great to impress a client in a hurry with something that looks and works right away but as the days turn into months you will have the gut feeling like "what did I do..." ...don't do it. Build yourself a core set of functions and your own library in PHP and then build ontop of that individual sites. Code Ignitor among others still get a thumbs up from me. Don't use the same mysql fields all the time. Change your database connection strings up. Change critical global variables every now and then. Thats my 2 cents.

Re:CMSes and my opinion (1)

indiechild (541156) | more than 5 years ago | (#28005641)

Somewhat off-topic, but I was wondering if you've tried ExpressionEngine? It's not open source, but it's definitely the most user-and-designer-friendly light-weight CMS I've used.

Re:CMSes and my opinion (1)

mmsimanga (775213) | more than 5 years ago | (#28007985)

I work for a company that provides Business Intelligence services. While we are all highly competent IT professionals none of us are developers. Using Drupal we have been able to set up our knowledgebase and task tracking system mainly using CCK and Views modules.

The point I am trying to make is for individuals like you who can write code, do write your code. But if your core business is not writing code and you need to create some sort of web application without having to learn to code then a CMS is a good idea.

I am not sure on my own with my limited knowledge of PHP (and limited time) if I could create something more secure than Drupal.

Drupal (1)

ezwip (974076) | more than 5 years ago | (#28003691)

I have toyed with Drupal on occasions but I wouldn't call myself a developer. I mostly use other people's plugins and modify the skins. Unfortunately skin wise I had nothing to work with.

Jesus! Frustrated book editor much? (0, Troll)

PCM2 (4486) | more than 5 years ago | (#28004191)

While I appreciate book reviews on /. that actually take the time to say something critical about the book, this one is just ridiculous.

Every chapter ends with a summary, and not a single one of them is useful or needed. Any unique information conveyed in them should have been merged with the introductory paragraphs for the respective chapters, which is where readers would be looking anyway to see what each chapter addresses.

Yes. Agree completely. Nobody would ever be looking for what a chapter addresses in the summary.

The book has numerous minor problems, including grammatical and stylistic errors, such as dashes incorrectly performing the duty of semicolons, some URLs missing the root directory slash, and excessive use of exclamation marks (more than a dozen before even reaching the second chapter).

Really? Seriously? Since you claim to be a writer, you of all people should know that stylistic "errors," such as using too many exclamation marks, are really just different stylistic preferences. Similarly, opinion differs about the trailing slash on URLs. And as for dashes vs. semicolons, you might want to get your head out of your Shakespeare First Folio and read a magazine sometime.

As is typical in a first edition, the book contains several errata:

...which is why most readers feel perfectly comfortable overlooking them. Honestly, has anybody (except you) ever looked at a diagram and gnashed their teeth at poor capitalization?

Scattered throughout the manuscript are tips, each indicated with a pencil tip icon. These help to break up the text visually, and provide valuable guidance. The contrast between the black text and the dark gray background could certainly be improved ...

Seriously?? Seriously?? OK, I've never met William Shatner, though I'm fully willing to admit that I'm no William Shatner; nonetheless (note my use of a semicolon there), I mean it sincerely when I say GET A LIFE.

2 more cents on the open source CMSes of today (2, Insightful)

room34 (1557423) | more than 5 years ago | (#28004805)

As someone who has been developing custom CMSes at various jobs for over a decade, I've gotten to know what makes a CMS work (or not) quite well, and I've given most of the popular PHP-based open source CMSes (especially Drupal, Joomla, and MODx) more than a fair chance to impress me.

So far, I always eventually get frustrated with their arcane and idiosyncratic ways of doing things, which often require as much new specialized knowledge as learning a programming language in itself, and in the end they're never quite the right tool for the job anyway.

Now that I've been freelancing full-time for a year, I've come to a decision I'm satisfied with: as far as I'm concerned, there's only one pre-built CMS I've never been disappointed by, and believe it or not it's WordPress. But WordPress of course is not ideal for every site (it IS, however, ideal for lots of small- to medium-sized sites, not just blogs). Concurrently I've been developing my own custom CMS on CakePHP, tailored to the specific needs of my clients, and expanded as necessary as I've been adding more clients who are using it.

So, what it boils down to for me is this: assess the client's requirements, determine whether or not WordPress fits the bill, and either go with WP or use my own proprietary CakePHP-based CMS, expanding it as needed.

Maybe if one of the "big" open source CMSes were built on one of the equally "big" open source MVC frameworks, it would be worth investing the effort into getting to know inside and out, but just as I've made the decision to focus on PHP as my development language of choice, I've also had to decide to focus on one framework (CakePHP) and one CMS (my own) to know intimately and be able to build upon as needed.

It's not so much a matter of "staking my career" on it as it is of focusing on my strengths and building upon them. The whole point of freelancing is to get more bang for my buck in terms of productivity (and income) per hour worked. And so far, Drupal, Joomla, MODx, whatever... they just don't fit into that model for me.

Re:2 more cents on the open source CMSes of today (1)

dave420 (699308) | more than 5 years ago | (#28010129)

Wordpress is NASTY. Jesus Christ it's horrific. Ugh. Sprawling spaghetti-code, hideously written. Nasty.

CMS should have no "front end" (1)

Stan Vassilev (939229) | more than 5 years ago | (#28008275)

The fact we have a book on front-end CMS design is irony in itself.

The problem with popular CMS systems today stems from the tight coupling of back-end architecture and front-end architecture.

Remove the coupling, and the need for a book on Front End Drupal vanishes, leaving us with a simple API which we can integrate with our own custom or third party front-end.

Re:CMS should have no "front end" (0)

Anonymous Coward | more than 5 years ago | (#28008499)

I agree with this and it's one of the reasons I like drupal. It makes the back-end, which used to be the largest part of a job (setting up a way to put data into a system), into the smallest.

With the way templates work, you're pretty much free to do whatever you want. And honestly, if you just want to throw out the drupal front-end system altogether you could do that, and either use their API to get the data you need or just write your own way to get the data out of the database in the way you want.

I have to say, though, I tried dozens of other CMSs over the years and always hated them (as most people on slashdot today seem to hate them). Drupal is the first one I've found to be robust, intelligently put together (you almost never have to hack the core files for any reason, despite what many people are claiming), and ridiculously easy learning curve (again, against what most people here are saying... but then, I suspect they tried to jump right in as programmers looking for things to develop rather than realizing 98% of what you need is already out there).

Re:CMS should have no "front end" (1)

railbaron (1116003) | more than 5 years ago | (#28016667)

Remove the coupling, and the need for a book on Front End Drupal vanishes, leaving us with a simple API which we can integrate with our own custom or third party front-end.

I disagree. With decoupling you might have a simple API, but that API is specific to the CMS you're using. You might still want to have a book from which to learn how to use it to create front ends.

Re:CMS should have no "front end" (0)

Anonymous Coward | more than 5 years ago | (#28023897)

I disagree. With decoupling you might have a simple API, but that API is specific to the CMS you're using. You might still want to have a book from which to learn how to use it to create front ends.

You're missing the point. If the API is designed well you won't be using it to create front ends, but just to fetch the page data to insert into an existing front end made by other means. Which negates the point of a Drupal Front End book. Maybe a chapter on the API in a Drupal Backend book.

Ru Paul (0)

Anonymous Coward | more than 5 years ago | (#28011405)

I am also interested in the front end of Ru Paul, please post more information.

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>