Slashdot Mirror

I guess they should start with taking down whitehouse.gov now that the Administration has switched to Drupal.

(Who comes up with these names? "drupal" always makes me think of "droopy" which isn't really what I'd want my web site to be.)

Sorry, I was referring to the feature that automatically CHECKS for updates, colour codes your out-of-date modules, and provides a direct download link to the latest version (ie the Available Updates page). I would classify that as extremely easy.

the stable 6.x version requires you to do a lot of file and configuration manipulation just to go from 6.14 to 6.15 (if you follow all the recommended steps, which I did for my test site recently)

You don't have to do all those steps. You just need to replace the core files and run any required database updates. Yes, I know the documentation specifies a lot more steps... I brought up this very issue in a thread (posting as "brian_c") here: http://drupal.org/node/360656

I find strange that the article talks about the upgrade path, but doesn't mention that Drupal 7 includes a modules and themes auto-update feature: "Update Manager: Building on Drupal 6's Update module, which keeps site administrators informed when new module and theme releases are available, the new Update Manager module can also install and upgrade modules and themes."

There's also an interesting link not included to TFS named Top Ten Changes That Make Drupal 7 the Best Version.

I have an interest in Drupal, since I'll be moving Slashgeo.org from Slashcode to Drupal in the coming weeks (here's why).

Great question. Got me to thinking there must be an Eclipse or Firefox plugin for that. Found a few I'll have to check out now. MyLyn looks promising from IBM http://www.ibm.com/developerworks/java/library/j-mylyn1/ though it seems to more programming oriented than what you do.

For FireFox, maybe Quick ToDo list https://addons.mozilla.org/en-US/firefox/addon/11386 or Time Tracker https://addons.mozilla.org/en-US/firefox/addon/1887

Set up a quick Drupal http://www.drupal.org/ site with pages you can privately blog to as an online notebook. Use Time Tracker in Firefox to track time on each task page.

I dunno - just made all this up.

K I skimmed this whole thread, the core problem & solution are elusive. Part of it is a decline in the 'harmony' of Linux app/desktop design integration, part is the information 'rot' of obsolete threads found on Google. The Gentoo wikis are pretty much the only bright spot here, no one can even cite a good GUI linux app documentation.

I'm not a Linux expert but I spend a lot of time dealing with Drupal which is also GPLed and regarded as a tough learning curve. They have dedicated a ton of effort into not just the documentation and forums but also U of M usability research. I met Dries at the U of M before they went in and looked at how peoples eyeballs scattered in panic because a RED ALERT BOX was worried their user creation password was not secure enough. They got a draft usability plan out of the research:
http://groups.drupal.org/node/9252 - and even video of eyes mapped around the screen.
In this case the information, inline documentation really, came in perceived as too hot by being RED so they changed it in Drupal 7 to light orange bkgnd. You structure the information to direct attention appropriately and then deliver snippets when the environment changes.

Think about it: we have totally divorced 'documentation' from even considering how important little snippets of text are, delivered correctly *with the correct level of detail* AND *the ability to seek up down and laterally in the conceptual environment*, instead thinking of man vs info vs annoying old threads. Probably the most important documentation, definitely for non-GUI Linux, are the small, less-than-ten-line, instructions and advisories that come before prompts. And usually these have HTTP links included for big deals. If everyone tripled their effort here it would work a lot better than just cleaning up the disastrously wrong (or certainly obsolete) design of man and info pages. Could familiar man pages spit out more examples and not exhaustive list of flags? (well it has to if you believe man must only be one page of stuff with all the programmer hooks, signals &etc. Where's the non-programmer material to be found then?)

Good wiki pages for software documentation usually break text into similar less-than-ten line sections, and do so in an up-down-lateral hierarchy of headers. Fortunately this can get exported and stashed into the app. If you had wiki paragraphs XML tagged to land in certain dialog boxes and other points, you could pipe wikified micro-documentation into the apps, even desktop apps. Hell if you just put a "WIKI??" button right there in the modal dialog box or prompt at least half the users would get it immediately. If a clever crew was handling this 'help string wiki' it would work out fine probably.But you'd have to control yr wiki or yr enemies would put in bad Windows YES/NO dialog boxes' help ("Do you want to print or save? YES/NO") just to mess w you.

Anything you present an end user should be structured in the newspaper article style - a pyramid structure leading with 'what does this do? how can i do the 3-5 basic things? why does this matter? what is this related to?' Beyond that you should be able to reach an overview of that part of the system architecture. Like apache2ctl would get you to rc and rc.conf and note what the runlevel is and why / which daemons are at runlevels.

There should be a clear ontology between nodes and levels of information. There is usually no explicit way to back out from a command to where the command fits in the system, or something you can run to lookup what a weird file does. maybe also the Apple 'receipt' type file that is a breadcrumb for packages could be used as a way to pull out documentation from different versions, another big gripe/snag here. There is not a lot of unity between Linux packaging systems and documentation and window managers. Obviously packaging info is already quite helpful but once things are installed it doesn't 'appear' anywhere useful, to other apps (imagine special warnings fo

In front of management, I asked him to explain why stable versions (some of these stable releases were several years old, too) of the software he was recommending contained over 100 bug fixes. He couldn't provide a suitable answer, and thus management gave him the boot. And so we're not using Drupal.

http://php.net/ChangeLog-5.php

Most recent version has approx 110 bug fixes, which was on 19-November-2009, the previous version (minor version) had a pretty big pile and that was just a couple months prior, and the same story going back.

The Drupal changelog shows... 3 bugs fixed...

So.... either your story is pure bullshit, or you are a first class moron. Or both more than likely.

http://drupal.org/node/579476 [Drupal 6.14 changelog lists 51 bug fixes plus multiple security fixes to 6.x core]

http://drupal.org/node/579484 [Drupal 5.20 changelog lists 6 bug fixes plus multiple security fixes to the 5.x core]

Who in the hell wouldn't use 6.14 over 5.20?

In front of management, I asked him to explain why stable versions (some of these stable releases were several years old, too) of the software he was recommending contained over 100 bug fixes. He couldn't provide a suitable answer, and thus management gave him the boot. And so we're not using Drupal.

http://php.net/ChangeLog-5.php

Most recent version has approx 110 bug fixes, which was on 19-November-2009, the previous version (minor version) had a pretty big pile and that was just a couple months prior, and the same story going back.

The Drupal changelog shows... 3 bugs fixed...

So.... either your story is pure bullshit, or you are a first class moron. Or both more than likely.

http://drupal.org/node/579476 [Drupal 6.14 changelog lists 51 bug fixes plus multiple security fixes to 6.x core]

http://drupal.org/node/579484 [Drupal 5.20 changelog lists 6 bug fixes plus multiple security fixes to the 5.x core]

Who in the hell wouldn't use 6.14 over 5.20?

That is a load of dingo's kidneys, because nobody had to manually generate sparklines, either. There are already numerous systems which dynamically generate them as needed, for example a drupal module. This is a ridiculous patent, as completely insane as any "business method" patent, except instead of taking a common business model and adding "on the internet", it's taking an already-accepted practice and adding "in excel". By any reasonable standard, this is a bad patent application.

Yes it is. There's even a module for it: http://drupal.org/project/og

O'Reilly's Using Drupal is pretty helpful with the basics. I'm not going to lie to you, there's definitely some opaque terminology in there, but I've noticed that seems to be true with CMSes in general. I still tend to squint a bit when I have to think about vocabularies and taxonomies, so don't feel too bad.

Once you figure out that just about everything in Drupal is a database object, it all starts to make sense. A "node" is functionally the same as a database table. A "view" is functionally the same as a database query. "Vocabularies" and "taxonomies", meanwhile, can be thought of as related tables that you can use to fine-tune your queries (erm... "Views"). Just as you can have two tables with identical data types but different names, and just as you might do that for organizational purposes (i.e. one table stores shop equipment, the other stores shop inventory), you can use "nodes" with similar data types but different names. In fact, if memory serves, a "Page", "Story", and "Blog Post" all use the same data types, but are given different names so you can treat each one differently if you're so inclined. Similarly, just as you can have a table with a column that stores related information with another table (say, a key that corresponds to a specific manufacturer), you can attach a taxonomy to a class of nodes (Page, Story, Blog, custom, whatever), and even have what amounts to sub-taxonomies ("Vocabularies").

To be honest, the data structure format isn't what drives me slightly insane about Drupal. No, in my case, it's the rather frustrating experience of finding the right combination of modules that actually does something useful. For example, let's say you want a contact form. Naturally, you would use the built-in Contact module, right? Ah, but then you're limited to only having one contact form on the entire site - that's probably not what you want. Let's see if somebody expanded it. Well, there's the Contact Forms module, which lets you split out each contact form category into a separate page. But, what if you want each contact form page to be able to handle a bunch of categories, or what if you want to control the URL it generates? Chances are, if you want a contact form that you can move around, or even have more than one contact form, you need a way to store contact forms as something that Drupal natively moves around so you can treat them like every other object in your system. So, now what? Do we try Contact Form On Node? What if I want it in a block? Shall we give Contact Form Blocks a try? Or do we try Form Block? Or, do we use the Webform module, which gives us forms as nodes? Or, do we just write our own module and be done with it? Then there's the matter of theming...

Don't get me wrong. If you know what you're doing and you have the time and patience to get through it, you can do some pretty cool stuff with Drupal. That said, if the only CMS you've ever touched in your life was something like Wordpress, you're in for a rough ride.

O'Reilly's Using Drupal is pretty helpful with the basics. I'm not going to lie to you, there's definitely some opaque terminology in there, but I've noticed that seems to be true with CMSes in general. I still tend to squint a bit when I have to think about vocabularies and taxonomies, so don't feel too bad.

Once you figure out that just about everything in Drupal is a database object, it all starts to make sense. A "node" is functionally the same as a database table. A "view" is functionally the same as a database query. "Vocabularies" and "taxonomies", meanwhile, can be thought of as related tables that you can use to fine-tune your queries (erm... "Views"). Just as you can have two tables with identical data types but different names, and just as you might do that for organizational purposes (i.e. one table stores shop equipment, the other stores shop inventory), you can use "nodes" with similar data types but different names. In fact, if memory serves, a "Page", "Story", and "Blog Post" all use the same data types, but are given different names so you can treat each one differently if you're so inclined. Similarly, just as you can have a table with a column that stores related information with another table (say, a key that corresponds to a specific manufacturer), you can attach a taxonomy to a class of nodes (Page, Story, Blog, custom, whatever), and even have what amounts to sub-taxonomies ("Vocabularies").

To be honest, the data structure format isn't what drives me slightly insane about Drupal. No, in my case, it's the rather frustrating experience of finding the right combination of modules that actually does something useful. For example, let's say you want a contact form. Naturally, you would use the built-in Contact module, right? Ah, but then you're limited to only having one contact form on the entire site - that's probably not what you want. Let's see if somebody expanded it. Well, there's the Contact Forms module, which lets you split out each contact form category into a separate page. But, what if you want each contact form page to be able to handle a bunch of categories, or what if you want to control the URL it generates? Chances are, if you want a contact form that you can move around, or even have more than one contact form, you need a way to store contact forms as something that Drupal natively moves around so you can treat them like every other object in your system. So, now what? Do we try Contact Form On Node? What if I want it in a block? Shall we give Contact Form Blocks a try? Or do we try Form Block? Or, do we use the Webform module, which gives us forms as nodes? Or, do we just write our own module and be done with it? Then there's the matter of theming...

Don't get me wrong. If you know what you're doing and you have the time and patience to get through it, you can do some pretty cool stuff with Drupal. That said, if the only CMS you've ever touched in your life was something like Wordpress, you're in for a rough ride.

O'Reilly's Using Drupal is pretty helpful with the basics. I'm not going to lie to you, there's definitely some opaque terminology in there, but I've noticed that seems to be true with CMSes in general. I still tend to squint a bit when I have to think about vocabularies and taxonomies, so don't feel too bad.

Once you figure out that just about everything in Drupal is a database object, it all starts to make sense. A "node" is functionally the same as a database table. A "view" is functionally the same as a database query. "Vocabularies" and "taxonomies", meanwhile, can be thought of as related tables that you can use to fine-tune your queries (erm... "Views"). Just as you can have two tables with identical data types but different names, and just as you might do that for organizational purposes (i.e. one table stores shop equipment, the other stores shop inventory), you can use "nodes" with similar data types but different names. In fact, if memory serves, a "Page", "Story", and "Blog Post" all use the same data types, but are given different names so you can treat each one differently if you're so inclined. Similarly, just as you can have a table with a column that stores related information with another table (say, a key that corresponds to a specific manufacturer), you can attach a taxonomy to a class of nodes (Page, Story, Blog, custom, whatever), and even have what amounts to sub-taxonomies ("Vocabularies").

To be honest, the data structure format isn't what drives me slightly insane about Drupal. No, in my case, it's the rather frustrating experience of finding the right combination of modules that actually does something useful. For example, let's say you want a contact form. Naturally, you would use the built-in Contact module, right? Ah, but then you're limited to only having one contact form on the entire site - that's probably not what you want. Let's see if somebody expanded it. Well, there's the Contact Forms module, which lets you split out each contact form category into a separate page. But, what if you want each contact form page to be able to handle a bunch of categories, or what if you want to control the URL it generates? Chances are, if you want a contact form that you can move around, or even have more than one contact form, you need a way to store contact forms as something that Drupal natively moves around so you can treat them like every other object in your system. So, now what? Do we try Contact Form On Node? What if I want it in a block? Shall we give Contact Form Blocks a try? Or do we try Form Block? Or, do we use the Webform module, which gives us forms as nodes? Or, do we just write our own module and be done with it? Then there's the matter of theming...

Don't get me wrong. If you know what you're doing and you have the time and patience to get through it, you can do some pretty cool stuff with Drupal. That said, if the only CMS you've ever touched in your life was something like Wordpress, you're in for a rough ride.

O'Reilly's Using Drupal is pretty helpful with the basics. I'm not going to lie to you, there's definitely some opaque terminology in there, but I've noticed that seems to be true with CMSes in general. I still tend to squint a bit when I have to think about vocabularies and taxonomies, so don't feel too bad.

Once you figure out that just about everything in Drupal is a database object, it all starts to make sense. A "node" is functionally the same as a database table. A "view" is functionally the same as a database query. "Vocabularies" and "taxonomies", meanwhile, can be thought of as related tables that you can use to fine-tune your queries (erm... "Views"). Just as you can have two tables with identical data types but different names, and just as you might do that for organizational purposes (i.e. one table stores shop equipment, the other stores shop inventory), you can use "nodes" with similar data types but different names. In fact, if memory serves, a "Page", "Story", and "Blog Post" all use the same data types, but are given different names so you can treat each one differently if you're so inclined. Similarly, just as you can have a table with a column that stores related information with another table (say, a key that corresponds to a specific manufacturer), you can attach a taxonomy to a class of nodes (Page, Story, Blog, custom, whatever), and even have what amounts to sub-taxonomies ("Vocabularies").

To be honest, the data structure format isn't what drives me slightly insane about Drupal. No, in my case, it's the rather frustrating experience of finding the right combination of modules that actually does something useful. For example, let's say you want a contact form. Naturally, you would use the built-in Contact module, right? Ah, but then you're limited to only having one contact form on the entire site - that's probably not what you want. Let's see if somebody expanded it. Well, there's the Contact Forms module, which lets you split out each contact form category into a separate page. But, what if you want each contact form page to be able to handle a bunch of categories, or what if you want to control the URL it generates? Chances are, if you want a contact form that you can move around, or even have more than one contact form, you need a way to store contact forms as something that Drupal natively moves around so you can treat them like every other object in your system. So, now what? Do we try Contact Form On Node? What if I want it in a block? Shall we give Contact Form Blocks a try? Or do we try Form Block? Or, do we use the Webform module, which gives us forms as nodes? Or, do we just write our own module and be done with it? Then there's the matter of theming...

Don't get me wrong. If you know what you're doing and you have the time and patience to get through it, you can do some pretty cool stuff with Drupal. That said, if the only CMS you've ever touched in your life was something like Wordpress, you're in for a rough ride.

O'Reilly's Using Drupal is pretty helpful with the basics. I'm not going to lie to you, there's definitely some opaque terminology in there, but I've noticed that seems to be true with CMSes in general. I still tend to squint a bit when I have to think about vocabularies and taxonomies, so don't feel too bad.

Once you figure out that just about everything in Drupal is a database object, it all starts to make sense. A "node" is functionally the same as a database table. A "view" is functionally the same as a database query. "Vocabularies" and "taxonomies", meanwhile, can be thought of as related tables that you can use to fine-tune your queries (erm... "Views"). Just as you can have two tables with identical data types but different names, and just as you might do that for organizational purposes (i.e. one table stores shop equipment, the other stores shop inventory), you can use "nodes" with similar data types but different names. In fact, if memory serves, a "Page", "Story", and "Blog Post" all use the same data types, but are given different names so you can treat each one differently if you're so inclined. Similarly, just as you can have a table with a column that stores related information with another table (say, a key that corresponds to a specific manufacturer), you can attach a taxonomy to a class of nodes (Page, Story, Blog, custom, whatever), and even have what amounts to sub-taxonomies ("Vocabularies").

To be honest, the data structure format isn't what drives me slightly insane about Drupal. No, in my case, it's the rather frustrating experience of finding the right combination of modules that actually does something useful. For example, let's say you want a contact form. Naturally, you would use the built-in Contact module, right? Ah, but then you're limited to only having one contact form on the entire site - that's probably not what you want. Let's see if somebody expanded it. Well, there's the Contact Forms module, which lets you split out each contact form category into a separate page. But, what if you want each contact form page to be able to handle a bunch of categories, or what if you want to control the URL it generates? Chances are, if you want a contact form that you can move around, or even have more than one contact form, you need a way to store contact forms as something that Drupal natively moves around so you can treat them like every other object in your system. So, now what? Do we try Contact Form On Node? What if I want it in a block? Shall we give Contact Form Blocks a try? Or do we try Form Block? Or, do we use the Webform module, which gives us forms as nodes? Or, do we just write our own module and be done with it? Then there's the matter of theming...

Don't get me wrong. If you know what you're doing and you have the time and patience to get through it, you can do some pretty cool stuff with Drupal. That said, if the only CMS you've ever touched in your life was something like Wordpress, you're in for a rough ride.

Check out the Organic Groups module.

The review is well timed. The book was from the beginning of the year, but since then the US Whitehouse has gone back to FOSS on its web site. It's using drupal. It's good to see more discussion of these tools. Everyone has heard of Drupal and plone and respect the capabilities. They are the heavy hitters like Apache2 for httpd.

What new FOSS CMS tools are corresponding to Lighttpd and nginx, ready and useful but not as visible as they could be?

We use it for our intranet and everyone seems to like it. As far as developing for it: what exactly are you wanting to do? There are a bazillion pre-made modules for just about every task you can imagine, and you're probably better of finding something close to what you need and making minor adjustments as necessary.

Honestly, I can't think of anything bad about it. If nothing else, why not install it on your own machine and play with it until you get everything working the way you like it, then move your settings.php file onto a production server. It's not like you have to buy licenses for multiple installations.

There are potentially thousands of companies using Drupal for intranets (we can't track them due to the free download / no login required). They include small and large companies from BMW to Intel to Pfizer. Much more detail can be found on drupal.org. Here is a link to one post http://drupal.org/node/588636 If you have any other questions, feel free to contact us at Acquia www.acquia.com

If you are a normal corporatation (using Office) I would recommend SharePoint instead.

Yes, each version is an evolutionary jump on the previous version. Not surprisingly, D6 has got better caching than D5.

Boost: It replaces pages with static html. This static cache is updated on a schedule. But if you have someone who is logged in, because it completely bypasses PHP, you have to replace all the page elements that are different for logged in people with Javascript driven widgets which load the block data dynamically. For a site with lots of elements this is a lot of work. Plus you are depending on Javascript being switched on. So if you have lots of logged in users, and lots of blocks just for logged in users, and you don't have much control over their environment the site is viewed in, then this isn't really a starter.

Global cache clear whacks everything, obviously, but it's quite surprising to me that item/page cache clear does this. I've never had a close look at caching on D5, but knowing that there's a potential problem here is useful. Thanks.

I'm guessing that you already track the groups.drupal.org that deal with high volume sites and the distributions intended for your situation like PressFlow, Mercury, OpenPublish, and http://groups.drupal.org/high-performance. Pressflow in particular has spent lots of effort on optimisation, and there's a D5 version. Pressflow also only supports MySQL, which answers one of your concerns. Maybe you've already trawled through it, looking at SQL optimisations they've done.

InnoDB: I can't comment, but I'm pretty sure that someone in the high-performance group has experience to offer. I think most high-performance sites are using InnoDB, and I'm pretty sure it's the Pressflow default. I know there's an issue with node counts on InnoDB, and I think that Pressflow changes the way that this is handled.

BTW - check out http://groups.drupal.org/node/25617 not so much for the comparison of performance stats on D6, because it's concerned with non-logged in users, but because the discussion below the article will probably interest you.

Once more, thanks for your very good posts; it's always useful to learn other people's experiences.

Yes, each version is an evolutionary jump on the previous version. Not surprisingly, D6 has got better caching than D5.

Boost: It replaces pages with static html. This static cache is updated on a schedule. But if you have someone who is logged in, because it completely bypasses PHP, you have to replace all the page elements that are different for logged in people with Javascript driven widgets which load the block data dynamically. For a site with lots of elements this is a lot of work. Plus you are depending on Javascript being switched on. So if you have lots of logged in users, and lots of blocks just for logged in users, and you don't have much control over their environment the site is viewed in, then this isn't really a starter.

Global cache clear whacks everything, obviously, but it's quite surprising to me that item/page cache clear does this. I've never had a close look at caching on D5, but knowing that there's a potential problem here is useful. Thanks.

I'm guessing that you already track the groups.drupal.org that deal with high volume sites and the distributions intended for your situation like PressFlow, Mercury, OpenPublish, and http://groups.drupal.org/high-performance. Pressflow in particular has spent lots of effort on optimisation, and there's a D5 version. Pressflow also only supports MySQL, which answers one of your concerns. Maybe you've already trawled through it, looking at SQL optimisations they've done.

InnoDB: I can't comment, but I'm pretty sure that someone in the high-performance group has experience to offer. I think most high-performance sites are using InnoDB, and I'm pretty sure it's the Pressflow default. I know there's an issue with node counts on InnoDB, and I think that Pressflow changes the way that this is handled.

BTW - check out http://groups.drupal.org/node/25617 not so much for the comparison of performance stats on D6, because it's concerned with non-logged in users, but because the discussion below the article will probably interest you.

Once more, thanks for your very good posts; it's always useful to learn other people's experiences.

There is a excellent calendar module right here, which leverages heavily off of functionality provided by other modules (as is Drupal convention). From a standpoint of functionality, available features, and extendability, it's better than anything I found with Joomla.
http://drupal.org/project/calendar

Here's a screencast tutorial:
http://www.drupaltherapy.com/node/76

I've used this module extensively, out-of-the-box most of the time, and yes, I do so as a paid consultant from time to time.

Besides that, since Drupal tries to provide a framework for anyone and everyone to contribute pieces via 3rd-party modules, it will be as chaotic, diverse, and even inscrutable as one would expect a bazaar to be. Still, it enables that bazaar to exist in the first place.

"This theme saved me at 2am. Three hours of messing with 1000+ lines of nasty Garland-adapted code later, I abandoned it and recoded the site as a Zen sub-theme in under an hour. Thank you, thank you, thank you. - Greg "

'Nuff said, asshole.

I can't comment on the hardware part, but what you say is certainly doable.

If you go the CMS route, Drupal is a very powerful, flexible and extensible CMS. It also has a couple of add ons that facilitate this. For example, there is the kiosk module, and the kiosk theme module (I am the author of the latter). These are in use at some museums already (e.g. Science Museum of Minnesota and Arts Institute of Chicago).

Using a CMS will allow you do do many things, such as interactive quizzes, polls and surveys, display news and events, ...etc. Much more than just DVDs can do.

I can't comment on the hardware part, but what you say is certainly doable.

If you go the CMS route, Drupal is a very powerful, flexible and extensible CMS. It also has a couple of add ons that facilitate this. For example, there is the kiosk module, and the kiosk theme module (I am the author of the latter). These are in use at some museums already (e.g. Science Museum of Minnesota and Arts Institute of Chicago).

Using a CMS will allow you do do many things, such as interactive quizzes, polls and surveys, display news and events, ...etc. Much more than just DVDs can do.

I can't comment on the hardware part, but what you say is certainly doable.

If you go the CMS route, Drupal is a very powerful, flexible and extensible CMS. It also has a couple of add ons that facilitate this. For example, there is the kiosk module, and the kiosk theme module (I am the author of the latter). These are in use at some museums already (e.g. Science Museum of Minnesota and Arts Institute of Chicago).

Using a CMS will allow you do do many things, such as interactive quizzes, polls and surveys, display news and events, ...etc. Much more than just DVDs can do.

If some of the people who post here were as smart as they think they are, they'd figure out:

* Whitehouse.gov is not running Drupal on a ten-dollar shared server at GoDaddy.com.
* Building and maintaining a large, continuously updated website is not something you do in a weekend with Notepad, a giant bag of Cheetos, and a case of diet Coke.
* Any Drupal project of this scale involves layers of extremely high-performance caching and multiple firewalls.
* The site's administrative tools aren't available from the outside. (This is not difficult to implement.)
* Life does not begin and end with your personal favorite programming language, database server, etc., or with the boundaries of your parents' basement.
* Security reports are reports of vulnerabilities that have been fixed, not vulnerabilities that lie in wait to ambush your site. A properly run open-source project has a documented process for handling security issues.

I don't know any details of the site's technical architecture beyond the obvious, but it's blazingly fast. My bet is that when you hit the site, you're pulling completed pages out of RAM on a customized and hardened Varnish, but that's just a guess. The HTTP headers identify the server technology as "White House."

The deployment framework is a series of modules which are designed to allow developers to easily stage Drupal data from one site to another. This includes content (nodes, taxonomy, users, etc) as well as configuration (views, content types, system settings, etc.) Not only can it push new content, it can also push updates to existing content. Deploy automatically manages dependencies between nodes (IE nodereferences) as well as between other objects. It is designed to have a rich API which can be easily extended to be used in a variety of situations. Check out the screencast for a demo!

http://drupal.org/project/deploy

From a technology point of view, the site was open source when it first launched in February or March 2009. It used Drupal on Linux.

Now, it is using ASP.NET, presumably on Windows.

Not saying this made it less accessible. Far from it. But that there was also a switch from open source to proprietary as well.

I don't know about your sharepoint comments, but you're wrong about most everything you said about Drupal. You should have asked me for help.

http://drupal.org/project/webdav
http://drupal.org/project/notify

Also, I don't know what you mean by

as manifested by the fact that you cannot edit things were they are seen by users but rather must work through a back panel.

You click the edit tab, which gives you direct access to edit the page. I don't know how much more direct you want. It's kind of a logical fallacy to say "edit things [as] seen by users". Users cannot edit, therefore you cannot edit *and* see things the way the user would.

I don't know about your sharepoint comments, but you're wrong about most everything you said about Drupal. You should have asked me for help.

http://drupal.org/project/webdav
http://drupal.org/project/notify

Also, I don't know what you mean by

as manifested by the fact that you cannot edit things were they are seen by users but rather must work through a back panel.

You click the edit tab, which gives you direct access to edit the page. I don't know how much more direct you want. It's kind of a logical fallacy to say "edit things [as] seen by users". Users cannot edit, therefore you cannot edit *and* see things the way the user would.

This headline is dramatic and uninformed. Linux isn't the only open source project out there.

Sony has made huge contributions to the Drupal CMS (Website Content Management System).

They have hired a full-time programmer who is 100% dedicated to open source (CCK/Views modules).
They have sponsored major improvements to Drupal - http://drupal.org/node/383954

Ease up on the rhetoric, before you sour other open-source projects.

Maybe you want to couple your perceived right to hack the PS3 with open source? That's dangerous. Make an open-sourced PS3 and no problem. Mike

Especially when they're paying $18,000,000 to just install Drupal. (source: http://drupal.org/node/376036)

Also, what exactly are Vivek Kundra's qualifications for his position that place him above everyone else in the country? As best I could unearth, he apparently was the CEO of a tech company. That had one employee. And that employee was himself. And it didn't make a profit.

Also, have you heard his idiotic quote from a few days ago where he was blabbering on and on about all the "amazing" stuff he's done, like turn a bunch of already-available data into nifty little graphs? And he stated the following quote which, as far as I can tell, MEANS ABSOLUTELY FUCKING NOTHING:

"[Applications will] change to rich interactions away from binary or COBOL ways of interaction." - Vivek Kundra

Kundra: http://www.youtube.com/watch?v=9HZ-BESVVck

False positive from a DLL? That is nothing ...

How about TrendMicro giving a false positive on a valid PHP plain text file that is part of Drupal!

... find a way to contribute some small portion of their profits to The Apache Software Foundation?

Or any number of PHP- and Linux-related organizations?

Or Drupal?

That just seems to be the right thing to do, is all.

The site is running Apache on Red Hat Enterprise Linux 5, and it looks like Drupal running on PHP. What more do you want?

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

There's actually a really good reason for this - until fairly recently, there was no clear-cut way to make a wiki using Drupal. Wikitools only recently came out of beta - if it works as well as advertised, it would be a good one-stop solution.

Alternatively, you can patch one together using Pathauto, Diff (note, it's in alpha), Token, and a few others. In many respects, working with Drupal kind of reminds me of working with *nix - it can do some neat stuff on its own, but if you really want it to do anything particularly fun or useful, you're going to have to string together a series of "modules" that each do, you hope, one thing and one thing well. If you're really clever, you can do some really impressive stuff this way, especially if you know what you're doing with Views and the CCK. However, it's not exactly "user-friendly", in that you have to know precisely what you want to do and, just as importantly, precisely which tools you plan on using to make what you want to do a reality.

There's actually a really good reason for this - until fairly recently, there was no clear-cut way to make a wiki using Drupal. Wikitools only recently came out of beta - if it works as well as advertised, it would be a good one-stop solution.

Alternatively, you can patch one together using Pathauto, Diff (note, it's in alpha), Token, and a few others. In many respects, working with Drupal kind of reminds me of working with *nix - it can do some neat stuff on its own, but if you really want it to do anything particularly fun or useful, you're going to have to string together a series of "modules" that each do, you hope, one thing and one thing well. If you're really clever, you can do some really impressive stuff this way, especially if you know what you're doing with Views and the CCK. However, it's not exactly "user-friendly", in that you have to know precisely what you want to do and, just as importantly, precisely which tools you plan on using to make what you want to do a reality.

There's actually a really good reason for this - until fairly recently, there was no clear-cut way to make a wiki using Drupal. Wikitools only recently came out of beta - if it works as well as advertised, it would be a good one-stop solution.

Alternatively, you can patch one together using Pathauto, Diff (note, it's in alpha), Token, and a few others. In many respects, working with Drupal kind of reminds me of working with *nix - it can do some neat stuff on its own, but if you really want it to do anything particularly fun or useful, you're going to have to string together a series of "modules" that each do, you hope, one thing and one thing well. If you're really clever, you can do some really impressive stuff this way, especially if you know what you're doing with Views and the CCK. However, it's not exactly "user-friendly", in that you have to know precisely what you want to do and, just as importantly, precisely which tools you plan on using to make what you want to do a reality.

There's actually a really good reason for this - until fairly recently, there was no clear-cut way to make a wiki using Drupal. Wikitools only recently came out of beta - if it works as well as advertised, it would be a good one-stop solution.

Alternatively, you can patch one together using Pathauto, Diff (note, it's in alpha), Token, and a few others. In many respects, working with Drupal kind of reminds me of working with *nix - it can do some neat stuff on its own, but if you really want it to do anything particularly fun or useful, you're going to have to string together a series of "modules" that each do, you hope, one thing and one thing well. If you're really clever, you can do some really impressive stuff this way, especially if you know what you're doing with Views and the CCK. However, it's not exactly "user-friendly", in that you have to know precisely what you want to do and, just as importantly, precisely which tools you plan on using to make what you want to do a reality.

How about Drupal + this module: http://drupal.org/project/civicrm

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

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

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

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

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

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

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

Sure, greater productivity is one benefit, but the language is completely irrelevant for that.

It's about how flexible the system will be when you have to change it. And you will -- that's the whole point of software, that it is soft, and changeable.

Old Cobol apps generally are not flexible. (stolen from this comment). It's worth mentioning that a decent object-oriented system would've gone a long way towards eliminating this problem -- any idiot can stuff a date into a Date class, which then encapsulates all the date-handling code.

Maybe some of it is very well designed. Drupal proves that you can write good, elegant code in any language, even if you are fighting the language and reinventing the wheel every step of the way. But the converse is also true -- you can write bad COBOL in any language.

My point here is that when changing minimum wage is even a tech story at all, that program is really fucking broken*. It's very likely too broken to be patched. Really, we've learned things in the past 50 years, and not all of them are buzzwords or ways to waste five times the RAM.

Not all of them have anything to do with programming languages, either, but if you're building a new system, and you have a choice of languages, why would you choose COBOL?

I agree in spirit. But what people have to remember is, if it ain't broke, don't fix it. So, if it's broke, fix it!

* I apologize for the profanity, but any program that can't change a fucking constant is a broken program. Or did they copy/paste 6.55 all over the place?

Ha!

Looks like the userpoints system that I wrote for Drupal. Also has a plethora of contributed modules that integrates with lots of stuff.

Can be used as a site currency, reputation system, motivation for participation and much more.

Ha!

Looks like the userpoints system that I wrote for Drupal. Also has a plethora of contributed modules that integrates with lots of stuff.

Can be used as a site currency, reputation system, motivation for participation and much more.

There are plenty of examples of web services running on Open Source for 'enterprise' use - groupware, CRM, accounting, the works. Some of these packages are very good.

Its hard to be specific/determine what you're trying to do without knowing more specifics as to what you're looking for. Of the groupware projects I'm aware of, I know the following have a fair amount of support/use:

* Plone CMS
* OBM
* eGroupWare
* Drupal
* Typo3

Of these, I know that Plone, Drupal, and Typo3 are all "platforms" for developing, managing, and extending content. I seem to recall either eGroupWare or OpenGroupWare extend/integrate with MS Office products. No, it's not going to be the level of integration that Sharepoint stuff offers, but it's something to mention, at any rate (and isn't going to have the massive licensing costs + perpetual lock-in that a MS solution has*).

Plone, in particular, has a lot of support and corporate/"enterprise" use. From their site:

Plone is among the top 2% of all open source projects worldwide, with 200 core developers and more than 300 solution providers in 57 countries. The project has been actively developed since 2001, is available in more than 40 languages, and has the best security track record of any major CMS.
It is owned by the Plone Foundation, a 501(c)(3) not-for-profit organization, and is available for all major operating systems.
Sources: CVE and Ohloh.

That alone is impressive enough; but also consider some of the notable companies which utilize Plone in/for a variety of purposes:

Akamai (yeah, that Akamai - the guys who load balance Microsoft web servers)

Nokia (QT Software stuff)

MyCity ("real time monitoring system for Cities, Towns, Districts or utilities. It makes use of the GPRS service offered by the various GSM network operators")

Discover Magazine

Novell, Inc. (for enterprise services)

NASAScience (public site for NASA's Science Mission Directorate)

FSF (yeah, those hippies)

universities, university science/it departments, hospitals, public/government sites... the list goes on.

Those are notable company names, and at least in the case of Akamai, Novell and Nokia, everyone in IT should know about them. They're also some fairly diverse (and expansive) implementations using the same central CMS - and they're not shackled to a single software backend, able to run on any OS and server combination they could imagine.

* The cost factor associated with MS solution lock-in is a big consideration, bigger than just a simple argument of something like "OpenOffice vs. MS Office". With a web-based, top-level technology like this, it's much, much more important to keep the technologies used "open" - because it is the top-level interface to all your data. You can not move away from a closed package on the backend without moving the entire system, at once, to something open (more often than not, with MS). You're basically stuck with that stack unless you want to start over; there's no ability to independently consider parts of the stack and replace them, as there often is with open systems.

Whether you use WebSphere from IBM or Sharepoint from Microsoft, you have the ability to leverage an API and develop a custom solution around something that has a few things.

1. A community.
2. Documentation
3. Support

Now I am all for open source in an environment that deems it important, but having an SLA for a solution that is now going to become your intra/extranet is important -- and Drupal doesn't provide that. Sharepoint does, and so does Websphere.

All these things are available for open source solutions as well. If you don't think the Drupal community is adequate, there are companies that provide managed Drupal solutions and support. If you need an SLA, you can get one. If you need design or implementation services, they are available from a growing list of consulting firms. Drupal's code is open and documented, and if you can't read code, there are plenty of books. We handle our own Drupal projects internally, but not because we have to. There are many options.

Whether you use WebSphere from IBM or Sharepoint from Microsoft, you have the ability to leverage an API and develop a custom solution around something that has a few things.

1. A community.
2. Documentation
3. Support

Now I am all for open source in an environment that deems it important, but having an SLA for a solution that is now going to become your intra/extranet is important -- and Drupal doesn't provide that. Sharepoint does, and so does Websphere.

All these things are available for open source solutions as well. If you don't think the Drupal community is adequate, there are companies that provide managed Drupal solutions and support. If you need an SLA, you can get one. If you need design or implementation services, they are available from a growing list of consulting firms. Drupal's code is open and documented, and if you can't read code, there are plenty of books. We handle our own Drupal projects internally, but not because we have to. There are many options.

Whether you use WebSphere from IBM or Sharepoint from Microsoft, you have the ability to leverage an API and develop a custom solution around something that has a few things.

1. A community.
2. Documentation
3. Support

Now I am all for open source in an environment that deems it important, but having an SLA for a solution that is now going to become your intra/extranet is important -- and Drupal doesn't provide that. Sharepoint does, and so does Websphere.

All these things are available for open source solutions as well. If you don't think the Drupal community is adequate, there are companies that provide managed Drupal solutions and support. If you need an SLA, you can get one. If you need design or implementation services, they are available from a growing list of consulting firms. Drupal's code is open and documented, and if you can't read code, there are plenty of books. We handle our own Drupal projects internally, but not because we have to. There are many options.