Slashdot Mirror
Drupal Multimedia
Michael J. Ross writes "Of the leading content management systems used by developers for creating websites, Drupal is highly regarded for many characteristics, including a much smaller initial footprint, compared to Joomla and other CMSs. Yet some developers find this a disadvantage as well, because one of the most common criticisms leveled against Drupal is its lack of built-in support for images and multimedia elements — thereby forcing new Drupal developers to choose from the thousands of contributed Drupal modules those that would be optimal for implementing their websites' multimedia functionality. Aaron Winborn's book Drupal Multimedia is intended as a guide to help such developers." Keep reading for the rest of Michael's review.
Drupal Multimedia
author
Aaron Winborn
pages
264
publisher
Packt Publishing
rating
7/10
reviewer
Michael J. Ross
ISBN
978-1-847194-60-2
summary
A guidebook for adding images, videos, and audio content to Drupal sites
The book was put out by Packt Publishing on 30 October 2008, under the ISBN 978-1-847194-60-2. On the publisher's book page, visitors can learn more details about the book and its author, purchase the electronic or print editions of the book (or both, at a discount), download the sample source code, send feedback or questions to the publisher, read the book's table of contents, or download a sample chapter for free ("Third Party Video") in PDF format. As with all other Packt Publishing titles, the errata is annoyingly not available directly from the book page; instead the visitor must go to the general Packt Publishing support page, find the title in a lengthy drop-down list box, click a button, and finally click another link (the one that should have been on the book page from the start) — only to have the errata displayed in a pop-up window. Among all the technical book publishers, Packt's procedure for accessing errata is surely the most tedious, and one can only hope it will be improved in the future. As of this writing, only one erratum has been reported. It is listed as being on "page 0," but that instead should read "page 34" (an erratum in an erratum!). Speaking of online resources, one would expect the author's own site to have further information on the book, but there does not appear to be any there.
Drupal Multimedia is a fairly slender volume, at 264 pages, no doubt because it focuses on a limited subject area — implementing multimedia with some key contributed modules — as opposed to most of the recent spate of Drupal books, some of which try to cover every major aspect of the CMS. The material in Aaron Winborn's book is organized into eleven chapters, addressing most if not all of the key topics within the chosen subject area: Drupal basics; images, galleries, and slideshows; image theming and effects; third-party and local video; file management; audio nodes and fields; theming audio; and the future of multimedia in Drupal. The book concludes with a skimpy five-page index, which fails to contain such basic entries as Flash, FLV, SWF, sprites, star ratings, slideshows, and countless others. A robust index is especially critical for any technical book, such as this one, that divides related topics among multiple chapters, and has section and subsection names that in some cases are quite similar to one another and thus could be easily confused.
Because this book is geared more toward programmers new to Drupal, and not well-versed veterans, the first chapter — the second longest in the book — introduces the reader to the core concepts of Drupal (nodes, regions, blocks, themes, and modules — core and contributed) as well as two essential modules (CCK and Views). The explanations do not go into any great detail, but should be enough to give any Drupal newbie a head start. Nonetheless, readers may be confused by the screenshots on pages 16 through 19, which appear to be from Drupal 5. Also, the brief coverage of views arguments is inadequate, and needs to be beefed to be useful later in the book. For creating a new theme, the author advises copying wholesale an existing theme; instead, a sub-theme is a much better approach. Chapter 1 wraps up with a discussion of some basic concepts in Drupal theming, which makes puzzling the title of the section, "Advanced Theming." Speaking of themes, readers should note that when the author refers to "theming" an image or video, he means making the uploaded file display as content on the node's page (and not just exist as an attachment to that node).
For many programmers new to Drupal, the first hurdle they encounter is how to add an image to the content of a page or story — a seemingly trivial task that is built into most major CMSs — without writing HTML and hard coding the path of an image file they FTP-ed to the server. Drupal version 6 and presumably all prior versions, do not have native support for uploading and embedding in-line images. In his second chapter, the author explains how one can create image galleries, teaser thumbnails, and images embedded in content. However, in the discussion on page 45, some details are incorrect, such as the label for the "Save" button (three times) and the presence of the galleries drop-down list. Readers will undoubtedly be confused by two additional inaccuracies: There is no Navigation menu item for displaying the "image galleries" created by default, because initially the image_gallery view has no menu assigned in the Gallery page settings. Secondly, the gallery description is not shown on the gallery page; in fact, it is not even listed as an available view field. The section titled "Image Gallery Settings" suggests that the author may have been using an older version of the Image module. But this probably does not explain the erroneous statement on page 56, that "image nodes created with Image attach will automatically be marked as not published." The chapter concludes with an explanation of how to embed an image in content, using manually inserted image tags, or the ImageAssist module, optionally supplemented with a WYSIWYG HTML editor, such as TinyMCE. The fourth chapter looks at how to theme images, and discusses — it greatly varying levels of detail — style overriding, the Firebug Firefox extension, the Theme Developer module, image nodes, image-based rollover menus, sprites, light boxes, star ratings, slideshows, and various special effects: drop shadows, magnification, and watermarks.
The subsequent chapter — oddly titled "Developing for Images" — extends the discussion by showing how to insert images as fields utilizing ImageField and several supporting modules. One of those modules is referred to as "FileField Tokens" (page 70), but there is no such module; the author probably meant ImageField Tokens. Also extending the previously noted problem of non-Drupal 6 content, is the screenshot for "Display fields," on page 83, as well as the narrative, which appear to be pre-version 6. The latter half of the chapter delves into how to create galleries and slideshows (using views), user pictures, and images associated with taxonomy terms.
With Chapters 5 and 6, the author shifts attention to what is perhaps the second most commonly used type of multimedia on websites nowadays — video — with the former of those chapters devoted to third-party videos (such as content hosted on YouTube), while the latter chapter is devoted to "local video" (local in the sense of hosted on one's own remote Web server — not one's local development machine). The author demonstrates how to utilize a YouTube-hosted video, first using core Drupal modules only, then using the Embedded Video Field module. For using local video files, the author shows how to use the FileField module so the user can upload QuickTime video files. Unfortunately, the instructions on page 146 may prove confusing to beginners, since it is not entirely clear as to whether the later, more-detailed paragraphs are repeating earlier instructions, or specifying something new. More significantly, the use of the FileField module necessitates writing theme PHP code, just to have the video display on the page — which less technical readers may not feel comfortable attempting on their sites. The second part of the chapter may be more useful to the typical reader, because it covers how to embed Flash videos, a more popular format. The author advocates the use of the jQuery Media module (which he created) in conjunction with the jQ module. Unfortunately for the reader, the details of implementing this approach are glossed over at the end of the chapter, with only meager instructions ("... add .node .content a to the classes."), and without any illustrative example. No explanation is provided as to why this particular JavaScript-dependent solution is recommended, as opposed to a more straightforward one, such as the Flash Node module — which is far less problematic for FLV files. (By the way, the author states that he and some other developers are creating a fully GPL media player module and that there is a development version available of this Media Player module. But there is no such version on that page, and the situation may never change, because the project appears to have fizzled in August 2008, judging by the comments on the Drupal.org site and the author's site.)
In written tutorials, videocasts, and other discussions of Drupal multimedia, one important area that is often neglected is asset management. This includes such seemingly mundane matters as where in a Drupal site's file system one should place plug-in files and even the uploaded multimedia files themselves. A more far-reaching topic is how to best associate multimedia assets with nodes so they can be accessed by various modules — for instance, as stand-alone content types versus CCK fields. Chapter 7 examines some of these topics, first discussing how to create and theme nodes whose associated videos can be used elsewhere on a site, such as in a gallery — using the Embedded Media Field and Node Reference modules. However, some readers may become frustrated because a couple critical steps are skipped, and, even worse, no guidance is provided as to how to make the video show up on a node reference content page, or what content provider selection to use (since "Local" is not an option). Next the author considers how to set access to videos by user role — using the Asset module. Unfortunately, the reader is apparently not shown how to do anything useful with video content uploaded and managed using the Asset module, including the scenario proposed at the beginning of the section. (Incidentally, one might assume that the author's solution would use the Asset Embedded Media submodule, but it is not compatible with the latest version of Drupal 6.) The Media Mover module, and its many submodules, offer an alternate method of video asset management, and the author shows how to e-mail a video from a mobile phone, to be automatically attached to a new blog post. The chapter concludes with a brief look at Kaltura, an open-source platform for storing and editing multimedia.
Some Web developers and end-users may consider online audio as the poor cousin of video. In truth, audio-only content plays a key role in many Web applications — from podcasts embedded in RSS feeds, to sample tracks on music sellers' websites. The subsequent three chapters of the book are devoted to managing audio content within Drupal using several resources and solutions — specifically, the Audio, getID3, FileField, jQuery Media, Embedded Media Field, XSPF Playlist, and Views modules
In the last chapter, titled "The Future of Drupal Multimedia," the author speculates as to what media-related capabilities he thinks we will likely find in Drupal 7 and beyond — such as native file handling (via hook_file) and multimedia support in core Drupal, the merging or deprecation of non-FileField modules, dissociation of data from nodes, improved module interfaces and usability, embeddable widgets (for data distribution), semantic multimedia (microformats, RDF, and taxonomy-powered tagging), mobile Web access, virtual reality (such as Second Life), tactile and olfactory media, and motion sensing (such as the Wii Remote controller).
One laudable feature of this book is the inclusion of numerous screenshots, which can be quite reassuring to a reader getting lost in the technical minutia of any particular recipe. Also helpful is the manner in which the author, for the most part, keeps the reader informed as to all configuration settings — and where to find them within the Drupal administration interface — that the reader must or may want to modify, depending on his or her needs. Technical books that fail to do this can be extremely frustrating to anyone trying to learn a nontrivial technology.
Yet there are some major flaws with the book: Far too much of the material suggests that the author was using Drupal 5. Aside from the screenshots mentioned earlier, sections of the text point in that direction, such as the statement, "The multiple image issue might be taken care of by Drupal 6" (page 56). Fortunately, none of these gaffes prevent the reader from learning how to perform the tasks using version 6. The second and more important flaw is the poor coverage of Flash content, as detailed above. A follow-up edition to the book, in which all of these problems are resolved, would be most welcome and valuable.
A revision would also be an opportunity to fix the grammatical errors that should have been caught in the proofreading process. For instance, the fourth complete sentence on page 11, is missing a verb. Errata include "Autrhor" (credits page), "you [have] learned" (page 2), ". you'll" (page 2), a ")" without a "(" to match it (page 17), "isin" (page 31), "it [is] installed" (page 32), "provide files" (page 33; should instead read "provide functions"), "hierarchal" (page 46), "formated" (page 57), "[the] FTP" (page 75), "menu — By" (page 117), "going a view" (page 119), "quicktime" (page 146), and "[Submit] Audio" (page 179). In addition, there are eight pairs of adjacent words missing their separating spaces — five on page 159, and three more on page 174.
As seen in many other Packt Publishing titles, this one contains excessive usage of inappropriate title case (e.g., several on page 8 and 9 alone), though occasionally title case is neglected (e.g., "Image attach" throughout the book). In addition, some of the phrasing is rather awkward, which may pose no barrier to a reader who already understands the particular idea being discussed in the text, but could prove a real detriment to anyone unfamiliar with that idea. For instance, on page 36, the author states that "Often you may wish to override a theme that is not provided as a file in the default theme." But no theme is contained within a single file, and one does not override themes anyway; rather, one can disable a theme, or modify a copy of it, or create a variation as a sub-theme.
Yet overall, this book's strengths outweigh its weaknesses. For Drupal developers who wish to add image, audio, and video content to their sites, Drupal Multimedia is a useful resource with which to begin.
Michael J. Ross is a freelance Web developer and writer.
You can purchase Drupal Multimedia from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Drupal Multimedia is a fairly slender volume, at 264 pages, no doubt because it focuses on a limited subject area — implementing multimedia with some key contributed modules — as opposed to most of the recent spate of Drupal books, some of which try to cover every major aspect of the CMS. The material in Aaron Winborn's book is organized into eleven chapters, addressing most if not all of the key topics within the chosen subject area: Drupal basics; images, galleries, and slideshows; image theming and effects; third-party and local video; file management; audio nodes and fields; theming audio; and the future of multimedia in Drupal. The book concludes with a skimpy five-page index, which fails to contain such basic entries as Flash, FLV, SWF, sprites, star ratings, slideshows, and countless others. A robust index is especially critical for any technical book, such as this one, that divides related topics among multiple chapters, and has section and subsection names that in some cases are quite similar to one another and thus could be easily confused.
Because this book is geared more toward programmers new to Drupal, and not well-versed veterans, the first chapter — the second longest in the book — introduces the reader to the core concepts of Drupal (nodes, regions, blocks, themes, and modules — core and contributed) as well as two essential modules (CCK and Views). The explanations do not go into any great detail, but should be enough to give any Drupal newbie a head start. Nonetheless, readers may be confused by the screenshots on pages 16 through 19, which appear to be from Drupal 5. Also, the brief coverage of views arguments is inadequate, and needs to be beefed to be useful later in the book. For creating a new theme, the author advises copying wholesale an existing theme; instead, a sub-theme is a much better approach. Chapter 1 wraps up with a discussion of some basic concepts in Drupal theming, which makes puzzling the title of the section, "Advanced Theming." Speaking of themes, readers should note that when the author refers to "theming" an image or video, he means making the uploaded file display as content on the node's page (and not just exist as an attachment to that node).
For many programmers new to Drupal, the first hurdle they encounter is how to add an image to the content of a page or story — a seemingly trivial task that is built into most major CMSs — without writing HTML and hard coding the path of an image file they FTP-ed to the server. Drupal version 6 and presumably all prior versions, do not have native support for uploading and embedding in-line images. In his second chapter, the author explains how one can create image galleries, teaser thumbnails, and images embedded in content. However, in the discussion on page 45, some details are incorrect, such as the label for the "Save" button (three times) and the presence of the galleries drop-down list. Readers will undoubtedly be confused by two additional inaccuracies: There is no Navigation menu item for displaying the "image galleries" created by default, because initially the image_gallery view has no menu assigned in the Gallery page settings. Secondly, the gallery description is not shown on the gallery page; in fact, it is not even listed as an available view field. The section titled "Image Gallery Settings" suggests that the author may have been using an older version of the Image module. But this probably does not explain the erroneous statement on page 56, that "image nodes created with Image attach will automatically be marked as not published." The chapter concludes with an explanation of how to embed an image in content, using manually inserted image tags, or the ImageAssist module, optionally supplemented with a WYSIWYG HTML editor, such as TinyMCE. The fourth chapter looks at how to theme images, and discusses — it greatly varying levels of detail — style overriding, the Firebug Firefox extension, the Theme Developer module, image nodes, image-based rollover menus, sprites, light boxes, star ratings, slideshows, and various special effects: drop shadows, magnification, and watermarks.
The subsequent chapter — oddly titled "Developing for Images" — extends the discussion by showing how to insert images as fields utilizing ImageField and several supporting modules. One of those modules is referred to as "FileField Tokens" (page 70), but there is no such module; the author probably meant ImageField Tokens. Also extending the previously noted problem of non-Drupal 6 content, is the screenshot for "Display fields," on page 83, as well as the narrative, which appear to be pre-version 6. The latter half of the chapter delves into how to create galleries and slideshows (using views), user pictures, and images associated with taxonomy terms.
With Chapters 5 and 6, the author shifts attention to what is perhaps the second most commonly used type of multimedia on websites nowadays — video — with the former of those chapters devoted to third-party videos (such as content hosted on YouTube), while the latter chapter is devoted to "local video" (local in the sense of hosted on one's own remote Web server — not one's local development machine). The author demonstrates how to utilize a YouTube-hosted video, first using core Drupal modules only, then using the Embedded Video Field module. For using local video files, the author shows how to use the FileField module so the user can upload QuickTime video files. Unfortunately, the instructions on page 146 may prove confusing to beginners, since it is not entirely clear as to whether the later, more-detailed paragraphs are repeating earlier instructions, or specifying something new. More significantly, the use of the FileField module necessitates writing theme PHP code, just to have the video display on the page — which less technical readers may not feel comfortable attempting on their sites. The second part of the chapter may be more useful to the typical reader, because it covers how to embed Flash videos, a more popular format. The author advocates the use of the jQuery Media module (which he created) in conjunction with the jQ module. Unfortunately for the reader, the details of implementing this approach are glossed over at the end of the chapter, with only meager instructions ("... add .node .content a to the classes."), and without any illustrative example. No explanation is provided as to why this particular JavaScript-dependent solution is recommended, as opposed to a more straightforward one, such as the Flash Node module — which is far less problematic for FLV files. (By the way, the author states that he and some other developers are creating a fully GPL media player module and that there is a development version available of this Media Player module. But there is no such version on that page, and the situation may never change, because the project appears to have fizzled in August 2008, judging by the comments on the Drupal.org site and the author's site.)
In written tutorials, videocasts, and other discussions of Drupal multimedia, one important area that is often neglected is asset management. This includes such seemingly mundane matters as where in a Drupal site's file system one should place plug-in files and even the uploaded multimedia files themselves. A more far-reaching topic is how to best associate multimedia assets with nodes so they can be accessed by various modules — for instance, as stand-alone content types versus CCK fields. Chapter 7 examines some of these topics, first discussing how to create and theme nodes whose associated videos can be used elsewhere on a site, such as in a gallery — using the Embedded Media Field and Node Reference modules. However, some readers may become frustrated because a couple critical steps are skipped, and, even worse, no guidance is provided as to how to make the video show up on a node reference content page, or what content provider selection to use (since "Local" is not an option). Next the author considers how to set access to videos by user role — using the Asset module. Unfortunately, the reader is apparently not shown how to do anything useful with video content uploaded and managed using the Asset module, including the scenario proposed at the beginning of the section. (Incidentally, one might assume that the author's solution would use the Asset Embedded Media submodule, but it is not compatible with the latest version of Drupal 6.) The Media Mover module, and its many submodules, offer an alternate method of video asset management, and the author shows how to e-mail a video from a mobile phone, to be automatically attached to a new blog post. The chapter concludes with a brief look at Kaltura, an open-source platform for storing and editing multimedia.
Some Web developers and end-users may consider online audio as the poor cousin of video. In truth, audio-only content plays a key role in many Web applications — from podcasts embedded in RSS feeds, to sample tracks on music sellers' websites. The subsequent three chapters of the book are devoted to managing audio content within Drupal using several resources and solutions — specifically, the Audio, getID3, FileField, jQuery Media, Embedded Media Field, XSPF Playlist, and Views modules
In the last chapter, titled "The Future of Drupal Multimedia," the author speculates as to what media-related capabilities he thinks we will likely find in Drupal 7 and beyond — such as native file handling (via hook_file) and multimedia support in core Drupal, the merging or deprecation of non-FileField modules, dissociation of data from nodes, improved module interfaces and usability, embeddable widgets (for data distribution), semantic multimedia (microformats, RDF, and taxonomy-powered tagging), mobile Web access, virtual reality (such as Second Life), tactile and olfactory media, and motion sensing (such as the Wii Remote controller).
One laudable feature of this book is the inclusion of numerous screenshots, which can be quite reassuring to a reader getting lost in the technical minutia of any particular recipe. Also helpful is the manner in which the author, for the most part, keeps the reader informed as to all configuration settings — and where to find them within the Drupal administration interface — that the reader must or may want to modify, depending on his or her needs. Technical books that fail to do this can be extremely frustrating to anyone trying to learn a nontrivial technology.
Yet there are some major flaws with the book: Far too much of the material suggests that the author was using Drupal 5. Aside from the screenshots mentioned earlier, sections of the text point in that direction, such as the statement, "The multiple image issue might be taken care of by Drupal 6" (page 56). Fortunately, none of these gaffes prevent the reader from learning how to perform the tasks using version 6. The second and more important flaw is the poor coverage of Flash content, as detailed above. A follow-up edition to the book, in which all of these problems are resolved, would be most welcome and valuable.
A revision would also be an opportunity to fix the grammatical errors that should have been caught in the proofreading process. For instance, the fourth complete sentence on page 11, is missing a verb. Errata include "Autrhor" (credits page), "you [have] learned" (page 2), ". you'll" (page 2), a ")" without a "(" to match it (page 17), "isin" (page 31), "it [is] installed" (page 32), "provide files" (page 33; should instead read "provide functions"), "hierarchal" (page 46), "formated" (page 57), "[the] FTP" (page 75), "menu — By" (page 117), "going a view" (page 119), "quicktime" (page 146), and "[Submit] Audio" (page 179). In addition, there are eight pairs of adjacent words missing their separating spaces — five on page 159, and three more on page 174.
As seen in many other Packt Publishing titles, this one contains excessive usage of inappropriate title case (e.g., several on page 8 and 9 alone), though occasionally title case is neglected (e.g., "Image attach" throughout the book). In addition, some of the phrasing is rather awkward, which may pose no barrier to a reader who already understands the particular idea being discussed in the text, but could prove a real detriment to anyone unfamiliar with that idea. For instance, on page 36, the author states that "Often you may wish to override a theme that is not provided as a file in the default theme." But no theme is contained within a single file, and one does not override themes anyway; rather, one can disable a theme, or modify a copy of it, or create a variation as a sub-theme.
Yet overall, this book's strengths outweigh its weaknesses. For Drupal developers who wish to add image, audio, and video content to their sites, Drupal Multimedia is a useful resource with which to begin.
Michael J. Ross is a freelance Web developer and writer.
You can purchase Drupal Multimedia from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Drupal sucks balls. It's very counterintuitive for something that claims to be simple and modular. Behaviors are inconsistent across themes, half of the available themes are broken, TFS is right about Drupal not supporting jack shit right off the bat. Enabling the modules requires manual downloads and dependency hells. The notion of using the site as you build it is shit, and using an "admin theme" just causes trouble because of the inconsistent behaviors across themes. Even its own advocates recommend just writing your own PHP and CSS.
Can somebody please develop a CMS for people without Asperger's ?!
I've been working with Drupal for a couple years now. Even experienced PHP developers will find themselves in a learning curve in using Drupal's administrative "backend" and third party modules.
An experienced PHP developer also realizes the value and importance of online documentation... php.net is a resource I still constantly refer to when certain decisions need to get made...
Whenever I see a Drupal-related book, I immediately compare it to drupal.org, the advanced help module and the information a simple google search can produce.
A developer's time learning fundamental Drupal concepts would be better served through diving into the Drupal community... not reading a book... That way they're prepared to find resources for all the various issues that come up with Drupal Development... not just adding multimedia.
A would like to see a book written from the perspective of a Web programmer evaluating Drupal as a development (MVC) framework weighed against the likes of cakePHP, Zend, codeigniter, et al.
Its been a topic of debate lately and a book would be a good medium to thoroughly evaluate such an idea.
A book like that would help the Drupal Community... I feel like the book you described hurts it.
What do they have in common?
Changing the theme changes basic functionality of the site. It's logic-in-template. Despite the lip service paid to this most essential separation of concerns, it's still considered a legitimate way to add features. Welcome back to the 90's.
Drupal is for scrubs
Because its commercial competitor (Sharepoint) doesn't require any do it yourself code/hacks...
I'm starting to think GNU is the problem with "GNU/Linux" these days.
Do yourself a favor and don't bother with Drupal. It's a huge piece of shit.
We just tried to use it for an intranet site, and it fell flat on its face. We threw better hardware at it, and that didn't help. We tried Lighttpd instead of Apache, and it was still fucked. We tried Linux, FreeBSD, and Solaris. We tried several PHP bytecode caches. We tries PostgreSQL instead of MySQL, although it's not really "officially" supported, and that did help somewhat. Other than that, nothing helped.
Our developers did notice that it makes a fucking stupid number of SQL queries per page load, though. That was just for the basic CMS, too. One plugin we tried using was particularly bad. It made over 730 SQL queries per page load. Needless to say, we stopped using that plugin.
Our CIO ended up getting fed up with PHP and open source software failing us, so he went behind our backs and bought a proprietary ASP.NET-based CMS. We were all against it at first, but unlike Drupal, it actually works. Now we have egg all over our faces for trying to get our company to adopt open source software.
I have prefer to use Drupal when developing sites for clients who's requirements align with what a CMS can provide. I recently received a contract to build a website with an intuitive slick image gallery, and I decided to explore Drupals image capabilities more than I had before. I have used the Gallery module before and found it suitable for for home photos, but I have not found an image gallery that would be useful for displaying images/slideshows (such as lightbox2) for a business-oriented website, and that the average user would find it intuitive to manage themselves. I have been attempting to modify the image_gallery module in order to make it as straight forward as possible, but it is still confusing to me. I'm curious as to what other drupal developers use, or if there is just a lack of drupal modules and features that make images easy to use.
...for people who secretly want to do everything from scratch anyway.
I'm sorry, but if it takes a 264 page book to teach someone how to implement media in a CMS, then something is wrong with the system.
Either that or this is one wordy author.......
I would argue that it only requires hacks if you wish to make it unique, or do something not provided by available modules. I've worked with Drupal for over 3 years and it rarely requires "hacks" once you know your way around. Sharepoint on the other hand is a proprietary and commercial rabbit hole that will cost you some serious bucks once you need to customize it.
...who works with it every day. Then, it's brilliant.
I spent 4 hours banging my head against a wall trying to do two things: 1)get a calendar of events up (in any way, shape, or form) and 2)put some boxes on the front page of a site, one for each major category of the blog. So, to transpose the example to slashdot: a box containing just "idle" story headlines.
The calendar bit, I gave up on because it involved creating all sorts of custom data types and forms and views and...jesus christ, why couldn't they just make an "events" module...
The box-with-a-category, I also gave up on. Apparently, the "solution" is to dig into PHP in your theme (why themes are chock full of code is beyond me) and edit the files. Well, except that then when a new version of the theme comes out, you have to port your changes forward. So instead, you make a copy of the file, install it into a duplicate of the theme's folder structure, tell Drupal your theme is a subtheme of another existing theme, and Drupal makes Magic Happen.
Sort of. The subtheme doesn't inherit critical stuff in the original theme, like the stuff that defines where content boxes can go on the page (ie, the most basic part of the theme: the layout!) so when you load the new theme, all your content completely disappears. Unfuckingbelievable.
In the end I threw up my hands in disgust. I could see the possibilities for a community site (which is what I needed and wanted in the long run), but getting there would have been an endless amount of time learning Drupal internals. Why the fuck should I have to learn internals to put an event calendar on my blog's sidebar?
Oh, and everyone makes out that modules are the second coming of Christ, especially this book, apparently. Well, as we discovered at work trying to implement a drupal site that sometimes when you enable a module, it runs all over your database, permanently screwing the pooch and requiring a complete restore from backup...a problem exacerbated by the lack of (apparently) refined APIs. What does that mean? Well, it means the modules and Drupal very often end up having very specific version requirements...
Please help metamoderate.
Just say no - if Steph the Geek is into it, its almost by definition faddish and lame.
I want to delete my account but Slashdot doesn't allow it.
Can somebody please develop a CMS for people without Asperger's ?!
It's for consultants, not people with Asperger's. Everything requires coding and customization and is awkward. It's a consultant's wet dream.
Please help metamoderate.
Has anyone used/liked/hated DjangoCMS?
Is it any worse than similar CMS's?
There are tons of modules for it, so more than just a couple people 'get it.'
http://www.maxineudall.com/2010/02/should-economists-be-sued-for-malpractice.html
I would argue that it only requires hacks if you wish to make it unique, or do something not provided by available modules. I've worked with Drupal for over 3 years and it rarely requires "hacks" once you know your way around. Sharepoint on the other hand is a proprietary and commercial rabbit hole that will cost you some serious bucks once you need to customize it.
Actually, it will cost you some serious bucks right out of the box, if you implement everything a mid-sized org will want. Customizing will cost you plenty of time and a budget that needs 3 levels of approval.
"Somebody has to do something. It's just incredibly pathetic it has to be us."
--- Jerry Garcia
I have to agree with the fact that Drupal is very complex and takes a bit to wrap your head around. I would have to disagree that it's a piece of crap... The #1&2 reasons people's installs/projects fail is due to them installing an un-audited module and "easy-to-get-to-and-read" tutorials. If you are going to use open source, you have to come to grips with authors' lack of coding skills and/or experience with open projects. Always test modules first in a dev environment, then implement. If you are scared of other peoples code, then write your own to hook into the core. It's fairly straight forward to get started and the flexibility from there onwards is only limited by your time invested into learning... Drupal is a very solid architecture. Peoples lack of discretion is that installation's downfall... Oh, and no body has even mentioned the powerful SEO capabilities out of the box... While every CMS has it's target audience, Drupal may not be for you... but it just might be!
drupal is not hard to use. the reason it has an 'initially light footprint' is because only essential functionality is packaged with the install. there are a handful of add-on modules which should be installed for just about any site: CCK, Views, and ImageField/ImageCache/ImageAPI. once you get the hang of installing these modules (e.g., unzipping the files into the modules directory, loading up the modules admin screen and clicking a checkbox) then you are set to go.
there doesn't need to be a book about this. a wiki page, maybe. in my experience, the only rough thing about drupal is figuring out which modules you want - there are thousands of user-contributed modules, a hundred or so which are good, and a handful which are excellent. but this could be solved with a better module directory on drupal.org - it doesn't speak against the software.
and this comes from someone who knows next to nothing about php or any other programming language. Setting up a small site/community site is pretty easy and you don;t need a book, you read the forums. NOW I will say this that multi user multimedia control or say a photo gallery is a fucking chore to set up and eventually you just give up .There are a few promising modules like Node Gallery and one of the better ones Acid Free Albums which isn't even maintained anymore.
by TheSpoom (715771) Uncaring Linux user here. I have nothing to add to this but please continue. *munches popcorn*
I've had great luck with it the last 18 months or so and the site has scaled pretty well with my needs. I had some complaints from my host when I was on shared hosting that I was hitting their database pretty hard, but I turned on caching for anonymous users and it's been smooth sailing since.
Reviewing just the first hour of video games.
I run free software almost exclusively, and even I LOL'd at that.
It applies to so many web apps that I can think of, it is almost not funny. Almost.
Drupal only sucks if you don't know how to use it. It's pretty great if you do.
I just don't get it. Most of the negative posts here so far just seem completely inaccurate. They must be written either by fanboys for other CMS systems or by people that have no clue to start with.
I'm not a web developer and I don't know even a bit of PHP and I am able to understand how Drupal works and get it to work fine for me. Granted, Drupal is not a panacea, but as far as open source CMSs go, I think it's one of the best available.
This has always been a debated topic. Depending on the needs of your client, or yourself, sometimes it is best just to make a custom CMS. Some non-developer types out there might scoff at this, but think of it this way. You could literally make your own CMS after learning some basic functions of PHP and MySQL. As a matter of fact, as a "designer" I think it is necessary that you understand these concepts. Once you see what is involved with making a simple CMS, then figure out whether or not you should use a big solution like Drupal or Joomla. But in all honestly, once you learn how to CREATE, INSERT, ALTER and UPDATE data from forms, and use the mysqli_connect function, you'll soon start to realize that you can be much more artistic with your sites. I'm not saying everyone should make a custom CMS, but the majority of small clients just want to edit the text on their homepage, put up new pics in their photo galleries, have a user submitted testimonials page that they can moderate, and keep in touch with their website visitors with the help of a mailing list. All of which can be accomplished with a couple days of reading up on some basic PHP and MySQL tutorials.
I've tried so hard to use Joomla and Drupal, and it just isn't for me. I could spend DAYS trying to figure out how to make a custom theme, or simply spend a couple hours making my own site layout from scratch, throw in a couple divs and some PHP scripts, and be done with it.
*plays the Apogee theme song music*
Hey there, I've put together a couple sites in Drupal and DotNetNuke recently, and Joomla beforehand, and must state that Drupal is far more useable and powerful than either of the other two CMSs. Here are the general differences: Drupal is a little more challenging to learn, but far more flexible. I can easily create data types and taxonomies, and relate information across modules and locations in the site. Its theming is relatively simple, and it's not a pain to incorporate social / profile elements in a standard way, across the site. Theming login modules and other user elements is simple enough. Its code is pretty good - very good, in many cases. On the other hand, DotNetNuke is like legacy software stacked upon legacy software upon legacy software. It has been nothing but trouble. Its modules don't communicate easily with one another and, unless you want to recompile the entire clunky thing, its code is a pain to change around. I definitely don't recommend it for a big-time site, no matter what they state on their homepage. Otherwise, it's somewhat easy to change *content* on pages - but again, not as powerful as Drupal. Finally Joomla is somewhere in the middle. Very easy to use, but on the other hand, not as powerful. It's fine for a beginning site, but probably not the tool/base I'd choose for a very advanced site with multiple social features and custom needs. Cheers! --Dave
I just started playing with Drupal. I have not ruled out trying Joomla, but Drupal seems to have pretty good support out there, so I tried it.
What I like about Drupal is what most graphic design people would hate about it. Out of the box it is not easy to drop a graphic here some text there and make a site. Drupal seems to be focused on storing and presenting lots of information in a consistent way. The admin might make a new type of node in Drupal and give the user some fields to fill out. To the user it seems very simple to post a news release, a blog, or a podcast. To the admin the nodes provides a powerful way to keep things consistent and easy to find.
I will probably check out Joomla and see what it's philosophy is. All I know is that anything is better than Sharepoint -- what a mess!
This book was great when it came out. Over a year ago. Strange to get such a late review of a book. Fortunately a lot of things are still accurate, and Drupal 6 has been the main release during this entire time, but sheesh. The contributed modules have improved a lot since then.
As far as Drupal itself goes, it's great. Yesterday my boss asked me to put together a secure site where a select group of people could discuss the upcoming budget cuts. The site needed to be attractive, secure, support single signon (integrating with our existing directory), restricted to one group of users, allow optional anonymity of posters (after authentication), and allow users to subscribe to threads.
Starting from scratch, I had it all done in an hour an twenty minutes with Drupal (plus the hidden author, subscriptions, pubcookie, pubcookie site access, secure pages, and views modules).
There seems to be a great deal of frustration and outright ignorance about how Drupal works in the postings above. If you want to be able to wield a complex weapon like Drupal, try the following resources.
For examples on how to create common types of sites using popular, well-supported modules: Using Drupal, O'Reilly
If you're a designer working with Drupal and want to understand how to work with it: Front End Drupal, Prentice Hall
If you're a coder and want to know how Drupal works internally: Pro Drupal Development, Apress
If you're not a book reader but like watching videos, pretty much anything put out by Lullabot
If you're not a coder or designer but a power user who has to deal with Drupal's admittedly byzantine administrative interface: Drupal 6 Content Administration
Drupal is the worst form of CMS except for all the others that have been tried.
If at first you don't succeed, destroy all evidence that you tried.
If you have a site that either 1) has no users, all anonymous. 2) if you have users, lots of power.
Can you predict the future? No, neither could he.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
As a DBA and Linux admin, I've had nothing but trouble with Drupal. We have several large-ish Drupal deployments, and we've had to hack away at the code for over a year now, and it's getting stable now, because we started building our own Drupal version with a shitload of patches to the core.
Drupal works indeed fine for small-scale deployments, but as soon as you want to use Drupal's famed flexibility and customizability, and scale your site out, you're going to run into trouble, mostly with your database - especially if you want a lot of logged-in-only content.
If Drupal is really serious about going on to be used for large, professional deployments, the best recommendation I have for Dries and the gang, is to abandond the entire "but we want to be compatible with all databases" whine, and decide on ONE database, which they use CORRECTLY and EFFICIENTLY. I'm sorry, but nearly a hundred queries for a single pageview is not acceptable. Please decide on an optimum technology stack and use it efficiently; and publish both the optimum stack and a fully patched, efficient version of the code specifically for large-scale deployments.
We've in the mean time rewrote the caching engine to correctly support Memcached - some parts of Drupal still fuck up, though, so ftm we've got 12 separate Memcache bins for every site deployment, to avoid one module flushing the cache of an entirely different site. We looked at read-write splitting for the database, and found that it won't work (on mysql, at least) because of the way Drupal interacts with the database. We're doing ugly tricks wih Squid and cookies, because not-logged-in users sometimes get content from logged-in pages. We've done oodles of patches on Drupal core, to optimize database use and remove needless full table locking. We're writing custom modules to avoid using Drupal Views, which create queries that are so inefficient that one of them on the front page can kill your monster of a database host.
No, Drupal may be very good for quick, small deployments, but if you're looking for something to build a high-traffic site with plenty of customization and member-only data, you're better off building your own framework from scratch, with scalability in mind.
What a depressingly stupid machine.
I do see a lack of civility in your posts, but not much information.
Drupal does claim to be modular. It doesn't often claim to be simple, unless you are only using a few core modules, perhaps in the default install, for instance, to make a blog. In the base install it _is_ less polished than, say, Wordpress. But it does more. I'm not sure how you measure intuitivity - what's intuitive for one person isn't necessarily, for another.
I don't know what you mean by 'Behavours are inconsistent across themes'. Isn't the point of themes to bring individualism to your Drupal installation? Doesn't that by definition mean that different themes will do different things?
Regarding 'Half the available themes are broken'. I have no idea where you get this statistic. I do know that if you install a Drupal 5 theme on a Drupal 6 installation, it will most likely not work. Perhaps that's what you did?
Regarding 'Not supporting things off the bat'. Again, I'm not sure what you want? By default Drupal 6 supports posting stories, pages, blogging, aggregating content from feeds, hierarchically structured collections of pages, comments on any content, contact forms, multilingual sites, forums, login with OpenID, polls, clean URLs, content categorisation, registered user profiles, searching, basic statistics tracking, and user uploads. Amongst other things. I'm not sure what else you would like a CMS to do as in the basic installation.
Regarding 'Enabling the modules requires manual downloads and dependency hells.'. Yes, in most installations you have to manually download and enable modules. This makes it more secure. Modules list their requirements and will not allow you to enable them unless their dependencies are also available. I'm not sure how this is 'hell'? Surely it's sensible not to allow a module to be enabled if it's guaranteed to break?
Regarding 'The notion of using the site as you build it is shit,' On the other hand, eating your own dogfood is a very good way of being sure that your users will enjoy the site you are building.Usually one would put the site into maintenance mode, but this isn't required. But again, if you don't like to use what your users use, you ARE able to use an admin theme. If you are building a larger site, it's not recommended practice to work on the live site. I have no idea what you mean about 'just writing your own CSS'.
'The only people who are willing to waste the time to understand Drupal enough...are those...chasing buzzwords...' Drupal is not for everyone. It's definitely not perfect; it's a large, rapidly growing system, which is being improved as it grows. Quality outside of the core is variable, as you would expect. It doesn't solve every problem, despite having around 5,000 modules available, spread across Drupal 5 and 6; clearly it didn't suit you, although it is fine for hundreds of thousands of other users. I don't know what problem you were trying to solve, but there are many CMS out there, and I'd recommend you start by investigating Sharepoint.
What is large-ish in your context? I'm not sure that readers will realise that you are coming from a particular point of view. I maintain a Drupal installation with 1.5m nodes, which I wouldn't call large, because it has a limited purpose and does not use hundreds of extra modules. We have not had to patch or customise. And it runs on a VM on commodity hardware.
I assume that you have a site with a great deal of functionality. Not every reader will realise that a CMS that is modular is naturally going to result in an explosion of queries; every module controls its own queries, each with its own tables. There are several ways of combating this: you can cache content and results, you can lazy-load daa, or you can reduce modularity, combining tables.
Drupal already uses the first two strategies, and occasionally prticular modules are designed to work together and implement the third. For anonymous users, pages are delivered from cache. For logged in users pages can be put together from cached blocks, if your site is set up to do this. (There are some restrictions on this; it's not available in every circumstance.) It sounds like you may have shared content which is an unusual installation. Under normal installations, one site of a multisite install does not ineract with another site. The caching is not designed with shared content multisites in mind; I've also had problems with this, but I think that this is an edge case. It would be great if your organisation would contribute your experience, by posting your rewritten cache engine.
I don't however agree with your suggestion of a focus on a single database. Yes, specialising to a single database will allow the use of features available on that database only, but at the cost of a portion of the audience. Similarly, we could say only a particular version of a particular database was supported, to allow us to use the optimisations available for that engine, but again this would cut the audience dramatically. Instead what is needed is a structured way to optimise. To a small extent this is already available through the SQL rewite hook, but this isn't especially safe. Drupal 7 deals with this by abstracting the SQL further, but the SQL rewrite is much safer, and more suited to rewrites for optimising.
I'd be really interested in where you've had full table locking problems. Do you have an issue reference on drupal.org?
Regarding "... if you're looking for something to build a high-traffic site with plenty of customization and member-only data, you're better off building your own framework from scratch..." With any CMS there's a trade-off: you can build your own, bearing the full cost yourself, or you can use one that's built already, whether closed or open source, amortizing the cost of the build over many organisations and individuals. By my estimation, Drupal core represents many millions of dollars of work. It's possible that your organisation can afford to invest that sort of amount in your own custom CMS, but the experience of companies that have built their own is that the cost of maintenance is too high, and many of them are migrating to open source software, which does more than they could hope to do, at a cheaper price, but which comes with its own problems. Organisations can use the money saved on the build to either make larger sites, more sites, or specialise the system, which is what your organisation appears to be doing.
It would be fantastic if others could learn from your DBA experience. Would you consider posting a case study to drupal.org?
People who have no experience with anything other than hotmail or google need some kind of base, the ability to NOT spend thousands of dollars every time they need their site altered. I like working with drupal because it is easy, unless you are completely in the dark. Learning is good, sometimes it can be a "waist of time" but at least your brain isn't rotting.
I absolutely agree - look at the source code - one of the reasons that we standardised on Drupal was that the code is well structured and well thought out. It's based on a call-back system with hooks triggered by naming convention. It is well documented, and has a wide series of tests that are automatically run against it, for regression tests of changes. The API is documented at api.drupal.org, and includes examples of how you can extend the system.
All the above applies to the core code, and the widely used modules just outside core - like Views, which is a module to help non-programmers build structured queries and present the results.
I agree that amongst the third-tier modules, the quality varies hugely, as you see in much open-source software. Some of them are very well written, but others are not.
Each module has an issue queue, which is publicly visible, and usage statistics tell you how widely it's used, which allows you to make some decisions even if you aren't a coder.
The only criticism I have with the core code is a technical one that doesn't matter to end-users; most of it is not object-orientated. This is not to say that it's unstructured: it is very modular. And there's a good reason it's not object oriented: it's because PHP4 made it very difficult to build a name triggered callback system with objects. However, I expect the core will become more and more object oriented over time since PHP5 objects are much more robust with reasonable performance characteristics.
Thanks for the detailed reply. Sorry, I wasn't meaning to teach you to suck eggs. That part of my reply was for readers who don't know much about Drupal beyond it having a strange name.
Interesting: I didn't know about the table lock on cache! Are you using Drupal 6? I've just done a search, but didn't find anything. I did find a status report I didn't know about! At admin/reports/status/sql which shows lock hits amongst other things. Maybe you are on Drupal 5? The cache updates I found where all straight inserts/updates or deletes. But whatever - I'd say that you were right in moving caching to memcached if you have to support millions of pageviews.
Yes - I agree the cache layer needs PHP execution, and that's not so great. Actually, IMO it's not the PHP, but that it's a hit against the database, even though it is a single query. A hit against the file system would avoid the whole DB connection and query. Drupal Boost caching module wouldn't bring huge benefits for you because you have lots of logged in users, but it uses static files and doesn't hit the database.
Block cache can be efficient at cutting down database hits and code execution. And if you are using Views2, it will also use block caching for HTML and queries. It has options for lots of different caching strategies - from one for everyone through to per user per block. Block caching not well documented though.
One thing that I'm not sure of is why one website would interfere with the cache of another if you are not sharing content. [Readers: you can configure Drupal to use a single database for all websites, or multiple databases. If you have a single database, then you can configure each installation to use a different set of tables, through setting a prefix to the table name. It's very unusual to share any of the cache tables across sites except in the shared-content scenario, where the same content is being presented on more than one website.] Maybe I've misunderstood. It might be that the sites are running on a cluster against a db shared across the cluster. In this scenario, I can imagine one machine locking others out, though I'm not sure where in the code a table lock is.
Multisite: Good points and bad points. The management of update is the bad point, when you put in a new module with database upgrades. You have global downtime unless you do progressive updates by putting the module first in the specific directory for each of the particular sites and running update for that site. But it does lower the admin cost.
SQL rewriting works in some circumstances. See hook_db_rewrite_sql. [Readers: The base problem is that it's difficult with modularity to avoid explosion of queries. This is true of all modular systems with database interactivity. You can avoid it if one module is intimately aware of another, and then the two can co-operate, though this is context dependent. For instance - if the first module loads the user details (name, user account, email, etc), and a second, optional, module loads a user profile, then you could cut down on the queries by including the user profile columns as part of the user table, and loading the two at the same time. Modularity, however, is not your friend here - to make the management of a profile module easy, it's much better to have it in its own table. But now you are doing table joins or loading one and then the other. If you have a heavily customised system, then you can make the joined table by hand, and modify the queries. You can do this either by changing the core code, or by rewriting the SQL on-the-fly, by writing a new module. With the second option you can leave the core alone, and your changes are overlayed, at the cost of a small drop in performance of the PHP (since there's an extra function to run). The PHP drop is almost certainly negligible compared to the database speed-up, except where the database is already in memory.]