Slashdot Mirror
Drupal 6: Ultimate Community Site Guide
Michael J. Ross writes "Among the more popular and better-regarded content management systems (CMSs), Drupal is distinguished partly by its building-block approach, in which a website's functionality is built up in pieces, each of which is a module (either core or contributed). The opposite approach — using far fewer but more encompassing modules — is generally preferred by non-developers who do not relish integrating a sizable collection of modules or trying to modify the underlying code. Nonetheless, anyone who wishes to build a Drupal-based social website, can learn how to do so in a new e-book titled Drupal 6: Ultimate Community Site Guide." Read below for the rest of Michael's review.
Drupal 6: Ultimate Community Site Guide
author
Dorien Herremans
pages
140
publisher
Holistic Vibes
rating
7/10
reviewer
Michael J. Ross
ISBN
978-2839904902
summary
How to create a Drupal community site using contrib modules.
Published by Holistic Vibes Sàrl in 2009, the book was written by Dorien Herremans, an independent Web developer in Belgium who holds an MSc degree in MIS from the University of Antwerp, and has lectured in IT and 3D computer animation at Les Roches University of Applied Sciences, in Bluche, Switzerland. Her Drupal story is no doubt similar to that of many other Web developers: After building numerous sites in Drupal, she decided to create a new community site — in this case, Raw Vegan Dating. She was well aware that other CMSs offered fairly sophisticated modules that could be dropped into a fresh CMS installation, thereby creating a new community site instantly. But that approach generally requires one to accept the functional limitations of the chosen module, or start hacking the module's code (which for most modules is poorly written and equally poorly documented), with no guarantee that one's modifications will even work. Dorien instead opted for Drupal's flexibility, but found the development process rather difficult and time-consuming, partly because of some technical issues that arose: How can one easily create advanced profiles in Drupal? Can one add a photo gallery to each profile? Ultimately, these lead to a much broader question: Is it possible to build a feature-rich community/dating site using only core and contributed modules, without having to make any modifications to them?
Dorien set out to answer that question, in developing a new site, Drupal Fun, which is a community primarily for Drupal users who have read the book and wish to help each other. The site also offers a few tutorials on how to convert to the latest versions of modules. In making that site, Dorien utilized only available modules, with no changes, and documented each step in the process. The lessons learned from that effort form the foundation of Drupal 6: Ultimate Community Site Guide. The first three chapters constitute an introductory foundation; the next two cover user profiles; and the remaining four major chapters explain content, monetization, etc. For all topics, the Drupal Fun site is used as a case study. Even though the book focuses on Drupal version 6, and the example site is created using that version, the book does have notes on how to implement everything in version 5 as well.
In the book's introduction, the author provides a brief overview of Drupal, virtual communities, and her perspective on how to build one of the latter using the former. She states that it is easy to resort to custom modules — i.e., modules created or modified by oneself — but this contradicts one of the central tenets of the book, that a non-programmer would find it difficult if not impossible to go beyond already-available modules in building a community site (unless of course he were to outsource the development of the custom modules). In a footnote, it is incorrectly stated that "You can use the Drupal interface to write a module yourself" (page 4).
The second chapter, titled "Setting up the site," explains the desired functionality of the example site to be created (including the site's main goal, which redundantly was also presented at the end of the previous chapter). The author explains how to install Drupal on one's local Web server. A Windows-only developer may be confused by steps 2, 3, and 8, which are specific to Linux/Unix, but not labeled as such. The expression "hidden files" (page 10) would mean in Windows any files with their "hidden" attributes enabled. But in this case the author is probably referring to a single file, ".htaccess," in the Drupal root directory, because in *nix parlance a file is considered hidden if its name consists only of an extension (such a file is not shown in directory listings by default). The chapter concludes with several figures, which should have been interspersed throughout the earlier narrative.
Any reader following the book should at that point have a working copy of Drupal in his development environment. Chapter 3 explains some basic configuration settings for the newly-installed Drupal instance, as well as how to install modules and themes. However, some of the information is presented in a potentially confusing manner, such as on page 16 when an absolute directory path in one step, is immediately followed by what appears to be another absolute directory path in the next step ("/admin/build/modules"), but is actually meant to convey a navigation path within the Drupal user interface. For a book intended for Drupal newbies, it is essential to clarify technical issues such as this one, because otherwise readers can quickly become frustrated, wondering what the author is discussing and how to follow along in their own Drupal instances. Later, a favicon is described as residing "on the top of your browser window," but that would be the browser icon; rather, favicons are next to the browser's location field and in any relevant tabs. The author briefly describes more than half a dozen modules that arguably should be included in any Drupal site, including ones for dynamic menus, spam control, and task scheduling. Links to the modules' pages — in the text and/or as links in the PDF e-book — would have been quite helpful. The Tagadelic module is recommended for generating tag clouds, including a friendlier 404 error page, using the directory path "/tagadelic"; but Figure 3.5 shows the setting without that leading slash, and a quick test suggests that it does not work. More importantly for the newbie reader, there is no explanation as to how to start using tags. This chapter — like all that follow, except for the last — concludes with a list of contributed modules discussed in the respective chapter. Given that the chapters are short, and the modules' names easily stand out, these module lists add no value and could be removed in a future edition.
In Chapter 4, the reader learns how to use the Content Profile module for making highly functional and versatile user profiles that include photo and video galleries, avatars, contact forms, social networking, map locations, personal Web pages, AdSense revenue streams, and more. Most of the instructions are straightforward, but the discussion on how to implement avatars, on page 30, should have been fleshed out (no pun intended) — with more details as to exactly what settings to make, and where. Chapter 5 extends the previous topic, by demonstrating how to enhance the new user profile content type by implementing additional functionality: image and video galleries, a site member's location on a world map, member search, and featured members. In the next chapter, the author shows how to add more text-oriented content types, using the Views, Panels, and Fivestar modules.
While the first six chapters of the book focus on how to create functionality for users, the three chapters that follow examine how to create functionality for the online community itself. Chapter 7 discusses the details of adding forums, shout boxes, buddy lists, messages, subscriptions, a newsletter, user points, user status, user activity (think Twitter), and user groups. Chapter 8 explains how to utilize Google AdSense, affiliate programs, and donations — so that site owners and members can receive some sort of financial reward for their community-building efforts. Chapter 9 covers subjects that a site builder will encounter near the final stages of site development, such as finalizing the navigation menus, providing a post-registration page, supporting internationalization and localization, customizing system e-mail messages, tuning site performance, promoting a new site, tracking a site's popularity with analytics, performing module updates safely, backing up Drupal files and database, and duplicating a site.
Drupal 6: Ultimate Community Site Guide is wrapped up with a brief chapter, an author bio, and an unnecessary marketing description of the book. Unlike most programming books, this one is missing an index — although, as an e-book, it can be searched far easier than a print book.
The list price of the book is a very reasonable €7.70, and it is currently available for €5.50. Even though it is registered under the ISBN 978-2839904902, it is currently not available from Amazon.com, because it is an e-book, and the Amazon.com Kindle is not yet available in Europe; this apparently prohibits European publishers from using it. However, the book's website makes it possible to purchase it online. That site also has more details on the book's contents and the author. In addition to the book site, the first three chapters can be previewed online, via its Google Books listing.
Like any technical work, this one has its strengths and weaknesses. Sadly, the book is marred by generally sloppy writing, with a high ratio of errors to pages. There are several errata: "to[o] much" (pages 4 and 79), "others[']" (page 5), "look[s]" (page 16), "fig 3.3" (page 17; should read "Figure 3.1"), "Imagecache_actions Module" (page 52), "eld avatar" (page 66), "other then" (page 69), "others['] contact link" (page 94), "less then" (page 117), "Clustermaps" (page 124), and ."[my]sql file" (page 128). Also, there are many instances of awkward or incorrect phrasing, such as "harmonic" (page 2; should read "in harmony"), "Skippy balls" (page 3; hint: they have nothing to do with peanut butter), "expansive" (page 4; should read "extensible"), "6-versions" (page 9), "and a while" (page 20; should read "in awhile"), "brackets" (page 26; should read "parentheses"), "200% satisfied" (page 34), "Fixfertig" (page 76), "a grip out" (page 83), and "yourbranch" (page 112). Some of these may be European expressions, though Google suggests otherwise. There are missing commas and hyphens, some punctuation marks used incorrectly, and numerous sentences split at the coordinating conjunction into separate (incomplete) sentences. The use of case and spaces in proper names throughout the book are oftentimes incorrect, e.g., "MySql" (page 10 and others), "ftp" (page 10), "cleanURLs" (page 15), "phptemplate" (page 16), "Dhtml" (page 23), "tagadelic" (page 31), "html" (page 98), and "Paypal" (page 113, etc.). Most of the PHP snippets do not have any proper code indentation. Web accessibility proponents will cringe at the table-based positioning. The book's first "chapter" is really an introduction, and should be relabeled as such. The "Acknowledgments" and "Overview" pages have the same page number. Chapter titles are not in title case, but in sentence case. The side notes, used to indicate unstable releases, are rather annoying, because each one of them is positioned so that it looks like a continuation of the narrative line to the left of it. All of these side notes — and perhaps the information in the footnotes as well — should be merged into the narrative. As of this writing, the book's site claims that the book has more than 100 screenshots, but by my count there are 87 of the them. All of these blemishes — none serious — suggest that no technical editing was done prior to publication.
However, the main problem with the book is how, at several points in the narrative, the author assumes too much understanding on the part of the reader, and does not provide enough details for the reader who is trying to implement each suggestion on his own computer and yet has never before worked with the modules in question, or even the key concepts. This problem is seen in entire sections (such as the tagging section mentioned above) and lone sentences (such as the baffling "If you want to change a preset later on, just flush the preset after making the changes..." on page 46).
But none of these weaknesses diminish the overall value of this contribution to the Drupal literature. The book largely achieves its goal of teaching the reader how to create his own Drupal-based community site, using core and contributed modules only, with no custom programming (with the exception of some code snippets stored in the Drupal database). The explanations are, for the most part, clear enough for the reader to step through the process within his own Drupal installation. Some people may fault the book as being too lightweight and lacking the in-depth discussions typical of most Drupal books. But those detractors would be missing the point: This particular title is written for a different target audience, namely, people who wish to build a new website as quickly and easily as possible, and who may not have the knowledge or time to write custom code.
With plenty of detailed instructions, and an upbeat tone throughout the presentation, Drupal 6: Ultimate Community Site Guide can serve as a useful and fast-paced beginning resource for any Drupal developer who wants to create a social media website, requiring minimal time and custom PHP code.
Michael J. Ross is a freelance Web developer and writer.
Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Dorien set out to answer that question, in developing a new site, Drupal Fun, which is a community primarily for Drupal users who have read the book and wish to help each other. The site also offers a few tutorials on how to convert to the latest versions of modules. In making that site, Dorien utilized only available modules, with no changes, and documented each step in the process. The lessons learned from that effort form the foundation of Drupal 6: Ultimate Community Site Guide. The first three chapters constitute an introductory foundation; the next two cover user profiles; and the remaining four major chapters explain content, monetization, etc. For all topics, the Drupal Fun site is used as a case study. Even though the book focuses on Drupal version 6, and the example site is created using that version, the book does have notes on how to implement everything in version 5 as well.
In the book's introduction, the author provides a brief overview of Drupal, virtual communities, and her perspective on how to build one of the latter using the former. She states that it is easy to resort to custom modules — i.e., modules created or modified by oneself — but this contradicts one of the central tenets of the book, that a non-programmer would find it difficult if not impossible to go beyond already-available modules in building a community site (unless of course he were to outsource the development of the custom modules). In a footnote, it is incorrectly stated that "You can use the Drupal interface to write a module yourself" (page 4).
The second chapter, titled "Setting up the site," explains the desired functionality of the example site to be created (including the site's main goal, which redundantly was also presented at the end of the previous chapter). The author explains how to install Drupal on one's local Web server. A Windows-only developer may be confused by steps 2, 3, and 8, which are specific to Linux/Unix, but not labeled as such. The expression "hidden files" (page 10) would mean in Windows any files with their "hidden" attributes enabled. But in this case the author is probably referring to a single file, ".htaccess," in the Drupal root directory, because in *nix parlance a file is considered hidden if its name consists only of an extension (such a file is not shown in directory listings by default). The chapter concludes with several figures, which should have been interspersed throughout the earlier narrative.
Any reader following the book should at that point have a working copy of Drupal in his development environment. Chapter 3 explains some basic configuration settings for the newly-installed Drupal instance, as well as how to install modules and themes. However, some of the information is presented in a potentially confusing manner, such as on page 16 when an absolute directory path in one step, is immediately followed by what appears to be another absolute directory path in the next step ("/admin/build/modules"), but is actually meant to convey a navigation path within the Drupal user interface. For a book intended for Drupal newbies, it is essential to clarify technical issues such as this one, because otherwise readers can quickly become frustrated, wondering what the author is discussing and how to follow along in their own Drupal instances. Later, a favicon is described as residing "on the top of your browser window," but that would be the browser icon; rather, favicons are next to the browser's location field and in any relevant tabs. The author briefly describes more than half a dozen modules that arguably should be included in any Drupal site, including ones for dynamic menus, spam control, and task scheduling. Links to the modules' pages — in the text and/or as links in the PDF e-book — would have been quite helpful. The Tagadelic module is recommended for generating tag clouds, including a friendlier 404 error page, using the directory path "/tagadelic"; but Figure 3.5 shows the setting without that leading slash, and a quick test suggests that it does not work. More importantly for the newbie reader, there is no explanation as to how to start using tags. This chapter — like all that follow, except for the last — concludes with a list of contributed modules discussed in the respective chapter. Given that the chapters are short, and the modules' names easily stand out, these module lists add no value and could be removed in a future edition.
In Chapter 4, the reader learns how to use the Content Profile module for making highly functional and versatile user profiles that include photo and video galleries, avatars, contact forms, social networking, map locations, personal Web pages, AdSense revenue streams, and more. Most of the instructions are straightforward, but the discussion on how to implement avatars, on page 30, should have been fleshed out (no pun intended) — with more details as to exactly what settings to make, and where. Chapter 5 extends the previous topic, by demonstrating how to enhance the new user profile content type by implementing additional functionality: image and video galleries, a site member's location on a world map, member search, and featured members. In the next chapter, the author shows how to add more text-oriented content types, using the Views, Panels, and Fivestar modules.
While the first six chapters of the book focus on how to create functionality for users, the three chapters that follow examine how to create functionality for the online community itself. Chapter 7 discusses the details of adding forums, shout boxes, buddy lists, messages, subscriptions, a newsletter, user points, user status, user activity (think Twitter), and user groups. Chapter 8 explains how to utilize Google AdSense, affiliate programs, and donations — so that site owners and members can receive some sort of financial reward for their community-building efforts. Chapter 9 covers subjects that a site builder will encounter near the final stages of site development, such as finalizing the navigation menus, providing a post-registration page, supporting internationalization and localization, customizing system e-mail messages, tuning site performance, promoting a new site, tracking a site's popularity with analytics, performing module updates safely, backing up Drupal files and database, and duplicating a site.
Drupal 6: Ultimate Community Site Guide is wrapped up with a brief chapter, an author bio, and an unnecessary marketing description of the book. Unlike most programming books, this one is missing an index — although, as an e-book, it can be searched far easier than a print book.
The list price of the book is a very reasonable €7.70, and it is currently available for €5.50. Even though it is registered under the ISBN 978-2839904902, it is currently not available from Amazon.com, because it is an e-book, and the Amazon.com Kindle is not yet available in Europe; this apparently prohibits European publishers from using it. However, the book's website makes it possible to purchase it online. That site also has more details on the book's contents and the author. In addition to the book site, the first three chapters can be previewed online, via its Google Books listing.
Like any technical work, this one has its strengths and weaknesses. Sadly, the book is marred by generally sloppy writing, with a high ratio of errors to pages. There are several errata: "to[o] much" (pages 4 and 79), "others[']" (page 5), "look[s]" (page 16), "fig 3.3" (page 17; should read "Figure 3.1"), "Imagecache_actions Module" (page 52), "eld avatar" (page 66), "other then" (page 69), "others['] contact link" (page 94), "less then" (page 117), "Clustermaps" (page 124), and ."[my]sql file" (page 128). Also, there are many instances of awkward or incorrect phrasing, such as "harmonic" (page 2; should read "in harmony"), "Skippy balls" (page 3; hint: they have nothing to do with peanut butter), "expansive" (page 4; should read "extensible"), "6-versions" (page 9), "and a while" (page 20; should read "in awhile"), "brackets" (page 26; should read "parentheses"), "200% satisfied" (page 34), "Fixfertig" (page 76), "a grip out" (page 83), and "yourbranch" (page 112). Some of these may be European expressions, though Google suggests otherwise. There are missing commas and hyphens, some punctuation marks used incorrectly, and numerous sentences split at the coordinating conjunction into separate (incomplete) sentences. The use of case and spaces in proper names throughout the book are oftentimes incorrect, e.g., "MySql" (page 10 and others), "ftp" (page 10), "cleanURLs" (page 15), "phptemplate" (page 16), "Dhtml" (page 23), "tagadelic" (page 31), "html" (page 98), and "Paypal" (page 113, etc.). Most of the PHP snippets do not have any proper code indentation. Web accessibility proponents will cringe at the table-based positioning. The book's first "chapter" is really an introduction, and should be relabeled as such. The "Acknowledgments" and "Overview" pages have the same page number. Chapter titles are not in title case, but in sentence case. The side notes, used to indicate unstable releases, are rather annoying, because each one of them is positioned so that it looks like a continuation of the narrative line to the left of it. All of these side notes — and perhaps the information in the footnotes as well — should be merged into the narrative. As of this writing, the book's site claims that the book has more than 100 screenshots, but by my count there are 87 of the them. All of these blemishes — none serious — suggest that no technical editing was done prior to publication.
However, the main problem with the book is how, at several points in the narrative, the author assumes too much understanding on the part of the reader, and does not provide enough details for the reader who is trying to implement each suggestion on his own computer and yet has never before worked with the modules in question, or even the key concepts. This problem is seen in entire sections (such as the tagging section mentioned above) and lone sentences (such as the baffling "If you want to change a preset later on, just flush the preset after making the changes..." on page 46).
But none of these weaknesses diminish the overall value of this contribution to the Drupal literature. The book largely achieves its goal of teaching the reader how to create his own Drupal-based community site, using core and contributed modules only, with no custom programming (with the exception of some code snippets stored in the Drupal database). The explanations are, for the most part, clear enough for the reader to step through the process within his own Drupal installation. Some people may fault the book as being too lightweight and lacking the in-depth discussions typical of most Drupal books. But those detractors would be missing the point: This particular title is written for a different target audience, namely, people who wish to build a new website as quickly and easily as possible, and who may not have the knowledge or time to write custom code.
With plenty of detailed instructions, and an upbeat tone throughout the presentation, Drupal 6: Ultimate Community Site Guide can serve as a useful and fast-paced beginning resource for any Drupal developer who wants to create a social media website, requiring minimal time and custom PHP code.
Michael J. Ross is a freelance Web developer and writer.
Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Hmm. The Onion?
Reality Sandwich?
etc.
"brackets" vs "parentheses" is a known difference between American and British English.
Name one truly successful site built with this.
http://drupalib.interoperating.info/node/105
Library, University,& Educational Sites
* Ann Arbor District Library
* Arts & Sciences, Washington University in St. Louis
* Big Ideas @ Berkeley Marketplace
* College of Communication and Information, UTK
* Educause Connect
* Edutopia.org
* Florida State University Libraries
* HavardScience
* Idaho Library Commission's E-Branch in a Box
* Indianapolis Museum of Art
* Michigan State University
o Future Engineers
o Mechanical Engineering
o Office for Inclusion and Intercultural Initiatives
* Oregon State University
o Central Web Services
o Student Health Services
o Women's Studies
* UAA/APU Consortium Library
* University of Alaska Fairbanks: Elmer E. Rasmuson & BioSciences Libraries
* University of Calgary
* University of Saskatchewan Library
Computing and Open Source
* Eclipse Live [IBM]
* Electronic Frontier Foundation
* 43folders
* Linden Lab (creators of Second Life)
* Novell Communities
* Open Office Extensions (Sun)
* Open Source Initiative
* Ubuntu
* Yahoo! Research
Government and Social Activism
* Amnesty International
* The BuzzMonitor
* End Poverty 2015 [United Nations]
* Greenpeace UK
* Global Forum on Migration and Development
* HRH Global Resource Center
* Mississippi Remixed
* New America Foundation
Entertainment
* Discovery Channel [Germany]
* Fox Searchlight
* Lifetime TV
* Mississippi Remixed
* MTV UK
* Sony BMG Musicbox
* The Onion
* Tori Amos
* Warner Bros. Records
If you want to build a website, learn HTML. If you want to build a community website, learn to code. If you don't want to learn, hire somebody who knows how.
Free Martian Whores!
I cannot express to you just how tired I am of these overcomplicated frameworks that require almost as much learning curve as it would to build a custom solution from scratch to suit your needs.
And I cannot express to you just how tired I am of hearing people talk about how you should never use a framework and instead should reinvent the wheel for every project just because they see no use for a particular framework.
Using something like this also creates skill lock-in, where you only know how to do it using this instead of truly understanding the underlying logic.
For someone who just wants a simple and fast website, why exactly do they need to care about the underlying logic? Not everyone cares to tinker with every little thing for every little project and as such these frameworks are very nice to use.
Is it just me or does the name "Drupal" seem kind of limp and flaccid?
nowpublic.com
crooksandliars.com
popsci.com
Aha! I knew it. You couldn't name one site using Drupal.
Well, I was wrong... I am quite surprised that a lot of those sites went that way. I would never use it, ever.
Good for you. What you would or wouldn't use is probably a topic of least concern for most people.
Popsci.com
Earthday.org
American City Business Journals (Sporting News)
BMW, AG
John S. and James L. Knight Foundation
City of Brisbane, Australia
E.W. Scripps & Co.
Spectrum Magazine
Stanford Law School
Coghead
Do Something
BlogHer
frameworks that require almost as much learning curve as it would to build a custom solution from scratch
Getting really good with Drupal = 1-2 months
Building a single site from scratch with the same scope of functionality = 4-5 months
I can programme (in theory ) in fifteen different languages including a couple of assemblers. Twelve are well and truly out of date so which lock in were you referring to - anything complex requires learning and will be out of date after a few years.
Yes, but learning how to use a framework means you aren't as 1337 as people like GigaHurtsMyRobot so you will automatically lose in the e-peen wagging contests. Clearly only stupid people don't reinvent the wheel over and over again when they can just use a preexisting solution that does what they need already.
Using something like this also creates skill lock-in, where you only know how to do it using this instead of truly understanding the underlying logic.
For someone who just wants a simple and fast website, why exactly do they need to care about the underlying logic? Not everyone cares to tinker with every little thing for every little project and as such these frameworks are very nice to use.
Q. F. T.
Also, while I accept that this is a little reductio ad absurdum, one could also say "Learning the C STDLIB creates skill lock-in, write your own libraries." Or yet further, "Using the x86 assembler creates skill lock in, fab your own chips."
I'll also observe real quick, that one of Drupal's strengths, IMO, is how easy it is to manage content and users. Even for very large projects, it is an attractive framework from a more "company" perspective, given that you can hire someone who DOES understand the underlying logic to build modules, theme it, and set it up for X thousand dollars, and then manage it yourself from there. Or, you can put someone on a payroll for XY thousand dollars per annum to design and manage a custom built monster.
It boggles my mind how ON SLASHDOT, something as simple as a (relatively elegant!) PHP API can become "over-complicated" with too steep a learning curve.
That's a reflection on you, more than it's a reflection on the sites that chose it.
I guess it's a matter of applying one of the most important rules of engineering, "use the right tool for the job", properly.
Ready-made frameworks are, to the best of my knowledge, good for small-to-somewhat-biggish-medium deployments (measuring primarily in the terms of hits per a unit of time, the amount of content being somewhat less important, unless it's really huge) with a good safety margin of available CPU time and I/O bandwidth on the server. Very big websites and small-to-medium websites operating in a severely constrained environment (like a cheap shared account, or a single, underpowered dedicated server), on the other hand, require mostly custom coding.
I don't think there's any site the size of YouTube or Facebook using some premade, general-purpose CMS (or whatever you like to call all those Drupal-like things), at least not without some heavy custom optimisations or excessive hadrware expenses (yeah, I know, Wikipedia is, technically speaking, using a premade CMS, but it was designed for a specific huge deployment in the first place).
At the same time, squeezing a popular website onto a cheap hosting platform demands custom coding, too - CMSes, with their modularity and layers upon layers of abstraction (which is surely good from the programmer's and maintainer's point of view) require quite a bit of resources for even such simple tasks as checking the user's session, permissions, profile data etc., which have to be done on every request.
Personally, I'm involved in a project of the latter category, a popular webpage operating from a cheap dedicated machine (single core, 1GB of memory, one logical disk, cheap disk controller with limited I/O bandwidth), and it's a nontrivial task to keep it running smooothly. In a few places it was necessary to do some custom coding at the HTTP server level, use different types of databases to do different things and even utilize specific filesystems for different partitions that hold data of different nature (lots of small, fast-changing files on one, some big, mostly appended to files on another, etc). The scripting itself, too, was written with performance in mind, sometimes even breaking design patterns (with due care and big fat warnings in the comments, of course). Not long ago, I measured the performance of this contraption and while there's still room for improvements (mostly around database schemas and smart caching), it was able to outperform Plone, Joomla and a few [...]-Nukes tested under a similar workload pretty easily. Sure, it *was* a lot of work to do, but still probably less than modifying an existing CMS for such a level of specialization. (Oh, and before someone asks - no, I'm not giving the URL, I'm quite proud of my code, but I'm also sure it's not *that* fast yet.)
This is Slashdot. Common sense is futile. You will be modded down.
It is pronounced:
Drooo pall
Droo puhl <- my money's on this one.
Drup - uhl
Drup - Al
Help me out, Slashdot.
Yes, CMSes are not the right fit for every job and that was never my intent to imply. But my issue is that you constantly get people trolling threads about Drupal, Django, etc etc always decrying that no one should be using these frameworks because they think it's improper and that everyone should be writing custom code for every situation even if that is total overkill and unnecessary.
Also, linuxjournal.com
I don't care why you're posting AC
almost as much learning curve as it would to build a custom solution from scratch to suit your needs
Man, have I got a snappy retort for you, mister. Hold on while I write my own version of the slashcode and put up a new web site so you can see what I have to say. Or, I can send you a fax. I'll need your street address so I can string up some copper wire to your house.
Don't disappoint your bird dog. Go to the range.
I find your ideas intriguing and wish to subscribe to your newsletter ..
(Unless, of course, that newsletters are bad?)
Hold on while I write my own version of the slashcode and put up a new web site so you can see what I have to say.
Or, I can send you a fax.
I'm sorry, but learning to use html or a fax machine "creates skill lock-in" so you will have to invent your own protocols for sending electronic messages if you want to live up to Giga's standard.
I recently purchased "Using Drupal" when it became apparent to me that my company's intranet needed to be reworked from the ground up.
The book is fine for what it is, but once I got past the hyp & theory and proceeded into the step-by-step, I began to realize how horribly limiting linear text is for this kind of instruction. When many steps are involved, and there is a lot of explanation involved as to why each step is important, it becomes difficult to keep one's place. The strange loop epistemological dance between "I have to tell you why for you to understand" and "you have to understand for me to tell you why" never really resolves. I think that's true for any "How To" manual.
Finding video tutorials online made a world of difference, especially when it came to figuring out the logic behind constructing views. Sometimes I just wanted to *see* how to do a thing. I knew enough to know I'd get it when I saw it happen.
Static text and explanations can't always bridge the gap. Books tell, videos show, and that's a key point to having a breakthrough.
I guess it's a matter of applying one of the most important rules of engineering, "use the right tool for the job", properly.
. . .
Personally, I'm involved in a project of the latter category, a popular webpage operating from a cheap dedicated machine (single core, 1GB of memory, one logical disk, cheap disk controller with limited I/O bandwidth), and it's a nontrivial task to keep it running smooothly.
. . .
Common sense is futile.
I'm not sure what exactly were you trying to say, but I'm afraid that common sense is, indeed, futile when confronted with severely limited money to spend on hosting.
This is Slashdot. Common sense is futile. You will be modded down.
I'm involved in a project of the latter category, a popular webpage operating from a cheap dedicated machine (single core, 1GB of memory, one logical disk, cheap disk controller with limited I/O bandwidth), and it's a nontrivial task to keep it running smooothly. In a few places it was necessary to do some custom coding at the HTTP server level, use different types of databases to do different things and even utilize specific filesystems for different partitions that hold data of different nature (lots of small, fast-changing files on one, some big, mostly appended to files on another, etc). .... Sure, it *was* a lot of work to do, but still probably less than modifying an existing CMS for such a level of specialization
No offense, but that sounds like false economy; i.e. it would be cheaper to buy a better server than to pay for lots of custom programming, and if you're restricted to that hardware, it sounds like money is an issue. Later on, a popular standardized CMS is likely to get security updates and expanded features, while your client's solution will need further expensive custom programming.
Unless you're a volunteer, of course.
Damn those pesky terrorists
... is that you can use it until you realize that you should be using Django.
More seriously, I do like Drupal and I can see the point of its modular design. However, I must confess that for more complicated projects I found it easier to use Django.
I would advice any person planning to build a website with more-than-just-a-blog capabilities to seriously consider Django first. If Django doesn't cut it for any reason, then Drupal is the way to go.
If your site is meant to be complex in a non-standard way, you should fully understand the complexity.
Aeroespacio.org
I think Drupal can be very useful, depending on the application. I am using it to build a pilot for A Water Quality knowledge and Information Network, as part as my Ph.D dissertation. For a Pilot, it works well. If the network grows and take off, than I guess we will have to reevaluate.
But these kind of tools are great for Pilot projects an I imagine that for simple applications there is no need to build anything from scratch.
In this case the "client" is actually me and a few friends (and the users, sort of). We're putting so much time and effort into it in part for the experience we get, and that really pays - one of us got a very good job recently, just because he learned to write efficent, maintainable code and use and combine different technologies when appropriate, rather than sticking to one thing no matter what.
Besides, the pricing on dedicated servers is all screwed up, as is the usual selection of hardware configurations. And don't even get me started on the fact that colocating our own box costs more than leasing the same - in terms of rack space, power draw and cooling - thing.
Oh, and many popular CMSes were a security nightmare until recently. Now it's mostly OK, but five years ago, when we started, most PHP frameworks and CMSes were crappy, Python-based hosting was still rare and expensive and we did not have our own server yet.
This is Slashdot. Common sense is futile. You will be modded down.
Druppel in Dutch sounds almost exactly like Drupal.
Given that the project lead speaks Dutch, I always suspected that it has something to do with "a drop" (lit.)
The logo is a single drop of fluid so that tells me I'm probably not that far off.
News about the Kettle Open Source project: on my blog
Nothing about setting up a wiki in Drupal... The review doesn't bring it up, and as far as I can tell from the online table of contents, the book doesn't either. That was sort of surprising, for a book about community sites.
-Karl Fogel
http://www.red-bean.com/kfogel
Or, for someone who wants to leverage their time against the work of some 100,000 developers, who have, though not always perfectly, solved most use cases with contributed feature modules.
Also, www.mtv.co.uk launched in Drupal two years ago (don't know if it's still running it now), and President Obama's team used Drupal to build and run his campaign site until about a month after the DNC primaries concluded (and he had the money to build a fully-custom solution). And the New York Observer runs Drupal.
Simply that from certain perspectives, you aren't following your own advice. But I see that this is the "right" solution for you.
For others, an off-the-shelf framework is the "right" solution, often because the time it would take to develop your skill set does not represent a good value to them. Skill lock-in gets you one way or another. Time spent developing the skills to custom code and maintain your own site is time most people would rather spend doing/learning something else.
There have been a few times now that I've gotten stuck using a massive PHP project that someone else has installed (because it's so easy!) and I immediately feel the pressure on me to start learning how it all works, because otherwise it will never work right.
On a particular site using Drupal I've seen multiple bugs involving date and time handling (e.g. a scheduling calendar that reports bogus conflicts, and announcements calendar that on every edit forgets the times you previously entered), etc); but much worse than that it completely lacks any integration of the various little modules it was stuck together with -- e.g. once an event plan has been finalized, we would like to be able to publish it from our scheduling calendar to our announcements calendar, but instead you need to manually re-enter the information.
Well, at any moment I could get a piece of paper and a pencil, and design a deployment plan for my project that would use the right tool for the job on every level, hardware, software and all - but it would stay there, on paper, simply because of the initial cost.
In fact, I wouldn't agree on not following my own advice - I call it a rule of engineering, and engineering deals with real-world problems with real-world constraints. In this case, the constraint is financial, so I get to choose the right tool from what I can afford. This, unavoidably and regrettably, means that the right tool is an underpowered server combined with sufficiently optimized software - after all, it works properly. Consequently, the same underpowered server running slow software not optimized for the specific task would be an example of a bad tool for the job.
As for the skills and time required to develop them, take a look at my other reply in this thread - I'm not doing that just for fun. It turns out that the skillset required in my situation is quite similar to the one necessary at the other end of the spectrum, where the scale of a deployment is so big that off-the-shelf technology doesn't cut it and custom solutions must be carefully developed for a specific task. Even some of the specific techniques employed in the process are almost the same - especially using different databases, filesystems, programming languages etc. in unison, to get the most out of every piece.
This is Slashdot. Common sense is futile. You will be modded down.
Hold on while I write my own version of the slashcode and put up a new web site so you can see what I have to say.
Really, I posted a journal entry last week named Slashcode is dead, long live Slashcode?... read the "numerous" replies on the Slashcode-general sourceforge mailing list... I fear Slashcode might be really dead after all, and Drupal might come to save the day?!
Animoog.org
Agreed very much.
Frameworks aren't limited to the "simple and fast" user type either. Even when I'm developing an application from scratch that would not fit with Drupal's CMS, I will usually rip out one or more of Drupal's basic components (my favorites are the HTTP client and Form API) as they work exceedingly well on their own, making my own code leaner and higher-level. Admittedly, this only works if you have intricate knowledge of how each of these components operate, but it is still far easier than rewriting them.
A major complaint against frameworks is that they make programming too easy or "bloated" - as if a wheel invented in a few nights by an overcaffeinated code-cowboy is going to run remotely as smooth as one developed by a community over years of design discussion and real-world testing. I'm wondering if there is a school of thought (whose adherents are best known as "Real Programmers") that holds that self-torture can compensate for a lack of skill.
You are close. "Druppel" does mean "drop" in Dutch. But the original developer came across the name "drop" by mistake. He was trying to name his first site www.dorp.org. It was an online community site, and "dorp" is Dutch for "village", so dorp was an appropriate name. But he made a typo in his domain registration and registered drop.org by mistake. The site became popular and the name "drop" stuck. Later he changed it to Drupal, which is derived from "druppel" -- the Dutch word for "drop". cite
I was very intrigued at using Drupal for an upcoming site of mine. So I went to the wikipedia page for it, and I stopped when I read these three letters. PHP.
No thank you. PHP is horrible to code in, and is inferior to other technologies out there.
OK, well:
1. volunteer work or paid in fame and respect
2. legacy code
3. intimacy with the work and ongoing staff continuity
Result: you should be doing what you're doing.
If you were:
1. doing a new site
2. being fully paid
3. needing something close to what a standard CMS offers, and
4. on a restricted budget
then you would have to research CMS offerings carefully before going with a from-scratch system.
Damn those pesky terrorists