Module List Review

Hi John. I'm taking a look at the list and will send you an email.

Acquia (the commercially supported Drupal company founded by Dries Buytaert) offers a sort-of certified Drupal package that contains a number of community contrib modules, some of which are on UDel list. The full Acquia list can be found here:

http://acquia.com/products-services/acquia-drupal-modules

-Larry

John,

Looks like you've got a great start on putting together a module list for your people. I've included my thoughts on them in my comment here. Any I've omitted means I didn't have much to say about the module positive or negative. One of the things to remember is that modules can change a lot between even minor versions, depending on the maintainer. I continue to find that choosing the right module is a case-by-case decision based on requirements, technical skill of the users, time allowed, and so on.

My apologies for how long this ended up being.

Core Modules

• Aggregator -- Good for what it does, pretty basic. FeedAPI is a good place to look if you want to import feeds as nodes, etc
• Contact -- Basic contact forms. WebForm is actually great for more advanced contact forms.
• Path -- Great for pretty/SEO URLs.
• Profile -- Basic profile functionality. Node-based profile stuff is more powerful but more complicated.
• Search -- Decent search engine. Usually good enough.
• Taxonomy -- Can be used for more than just tags and categories. Mixed with the right modules, taxonomy can become the basis for permissions and more. Always consider if taxonomy can be your ally when figuring out how to implement a feature.
• Update Status -- Great for making sure your site is up-to-date. I recommend having it on (though maybe not during dev -- can get a tad annoying on occasion).
• Upload -- Basis for a lot of other modules that implement upload abilities, so it ends up being enabled a lot.

Content Editing

• CCK -- A must for anything more than the most basic of basic sites.
• FileField -- THE module for associating files with nodes.
• Checkout -- Good for what it does and if it fits your site's workflow and user culture/procedure.
• Workflow -- Decent module. Has suffered from the occasional instability, but modern releases are much better. I end up using workflow regularly. Is most useful when combined with other modules that integrate with it.
• Mollom/Akismet -- Mollom and Akismet both get the job done. Mollom is more Drupally-correct and is more likely to be well-supported moving forward.
• TinyMCE/FCK -- If you ask 5 developers about this, you're likely to get 6 opinions. They both work -- at varying degrees at varying releases, it would seem. In D6, I've found more success with WYSIWYG API combined with TinyMCE. I recommend keeping the tool palettes as light as possible.

User Interaction, Rich Media, etc...

• Image/ImageField -- Both good at what they do, but not always good together. For each site, it's good to figure out which will fit your needs ahead of time. Neither seems to satisfy all needs, but the good news is Aaron Winborn assures us that they are moving closer together. :)
• ImageCache -- I love this module, use it regularly.
• Embedded Media Field -- Easy way to get third-party rich media into your site with minimal overhead. Good quality, well-maintained, and has potential for custom integrations.

File System

• IMCE -- another one that's good at what it does. Don't expect to do document management with IMCE, though. It's most useful used with TinyMCE and used to upload images for use in a post (and sometimes documents). If you're using Image/ImageAttach and the like, IMCE might make less sense. Otherwise, very configurable and nice when it fits the job.

SEO

• Pathauto -- Personally, I love pathauto; however, I've heard stories of pathauto confusing people badly.
• XML Sitemap -- Love this module. Has helped me make many sites get better hits from Google. Be familiar with Google's webmaster tools.
• Google Analytics -- If you like numbers and graphs, this is a great way to go. Can interfere with some JS-related things that that try to add click events to links to pop up modal dialogues and whatnot, so if you run into problems, know your usual suspects.

Navigation, Menus, Organization

• Views -- I love views. Views are even tastier, IMO, when you export them to code as default views (great for change management). Views 2 has some great capabilities and I even enjoy the API a little more than Views 1.
• Webform -- Great for contact forms, surveys, and the like. Well-maintained, active module. Good module to investigate and become familiar with so it's in your toolbox when solving an issue related to forms somehow.
• Token -- Good module that a lot of other modules integrate with. Will be a dependency of other modules.
• Nice Menus -- Probably the better solution for drop-down/over menus for Drupal, but can be challenging to get it to work the way the client wants at times. I often find myself overriding nice menu's theme functions to suit my needs -- but this saves a TON of time over implementing its features myself.

Administration, Authentication

• admin_menu -- First menu that gets installed on any site I work on. Always.
• Many of the .edu Drupal (and otherwise) implementations I've done involved some sort of identity federation, shared authentication, and/or single-signon. In many cases, I've made ldap_integration meet my needs, though we've also found ourselves writing custom modules to integrate with schools' existing auth mechanisms. I just wanted to put that on your radar.

Date/Place

• Location -- Great for associating location information with nodes and people. Well-maintained and keeps getting better. Good for providing google maps integration when combined with other modules.
• Date/Calendar -- I use these modules so very heavily. Nearly out-of-the-box calendar/event functionality. Time Zone stuff that Date module does is very nice. Maintained well.

Access Modules
NOTE: Using multiple access modules can sometimes (many times?) lead to unexpected behavior, so beware. I usually try to find a single access module that can be made to fit the needs of the site. I have a lot of success using Organic Groups with its included og_access module to control access to content based on group membership. OG is a module that should be on your list of modules to become familiar with. Also for access in D6, TAC Lite is worth a look.

Communication, Users

• Notifications -- I use it a lot, but users often complain about it being confusing. One of these days I'll contribute a module that exposes a more limited but more simple interface to this module. One of the better/best options for getting notifications, though.
• Five Star -- Great module. I use it any time we need to rate something. Great views integration via votingapi.

Style, Layout

• Contemplate -- I always do my layout with either a custom template or Panels. Certainly not a bad module, but you'll want to evaluate how you want your presentation code edited, stored, etc.
• Panels -- Great module from merlinofchaos. I haven't used the D6 alpha yet, but the D5 version saved me a lot of time over generating layouts manually. I also like the ability to export panels as default panels in code, much like views.
• GeSHi Filter -- This is what I use for code highlighting on my blog. Gets the job done reasonably well -- some odd issues with css, but nothing insurmountable. I haven't used the D6 version.

--
Josh Benner
http://jbenner.net

Rock River Star, LLP

That's a lot of modules you plan to support! As a fellow .edu support person I'd be seriously worried...
I suggest you carefully read through the excellent comments above, prioritize accordingly, and then pare down your list. Between CCK and friends, Views2, and Taxonomy you can get so much done, you often don't need the module which bears the name of your desired functionality.

More than I hoped for. I appreciate the time and thought you put into the response. It does look like we're on the same page in most cases. I'll do my best to respond to everything below...

I like the idea of using smaller, modular, reusable components where possible. CCK with Views and a few other modules can do quite a lot. I would rather go this route than larger, all-in-one packages, or simpler packages that focus on one task. For example, the Video Filter module make sit very easy to embed video from YouTube and similar sites. I would prefer to use the Embedded Media field in CCK and jQuery Media modules. This would require more training for our users (many of which will be faculty or staff with little to no web development experience) but it would be knowledge they can use for other enhancements to their sites.

I totally agree about the Image module. I would much rather use ImageField, Image Cache, etc..., and I'm now convinced that's where we (UD) should move as an organization.

Note that I'm not sure how much access our clients are going to have to the file system. We're still working that out. One of the reasons I have Panels, Contemplate, Front Page, PHP filter, etc.. in there is because users may not be able to create their own or edit .tpl.php or the template.php files. One thought is to give each site full access to their own themes folder. Modules will probably be in sites/all and user will NOT be able to edit these files.

I totally agree about not going WYSIWYG and I am pushing for things like BUEditor and Markdown. However, it depends how much of a demand there is for WYSIWYG. Personally, I like TinyMCE but FCKEditor is in use elsewhere on campus. Maybe we offer all three and each site admin can enable what they want. Of course, this will make support and module maintenance tougher than it should!

For backups, I probably shouldn't even list that here. Database and file system backups will be done on the server administration end. probably best not to leave that up to individual site owners! (For my own sites I use DB_maintenance or Backup and Migrate simply because of the file system component. Although it does have some more dependencies.)

I am surprised to hear that SimpleNews may not be good for large mailings. That could be an issue. It such a popular module. I haven't used it though on any sites that had significant membership.

Thanks for the thought on using Mollum, et al, instead of CAPTCHA. For some reason, I had thought they worked together. Do these other services slow down your sites????

I agree the FeedAPI is better (more flexible) than the default Aggregater. However, Aggregater had done well for what I've needed. It's going to depend on what our client needs are here. I need to look more into the FeedAPI. For some reason, I'm still hesitant to create node for every feed item. Doesn't that fill up your db needlessly? Wouldn't having thousands of extra nodes slow down your queries, or put items in your search results you don't want there????

For searching individual sites, we're still debating whether to use the default Drupal search, maybe integrate Apache Solr, or just use our new Google Search Appliance crawl our entire network of sites. Right now, using the GSA is where we're leaning.

Thanks for the suggestion of vertical tabs, popups, and a few others.

For SEO modules, I understand when you say Page Title and Nodewords may not be necessary. If we give each site their own theme, so they can customize the .tpl.php files, then Nodewords probably wouldn't be necessary. If not, then we'll need it.

I definitely agree with Bill that D6 is where media gets polished. Well, I would say D6 is where the ideas come out, development pops up everywhere, we determine which technologies here work best with the rest of our non-media sites, but D7 is where the polishing gets done. This is tough but I'm going where CCK is used and away from from the all-in-one packages, or the default packages like Image/Image Gallery.

John

I should also mention that I see Organic Groups being active at UD. Great set of modules. Student organizations, technical user groups, IT support sites, advisory committees, etc.. all could benefit Organic Groups. However, this won't be included in our hosted services to start. I'd encourage colleges/depts on campus running their own Drupal installs to consider OG. As well, we're so new to Drupal as an organization, I'd like to get our feet wet before we use OG. It was a bit tricky for me to setup and do what I want. I plan to revisit OG this summer for a user group site I'm doing.

For some collaboration sites, I've had requests for document management capabilities. It's common for users to share and collaborate on Word docs, spreadsheets, etc.... I'd encouraged others to use web pages as their documents, then Drupal is a great DMS! Even Google spreadsheets help here. Or course, that doesn't work and people want to share their Word docs. Maybe because we have a few Sharepoint installations floating around here... ;( Something for the future (maybe near future) to consider. From the reviews, KnowledgeTree and Alfresco with Drupal look good. When we get to this will depend on client needs, of course.

You need this module. It will remove lots of headaches when it comes to making sure that crontabs are executed.

Also, be advised that under heavy load conditions, you can get multiple instances of it running, which is Very Bad. There are patches for this, though.

Wow! I love it! Thanks Jody for bringing Mollum to my attention.