on drupal, part one
If you want the basics on Drupal, you could do no better than to spend some time combing through the project’s website. Actually, scratch that, the one thing you could do better than combing through the website would be to grab the software, install it, and mess around with it for a bit. It’s easy to use, robust, and super-highly configurable. Once installed, it’s pretty easy to get a feel for the software (especially if you have some familiarity with CMSes, even simple ones like WordPress), so I’m not going to spend any time on the basics. Instead, I figured I’d jump right into how it worked (and how I forced it to work) for me. As I’ve mentioned more than once over the past few weeks, I built my library’s redesigned website on Drupal and I have more than a few things to say about the experience, so I thought I’d piece it out into a series of posts. First up, let’s talk modules.
Drupal modules are little (and no-so-little) add-ons that extend the functionality of the CMS. You could happily run a solid website with Drupal’s vanilla install without a single additional module (which I’ve done), but my guess is that if you’re building even a moderately complex website, you’re going to want to explore your module options. When I first started exploring those options a few months ago, I found myself going down an all-familiar path when it comes to new tech: so many cool bells! such pretty whistles! I want it all! But wait? Which of these do I really need? Here’s what I’d recommend: sit down and make a wishlist of everything you want your site to do, in terms of functionality. At first you’re going to want to blue sky it (think everything is possible!) because you’ll have plenty of time later to cull and prioritize that list. Once you’ve got your wishlist firmly in hand, you’ll be ready to turn to that list of modules and figure out which ones will get you there.
When I hit the “which of these do I really need?” stage of module selection, I turned to other library drupalers to help me out. I figured that if another library had used a specific module on their site, I could probably use it on ours. The drupal4lib listserv was especially helpful here, but apart from that, I found little online documentation on what other library drupal sites had used. In the interest of filling that gap just a little, here’s a complete list of all the modules we’re using on our site:
- Active Menu
- Captcha
- Collapse Text
- Collapsiblock
- Comment Mail
- Contemplate
- Content Construction Kit (CCK)
- Custom Breadcrumbs
- Aggregator
- Comment
- Devel
- Devel Node Access
- Elements
- Event
- External Links
- Faceted Search
- FCKEditor
- Frequently Asked Questions
- Google Co-op CSE
- Heading Anchors
- Help
- Iconizer
- ImageCache
- IMCE
- Insert View
- JavaScript Tools
- jQuery Update
- Lightbox2
- Links
- NeighborForge
- Menu
- Nice Menus
- Node Field Indexer
- Node Import
- Panels
- Path
- Pathauto
- Poll
- Profile
- Search
- Search404
- Service Links
- Statistics
- Table of Contents
- Tabs Example
- Taxonomy
- Upload
- Views
- Webform
- XML Sitemap
Yes, that’s a lot of modules, but that list is actually relatively short compared to what it could be (there are thousands of modules out there, folks). Next up: more module-goodness, specifically CCK!
Update: continue to on drupal, part two
4 Comments