A newbie's guide to contributed Drupal modules
Back in the day (only 18 months ago in fact), whenever I started a new Drupal project I would read through the entire modules list and download each module I thought could be useful for the website I was developing. Once the contributed modules grew to such an extent that it would take me half a day to read through the entire list, my method to become acquainted with the current state of modules became prohibitive. Today, it would likely take several days to read through the entire list of available modules, and it would overload anyone’s brain to process the sheer quantity of information and inspired ideas of relationships between modules.
Since I have such a strong background in the history of many modules, my current method is to keep abreast of Drupal news and new modules. Since Drupal is so tied to my financial success, I have many RSS feeds that I read every day so I have a general idea of what is going on in Drupal’s world and how people are using the available modules.
But what is the Drupal newbie to do? At the time of this writing there are 4,129 modules for Drupal 5 (when I first wrote this guide for trainees 14 months ago, there were only 1002!). Someone just sitting down to Drupal may become too overwhelmed trying to peruse through available modules. Although it is divided into sections, some sections are huge with 150-400 modules in them. On top of that, some sections are module specific and a reader won’t get to the main module that section was built for until after they have read through a few modules that simply do not make sense without understanding the core module.
“CCK,” a newbie will think, “What the heck is CCK?” They’ll click on the section and start browsing, “Hmm.. Addresses, Audio Recording Field, Block Reference, Block submitting twice, CCK blocks… But what is CCK? What is this about?”
For you, Drupal newbie, here is a guide to some Drupal modules that will help you move forward in becoming a Drupal website developer.
Note: This is in no way a comprehensive guide to all modules. This is merely a snapshot of my perspective of the Drupal world. However, feel free to comment about your thoughts for any Drupal newbies who may be reading.
Modules you can’t live without
Content Construction Kit (CCK)
Custom fields for content types
I can not imagine how any other CMS out there can function without a module like this. Since Drupal 5, it has been a core functionality to allow the flexible creation of content types (the original CCK provided this for Drupal 4.7). This module allows the flexible addition and manipulation of fields for a content type. Text fields, drop downs, options, numbers, dates, files, etc. A wide variety of fields can be added to your content types to associate data to each node.
Create events, biographies, portfolios, news articles, etc. The possibilities are endless. And you can do it all through a user friendly front end, with no programming experience necessary. Too. Cool. Barely a Drupal site these days can go into production without this module.
Flexible display of conent
This allows flexible display of nodes, and with the development of the Drupal 6 version, it allows the flexible display of almost anything - users, comments, etc. When combined with CCK, the two modules are a powerful force to contend with!
Nodes can be grouped, sorted and filtered by fields and/or any other attribute about a node and then displayed in a variety of styles and locations. A view can also be given arguments based on its path alias or passed in through the theme to allow one view to serve a vast multitude of displays to the visitor.
Automatically generate URI paths based on patterns
No one likes paths formatted like “node/234”, so pathauto comes to the rescue. For each content type, category and user, you can create a custom pattern for URI paths to take.
My blog entries, for example, are formatted to have the pattern
blog/[yyyy]/[mm]/[title]. When combined with views, the sub-paths can automatically be populated. This allows me to have ‘blog/2008’ contain only entries created in the year 2008, and ‘blog/2008/06’ will contain entries created in June. I do not create these manually, they are populated automatically by using views.
You can then also use the custom fields from CCK as part of the pattern for the path, then combine that with views and create an automatically categorized web site of awesome proportions!
Sadly, in this day and age, if you have any part of your site open for unapproved user input (even the contact form!), you need to put in protections against spam. I just recently learned this lesson when I opened up comments for this site last spring. I thought, “I just have a tiny little blog that no one has heard of. Even if the spammers heard of me, they likely won’t take the effort to clog my site, I’m sure I could handle what they throw at me.” I was wrong. Within 12 hours, while I slept, the spammers found this little blog and slammed the comments with spam. I was receiving more spam than was ever possible to moderate.
Mollom saves the day. It allows the possibility for real users to post and interact with the website without necessarily being forced to jump through hoops to prove they’re human. A submission is sent to Mollom’s servers and they evaluate if they think it is spammy or not (ham vs spam). If Mollom deems it spammy, they present the user a second chance to submit their form, while this time they have to prove they are human by solving a CAPTCHA.
I hate having to prove I am human, so I love that Mollom makes it possible to interact with the site without necessarily through through these extra steps. I am also one of those people who have difficulties with solving CAPTCHAs. I do not know why, I can check and double check and swear that my solution is correct, yet about 50% of the time my first attempt is wrong. I am all for avoiding CAPTCHAs at all costs, and Mollom allows me to do so.
Easier administration navigation
I find this is the handiest module in the whole of Drupal planet. I’m exaggerating of course, but of all the modules I listed here as modules you can not live without, this is always the first module I install. In fact, I have an “example” install of Drupal with default configuration settings (like date settings, clean URLs, etc), and this is the only contributed module in it.
This module makes administrative navigation of a Drupal website so much easier. Because of the huge amount of configuration pages scattered through the administration section, they have been grouped into sections like “Content Management”, “Site Building”, “Site Configuration”, etc. But if you have to switch from the “Site Configuration” section to the “Site Building” section then over to the “Content Management” section, that is a lot of absolutely needless page loads!
DHTML Menu reduces page loads by allowing you to open and close the navigation tree dynamically, making the switch from the “pathauto” configuration page in “Site Configuration” over to the “content types” configuration page in “Content Management” take a mere second.
Related Modules: Admin Menu
Modules that will change how you approach Drupal development
Performing an action based on a event
Behaviour, almost any behaviour you can think of, can be automatically fired based on an event. Publish or unpublish content, change attributes, modify users, etc. This has proven to be so useful that it was ported to core in the release of Drupal 6 as the trigger module. Creating custom actions is fairly simple, requiring only basic PHP skills.
Organic Groups (OG)
Creating arbitrary groups of users and content on the fly
The most obvious use is for social networking sites. Drupal Groups is a fine example of it. Users can create new groups, grow a membership, and have public or private content within their group.
It is also handy to create sections of a website as groups with different user access and permissions based on the section/group. Our company is currently developing a client website driven by the OG module where each project is a group, and clients are registered users. Clients are then members of a group where all the content is private. Overall, the capabilities of this module most certainly will change your direction and possibilities for developing a site.
Flexible display of content
I will be the first to admit that I did not understand the point of this module while I watched the Drupal community drool over it. I figured, “Anything that could be done in this module can be done through the site’s theme, so why bother?” However, what I missed was that everything this module does is through the web interface, allowing a bit of control of the theme layer by someone without FTP access to the site’s files. Or, simply, to allow some control of the theme layer without needing to know any code.
The great use here, then, is to allow a registered user with proper permissions to gather a collection of data (like views, nodes, blocks, etc) and display it nicely without ever touching theme code. Panels are context aware allowing it to know where it is within the site and changing its content based on its context. Since it is context aware out-of-the-box, it can be simpler to use panels than to write up all the necessary code within the site’s theme.
For the company client site, we plan to use panels as a group’s homepage, allowing our project manager (who is a non-coder) to change the homepage of a project on the fly. Each client, then, can have a project homepage optimized for them and quickly change when needed with minimal overhead.
Set a customized workflow for content
This is another one of those modules I have installed on almost all of my websites. It allows you to create an arbitrary workflow for content to move through. I use it to create a publishing workflow. On this website I have a “Draft, Ready to Publish, Publish” workflow. For news websites I create the workflow as “Draft, Ready to Review, Embargo, Publish.”
Each workflow state can also have access permissions. For “Draft” states, I configure it so only the author can read it, while for “Publish” it is available to the world. News websites likely don’t want the author to edit a story that is published, so I configure access control to prevent authors from editing content in the “Publish” state, and allow only a set “editor” role to modify published content.
Transitions from one workflow state to another can also act as a trigger for actions! I have created a custom action to change the “created date” of a node to the current time when a node first enters the “Publish” state. Another useful action to trigger would be an emailed notification to an editor when a news story has been moved to the “Ready to Review” state.
Transitions can also be scheduled. I have a “Ready to Publish” state so I can “stage” content to be published. News websites almost always do this, while I use it even on this website. I will frequently get a burst of inspiration to write a large amount of blog posts. Instead of publishing them all at once, I will stage them in the “Ready to Publish” state and have each entry publish automatically every few days.
Views can also be filtered and sorted by workflow state. I have a “Manage Content” view that contains all my “Drafts” and “Ready to Publish” content. All the other views, such as “Dev Blog” and “Web Sites” filter to display only content that is in the “Publish” state.
Prepopulate or ignore node titles
When you have enabled automatic node titles for a content type, the title field is hidden on the input form, and its stored data is populated with whatever you configure. Just as in the pathauto module, you can set a pattern to generate a title based on other entries submitted in the form. When coupled with CCK, entries for various fields could be used as part of the pattern.
For example, say you are creating biographies of people and you have two separate fields for first name and last name. The node title can be automatically populated with both the person’s first and last name, and then the last name will be exposed for sorting and grouping with views.
Additional access control for nodes
The default possible permissions of a role for the given content type foo are:
- Edit all
- Edit own
- Delete all (Drupal 6)
- Delete own (Drupal 6)
But sometimes you just need more. Content Access will allow you to fine tune access control to content types and individual nodes, even allowing you to add permissions to specific users in addition to user roles. It also exposes the delete permissions to Drupal 5. Extremely handy in some situations.
Highlight changes between revisions
If you enable revisions for a content type or during the modification of a node, you will end up with revisions. In core, your only choice is to see the whole display of the node for each revision, which is a bit prohibitive to notice that someone fixed a typo on one word when creating that new revision. The diff module will allow you to select two revisions and see a highlight of all changes made between them.
Images as nodes with automatic derivative resizing
This is effectively images as nodes, which is in contrast to using a CCK imagefield to upload an image. An image as a node would allow various extra capabilities, while an image as a CCK field would be limited to only being a file and nothing more.
When creating an image-as-node with the Image module, the original file is preserved and resized derivatives are automatically created with access control permissions for each of the derivatives. They can then be sorted, displayed and manipulated just as any other node can be. By default, a simple album grouping of the images is included which can be grown upon and expanded by other helper modules.
Manipulate images on the fly
This module allows you to create an image manipulation setting and apply it to any image as it is being presented to the user. It will create a copy of the original, and scale, resize and crop however you would like. The possibilities are endless.
Relate a location to a node
There are several modules that have this same ability to associate a place to a node. My recommendation is the Location module because the developer of this module is also developing several other mapping related modules encouraging greater interoperability.
Related Modules: GMap Module
Making mass user management a tad easier
If you have a lot of users, or instances where you need to register a bunch of users by hand at one time, this module will make your life easier. You can register, change roles and assign OG groups of multiple users simultaneously.
Modules to make inputting content easier
IMCE or Img Assist
Uploading images on the fly and inserting them into content
The Img Assist module hooks into the Image module, maintaining images-as-nodes. The IMCE module treats and maintains images as purely files and additionally allows non-image files to be uploaded. Each will resize images on the fly for insertion into content and give the user an image browser to sort through with access to images filtered through access control.
The Img Assist module has better support for adding captions and sorts images based on taxonomy, while IMCE is flexible enough to support non-image files and sorts files based on file directory.
When used with a WYSIWYG editor, a user can drag the image around text to place it where they want it to appear. The IMCE module will show a preview of the image, while Img Assist shows only the space it will take up.
A text based filter to add markup without HTML
This is my preferred non-WYSIWYG editor. It allows a user to markup their text using symbols instead of HTML. The text is cleaner and easier to read, while keeping it simple, straight forward and reduce the risk of malicious input. View Markdown’s synatx.
Graphical content editors
TinyMCE is one of the most popular and supported WYSIWYG editors for Drupal. Its interface is similar to Word making most clients a bit more comfortable with it. When configured correctly, what the user sees is very close to how it will be when displayed to a visitor.
WYMeditor contrasts with TinyMCE in that it exposes the underlining HTML markup in a graphical fashion. It shows the editor the blocks and HTML being used to markup their content while still visually demonstrating the flow the content is taking but in a raw simplified manner. Headers, paragraphs, lists, etc, are all rendered simply while in editing mode, leaving the display of the content to be handled by the theme when displayed to a visitor.
Both have configurable access control for which roles should have access to which widgets. Administrators could have all the bells and whistles, while another role could have just the ability to bold, italicise and make links.
Related Modules: FCKeditor
The WYSIWYG glue project for Drupal
This is mostly a heads up post, but keep looking at it every time you need to make a WYSIWYG choice to see its current status. We have a lot of WYSIWYG editor modules available for Drupal, one for each flavour out there. Preferences of which to pick are mostly based on user interface likes and dislikes.
That piece that links the WYSIWYG editor code to work with Drupal is getting repeated with each and every editor module. The goal of this project is to create one ‘glue’ module which will allow a person to use a variety of different editors without requiring repeated efforts for each. This will hopefully open the doors to supporting more editors.
Modules for search engine optimization (SEO)
Automatically 301 redirect content with multiple paths
Most web developers do not want all their URI paths to say “node/1234” and instead something more like, “blog/2008/title-of-my-blog-post” which can be easily done with Pathauto. However, despite the existence of a URL alias for that ugly URI (otherwise known as the system path), the original ugly URI still works. And if it gets out, a search engine can think it is duplicate content and rate it down. If you have a node for a homepage, that means you have three URIs all for the same content. Bad news all around for SEO.
This module prevents the search engine from thinking it is two or three different pages serving the same content by automatically figuring out what is the primary path, and redirecting all other paths. The system path will redirect to the path alias, and when the front page is a node the path alias will redirect to the front page.
The redirects are a 301 redirect which tells the search engine that the URI it was trying to reach was moved permanently. It will understand that the old path is not supposed to exist anymore and will apply any data it had for the old path to the new path. If you switch from using system paths to URL aliases, this module would assist you in ensuring your current standing with a search engine is not changed - if anything, it should be helped!
Meta Tags (nodewords)
Easily add content for meta tags
Meta tag descriptions allows a search engine to get a better understanding of how a human, the author, perceives and categorizes the page. As long as your description is not far off from the content it can help the search engine place your content in the most appropriate places - which could hopefully raise your positioning! This module enables you to populate descriptive meta tag information from the submission form, allowing you to target your meta description for each page of your site with ease.
Automatically 301 redirect old paths to new paths if they have been changed
Whenever you change the path to a page of content, you should always have a redirect from the old path to the new path. It can be so easy to change your paths, and it becomes even easier to change them when using Pathauto because if you are using the node title as part of a path, you will also change the URL alias when changing the title!
This module will keep track of all those path changes for you and redirect them automatically. Old links will not be broken, and the search engines will know it has been moved retaining your search ranking.