10 Drupal Modules You Can't Live Without
Via my contact form, someone asked me to list 5 or 10 of the best drupal add ons. I decided to move away from "best", and rather decided to move to "can't live without". Or to put it differently, without these 10 modules, your experience with the minimial base install of drupal is likely to suck. (in spite of my physics teacher I once had who insisted that nothing sucked, but rather blew...).
Anyhow, this list isn't really ordered in any fashion other than the order that I think of ten "can't live without modules". Now -- there are many modules that have dropped my jaw that I haven't included. But that is still because I can still live without the majority of those modules.
10 DRUPAL MODULES THAT WILL KILL YOU IN YOUR SLEEP IF YOU DON'T INSTALL THEM NOW
1. TinyMCE WYSIWYG EDITOR -- Sometimes, we geeks forget that it is we who are the freaks. Most people don't know how to code an image, link, paragraph, unordered list, much less understand how image alignments work. TinyMCE, the only WYSIWYG editor that really works for drupal, opens up the world of webpublishing to this 98.9 percent of the population. Anyone who thinks that visitors who can't code an <a href=""> link aren't worth their time are both stupid, and will likely die cold, broke, and alone.
2. Feedback -- Its a simple module, sure. But every site needs it, and drupal doesn't include it. Sure, not everyone wants a contact form. However, most of those people, I'd argue should stick to blogger and myspace.com. Drupal -- being best suited for serious endevours and serious people needs a freakin' contact form.
3. Blockbar -- A totally underrated module, imho. What does block bar do? It makes all that crap that overwhelms first time drupal users disappear. Its now part of my personal toolkit that I implement on every install. Its role: make drupal friendly to non-cyborg types (e.g. those who haven't worked themselves to death to the point that this entry is their saturday night... wooohooo...)
4. Control Panel -- You know, I bet a few drupal veterns are going to scoff at this mention. However, remember cyborgs: not everyone is a cyborg. The best UI is always going to seek to remind users of soemthing they probably used before (::cough:: control panels on windows, and Mac -- seeing as how they are on the internet, I think its a pretty safe bet they are familiar.) And no, CYGWIN is not a good poster child for "good user interface" (though CYGWIN saves me, an ubercyborg freak hours upon hours every day).
Plain and simple, humans are monkeys -- and monkeys have an easier time navigating in visually rich enviroments, as opposed to enviroments inspired by manilla folders, and tax forms. So, monkeys: pictures good, text and white bad. Use control panels widely in your site, and you'll be amazed how many more people suddenly figure out how to use drupal.
Seriously. Anyone who disagrees on this point can shutup. They are wrong. I'd tell them they were wrong and that they should shutup again if I could.(wait, I just did)
Relax, Control Panels has the most dirt-plain simple API every for adding your own Icons to your own themes. Truly, its worth the download (or an include, or a rewrite then include -- echm, CS).
5. Printer Friendly Pages -- Cyborgs be damned, a large portion of the population "surfs" the web like this:
- they find they info they are looking for
- they print it out and often file it in a folder if they need it later.
Yes, you could tell these folks to "get with it". However, you'd be a fool to do so. You may want to check up on the relationships between internet access, age, and wealth if you think I'm bluffing, partner. Oh, and this module not only generates very printer friendly pages, but it also parses out your links, and lists them as foot notes on the bottom of the page.
6. Bad Behavior -- Because comment, trackback, malicious scripts, and bad bots will hit your site everyday. This module + 3rd party free libraries of scripts -- imho -- is usually all a medium level traffic site needs to withstand the internet's disgusting onslaught. Of course to be perfectly honest, this script no longer works at my site. However, this being one of 20 drupal sites I've been building, updatingng, or fixing is alright. I'd take a 1/20 percent chance of having to moderate comments if I were you. Its better than trying to delete 3000 spams from 200 nodes when you don't know a lick of MySQL.
7. Simplenews -- An email newsletter management module. It includes easy import/export of subscribers, lets non UID members unsubscribe and subscribe and manages all that info, gives you all the must-have-info on what's happening with your mail blasts, and well -- f#cking a' man -- since enewsletter stopped working about 2 months ago, its really the only good module that I'd trust to a non-cyborg for managing such an uberimport task!
8. Views -- its new, and changing everything.
9. CCK -- going to be hella disruptive to drupal at large. HELL-A hardcore, disruptive, even.
10. CiviCRM -- for god's sake could they get it compatible with 4.7?! Regardless of 4.7's beta status, I have to develop on 4.7 to prevent from screwing people over with obsolete code. I've tried to update it, but its beyond my PHP understanding.
CiviCRM is maybe the only module I know of that could create an industry of consultants all by itself. Moreover, the people who run the project are -- as far as I know -- the most responsive team in the entire industry. If you mention them anywhere on the public internet, you can rest assured they will hear you in 2-5 hours. This is one module, like CCK and Views that has the potential to change everything. That is, when they get it to be compatible with the non-obsolete-developing-for-it-is-a-total-waste-of-time-and-money version of drupal. ;-) O! -- screw Joomla!, get CiviCRM to work with forms API and the world will be shared by we, the open source community forever!
Or, at the very least, it would be really cool*.
*as the kids say.
indeed, my attempts at adding user-reference and node-reference
indeed, my attempts at adding user-reference and node-reference fieldso to nodes made a clear argument that CCK is still in a young and rambunctious phase. It was released what -- 5 days ago?! And though views is stable enough, it is indeed likely to change dramatically as more and more people realize its power, and its tested against the reality (the great destroyer of any programmers 'plans'). Of course you already know this. :-)
In so far as controlpanel is concerned, I agree that it would be lousy thing to add to the core. Right now, I'm singing high praises for it because it gives me an easy API to make drupal's hundreds of menu items monkey friendly. If anything, I think controlpanel is more powerful theming tool than it is a standalone module.
If there was one change I would make to the core it would be this: menus lack a lot of key data for CSS and AJAX -- however, menus are big spenders of resources as it is... what I think would be really helpful is there was a function that asked menu items a simple question: "From where, oh where did you come from?!" The answer could be as simple as returning the module's hook. I know that somewhere in the core,some function knows the node link "(username)'s Blog" was generated from the blog module -- however, I have yet to find a way to get an agreeable answer from the core about this. In order to generate dynamic classes so that I could add nice little icons to every $var[node]->links item in node.tpl.php, I still have to resort to using crazy preg functions, parsing out the retunred values, and then making them CSS friendly.
The control panel module, in a way is great crutch to solve the obvious problems with a preg solution when it comes to admin items. Yet, really, all I want is <li class="leaf"><a href="node/add/blog" class="node-blog-add" />... if I had that, I could reproduce control panels entirely via theme. Its really quite simple... it just would require onegeneral css rule, and a background-image:url() statement for each .menu li a.class.
This would be too much extra overhead to return by default, but I think merely making it available would cause a drupal UI renaissance. Especially when one considers how many ajax libraries execute actions on the basis of element classes and ids.
But I'm a mere idea hampster whose overworked, and needs to start making more time to help fix bugs beforeI start leaving comments in a suggestion box... just keep doing what you do!
且将新火试新茶 诗酒趁年华
Well I think the number "10"
Well I think the number "10" connotes that these choices were somewhat arbitrary.
FYI, I'm striking feedback from the list shortly, as Earl Miles rightly pointed out that the 4.7 core now takes care of this function -- and upon investigation, indeed does so in a superior way.
And you are correct about how the types of sites I'm building these days would sway my opinion. But, I think its the feedback on drupal from the many people I've been working with that is perhaps the biggest factor that influenced my choices.
TinyMCE, I feel is like that old cliche about democracy -- its the worst path to take, accept for the alternatives.
Stuff you may not be aware of: 4.7 TinyMCE provides compression that has greatly reduced load times and overhead. It also lets you select buttons and plugins one by one. Also, the recently released version of TinyMCE, v. 2.02, is a noticable improvement on 2.01 (which we'd be using for the past 5 months or so, I believe...). And, Safari is really the only browser that I'm aware of that has difficulties with TinyMCE. And I confess I don't spend much time worrying about explorer 5, ancient versions of netscape, or resolving javascript problems with Safari. Why? Because it affects maybe 4% of visitors, and doubles the time it takes to get a site up that meets the requirements.
Its a cost/benefit thing... I think aiming for universal browser support for "web 2.0" is kind of ike communism. Its inefficent, a good idea that really sucks in practice, and it reduces the overall quality of the site. Why do I say that? Simple, when you're going back and forth between IE5.5, Safari, Firefox, and Explorer, toiling at hacks, experiementing and pulling your hair out you are spending time. And at least in my book, time is everything: its cost, sanity and opprotunity.
The choice on controlpanels came from an observation: I was working with folks who still had trouble navigating through the admin menu after working with drupal for many months. In all cases, control panel solved their mental block in understanding how the different parts fit together, and where the settings they were looking for would most likely be found. Lately, myself have perferred the controlpanel view+blockbar to expand and contract the menu at any point of the site.
3. True: a greyscale fixed width site that looks good on a printer by default doesn't need a printer friendly version. Rather it needs a new design -- perhaps with some color. Also, as soon as you add a hyperlink to a page, I think providing a printer friendly version is a thoughtful move.Really, I can never think of reason NOT to help visitors read a sites content on their own terms.
+++
That said, your last paragraph is dead on. Context is everything to those who are learning -- thanks for the feedback.
once again assumptions are made
Once again people making broad unqualified statments to their specific needs without mentioning the context of their use. While I realize I am not an uber web developer your choices obviously carry assumptions about your market segment and types of sites you develop for :). TinyMCE for it's vanted GUI'ness is not necessary for many sites with a small group of people producing content and various browser issues have been frustrating in the extreme adding to annoying support overhead. This is why I stopped using it completely and removed it from all the sites I've done.
I would have added image, xstatistics, browsini and PHPTemplate. :)
Your assumption that only serious people need feedback is interesting. None of the folks I've setup sites for are interested in a 'feedback' form. They rely on people who visit their actual store. For the personal sites I've setup for folks, again their audience is people they know, not 'feedback' from strangers so MySpace and blogger are not good answers.
Blockbar is new for 4.7. Looks very nice. Not having deployed sites on 4.7 yet but have tried it I am unsure how other than general 'coolness' I will use it much less how 'pretecting' people from their sites admin function accomplishes this. Perhaps rather then a listing of modules a specific set of stragtegies to impliment modules in unexpected ways?
Control Panel is interesting but I think the simplicity of our current interface is overlooked. I will probably look at it again when I am upgrading my sites to 4.7 and will freely admit to not having had time to look at it recently.
Printer Friendly pages, again assume you are making sites that will need printer friendly content. If you have the old fixed width site that is sized to fit on a printed page then again, not needed. :)
CivicCRM is powerful. It is also very very complex and in many many cases completely uneccessary for a huge segment of site builders. Unless of course you run those types of sites. I doubt many many people even have the vocabulary to begin to understand what CivicCRM can do for them. I know I don't at this point.
Simplenews, awesome if you are running a newsletter (which I am on one site). Bad behavior, I'll take your word on it. For others not used to Drupal development, Views and cck are the breakthroughs of 4.7. Depending on how they evolve we'll see if any and what features evolve to join core 4.8. :) I'm still learning how to use them myself.
Perhaps you could elaborate on the types of sites you develop for and how these modules render themselves essential for you and your needs? As the first comment indicates, 10 essential modules heavily depends on perspective , types of sites you are building and audience that will be maintaining and using it. I would have mentioned image module myself. :)
Yeah -- let me backup... its
Yeah -- let me backup... its not so much that drupal sucks without certain modules, as a large number of the population will need them to be impressed by drupal, or to find drupal usable.
These modules aren't part of the base install because the core maintainers have enough on their hands as is. I wouldn't be suprised to CCk, or Views integrated eventually into the core, however.
In so far as taxonomy_access, and flexinode... I think CCK really takes over a lot of that. Plus, taxonomy_access can get pretty hairy to manage on sites with lots of vocabs and roles. I'd almost perfer path access.