Who love to Drupal

Archive for the ‘Modules’ Category

Module development

Drupal feature Module example

Posted by drupallovers on July 13, 2012

In this example we create an Online Videos feature. The site builder configured a lot in preparation of this feature we are currently not interested in.

Step 1. admin/build/features/export

As you can see we added a name, description and a version. Next step will be defining what this feature provides.

Step 2. Select features components.

From the “Add Components” dropdown we have to select the components the feature consists off. This is about a video node so we select “Node”. From the checklist we only need the video node type.

The auto-detect functionality grabs the required building blocks node (video), content (video-field_video), modules (emvideo, features). Therefore, when we want to install the feature, we need to make sure we have installed the required modules.

Step 3. Download the feature.

When satisfied with all components, click the download button and save the tarball (in this case, online_videos-6.x-1.0-alpha1.tar.gz).

Step 4. Install and enable the feature.

Best thing to do is untar the file in your current project. As described above, features are not listed on the site/build/modules page even though they are technically modules. To keep them separate, you should consider putting all of your features in a separate directory — e.g., site/all/modules/custom/your-feature.

The feature now appears at admin/build/features. Checking the box next to the feature’s name and saving page causes the features module to check for the current state all features.

Step 5. Visit admin/build/modules

When checking for the module online video module it’s not there. Searching for the name would show you a dependency on online_video module. To disable such a module you have to disable the feature first.


  • We have said nothing about what drupal projects you need to install to be able to install our example feature.
  • If we had created a view this would be exported too. test it yourself.

Posted in Drupal6, Drupal7, Modules | Leave a Comment »

Deploy Content from Development Server to Destination Server On Drupal 7

Posted by drupallovers on July 4, 2012

Deploy Content Development Server to  Destination Server On Drupal 7 :

We have two Server  1 is source and another is Destination

http://localhost:81/dev         (Source)                                          2. http://localhost:81/live (Destination)



Source server Configuration :

  1. Download the following modules. For now, you need latest dev version of at least deploy, services, uuid, ctools and entity_dependency : DeploymentServicesEntity APIUUIDCToolsViewsEntity Dependency:
2. Enable the following modules: Deployment, Deployment UI, Chaos Tools, Universally Unique ID, Services, REST Server, UUID entity resource, Entity Dependency
3.Put spyc.php into the /sites/all/modules/contrib/services/servers/rest_server/lib folder, it can be found at http://drupal.org/node/1313976#comment-5317796.
4. Go to admin/structure/deploy/endpoints and click “Add”.
5. Enter ‘Live Server’ (or whatever you want to call your destination server) for the Name. Choose “Session authentication” for Authenticator, and “REST JSON” for Service. Click “Continue.”
6. When prompted for a username and password, choose the username and password for user 1 on the destination site. Click “Continue.”
7. For Endpoint URL, enter ‘http://localhost:81/live/services/rest‘. Click ‘Finish’. Note that it appears that any path other than ‘/services/rest’ on either origin or destination generates a Request response error: -1002 missing schema.
8. Now, create a deployment plan. Go to admin/structure/deploy/plans and click “Add”.
9. Give it a name like “Push to live server.” Aggregator: Managed aggregator. Fetch only: unchecked. Deployment processor: Queue API. Endpoints: the endpoint you just created. Click “Continue.”

10. Delete successfully deployed items: unchecked. Continue.

11. No plugin to configure. Click Finish.


Destination Server

  1. Download the following modules: ServicesEntity APIUUIDCToolsViews:
2. Enable the following modules: Chaos Tools, Universally Unique ID, Services, REST Server, UUID entity resource
3. Go to admin/structure/services and click “Add”.
4. Under Name fill in ‘live’ (or whatever you want to call your destination server — must be a machine name). Server: REST, path to endpoint services/rest, Authentication: Session authentication. Click ‘Save’.
5. Back at the listing page, click the “Edit resources” link and check off the things you want to be pushable form the source site, e.g. file: create/retrieve, node: create/retrieve…You must enable the User actions “Login” and “Logout” in the resources section for Session Authentication to work.
6. Back at the listing page, click on the arrow next to the “Edit resources” link and click on “Edit server”. Check “application/x-www-form-urlencoded” and save.


Now I have created  Two Basic page About and Page1 on http://localhost:81/dev/ site.


And go http://localhost:81/dev/admin/content and select “Push To Live Server” option from Update Option. Click Deploy link on http://localhost:81/dev/admin/structure/deploy

Run Cron On Dev Site

Bot content can be found on http://localhost:81/live/ Destination Server.

Posted in Drupal7, Modules | 5 Comments »

Drupal and Varnish

Posted by drupallovers on June 12, 2012

Varnish is a HTTP accelerator (or reverse proxy) capable of serving 100,000 requests a second. Somewhat faster than Drupal, even with page-caching on!

How does it work?

Diagram of the varnish process, explained in more detail in the list below.

  • Cache-hit
    1. User requests a URL
    2. Varnish checks it’s cache
    3. Varnish retrieves the data from the cache
    4. Varnish delivers the data to the user.
  • Cache-miss
    1. User requests a URL
    2. Varnish checks it’s cache – but the data isn’t cached
    3. Varnish requests the URL from the backend
    4. Drupal processes the request and delivers a response to Varnish
    5. Varnish caches the response
    6. Varnish forwards the response to the user

Varnish magic

Varnish is capable of some cool features. It can be used for:

  • Load balancing between a series of backend Drupal servers
  • Serving assets (images/css/swfs…) from a light-weight backend whilst serving content from Drupal
  • ESI – Edge Side Includes – allowing personalised pages to be cached
  • Maintainance-mode, where Varnish can serve a “Site is being updated” page without traffic hitting the backend

What are the cons?

Like any solution, Varnish brings its own set of issues.

  • Statistics – content served by Varnish won’t hit the backend, so traditional stats (log files, the statistics module) won’t show the correct results. Use a client-side solution such as Google Analytics instead.
  • Personalisation – personalised pages are hard to cache. You will need things like ESI and custom VCL logic. Not for the faint-hearted.
  • Caching-rules complexity – choosing what to cache, how long to cache it for, and how to purge the cache if content is updated, is all complex, and needs more modules, more VCL rules. Choose a balance between complexity, performance, and investment in hardware.
  • Decreased performance – What? I hear you cry…I thought Varnish was meant to improve performance! Well, if something’s cached, it’s quicker. But cache-misses are generally slower via varnish than a direct request, because every additional system in the request-route decreases performance. In reality, most web-sites would benefit (if only to cache images and css), but it might not be suitable for a web-service.

Getting setup: How to add varnish to your existing web site

This how-to presumes that you already have your drupal site up and running, using apache on port 80.

  1. install varnish (apt-get install varnish / yum install varnish)
  2. change the varnish config to listen on port 80 Edit /etc/default/varnish Change the VARNISH_LISTEN_PORT to 80 NB: the behaviour has changed somewhat across varnish – check the docs for your version!
  3. change apache config to listen on port 8080 (or another suitable port, if something’s already running on 8080)
  4. edit the VCL to forward backend requests to apache Edit /etc/varnish/default.vcl
    backend default {
      .host = "";
      .port = "8080"; 
  5. restart apache
    I usually use “apache2ctl graceful”, rather than “/etc/init.d/apache2 restart” because this sanity-checks the configs before restarting!
  6. restart varnish: “/etc/init.d/varnish restart”
    NB: each time Varnish is restarted, its cache is cleared.

This will give you a very basic implementation – to see the benefit of varnish, you’ll want to do more.

Optimising Varnish and Drupal to work together

  • Varnish module: The varnish module provides an admin dashboard to show you the status of the Varnish server(s), and provides integration points which will clear the Varnish cache when a node is edited (when integrated with the expire module).
  • Expire module: The expire module has been separated out from Boost, and provides a generic cache-management tool which runs at page-level. Expire will purge the appropriate pages from the varnish cache when the content changes.
  • Memcache et al: use all of the normal performance tools as well. So memcache, APC, cache-sets/gets in your custom modules, etc. Varnish is an addition to the performance tools, not a replacement.
  • ESI module: Edge-side includes are difficult, but the ESI module makes them a little easier.

Some custom VCL logic

Long live assets!

Assets should live a long time. CSS, images, JS, SWFs: should all hang around in the cache.

sub vcl_recv {
  # Assets are pulled from the cache, even if we have a NO_CACHE cookie.
  if (req.url ~ "\.(png|gif|jpg|swf|css|js)$") {
    return (lookup);
sub vcl_fetch {
  # Don't cache cookies
  remove beresp.http.Set-Cookie;
  # Set a long TTL (1 day)
  set beresp.ttl = 86400s;

Is it working?

To give you some reassurance that Varnish is doing it’s job, it’s nice to see if you’re getting hits or misses. This code will add an HTTP header to report back.

sub vcl_deliver {
  if (obj.hits > 0) {
    set resp.http.X-Cache = "HIT";
  } else {
    set resp.http.X-Cache = "MISS";

How to clear the varnish cache

In case you follow all these instructions, but end up with some really private data in your cache, here’s a quick clear-cache how-to!

  • command-line: SSH into the server, and run:/etc/init.d/varnish restart
  • Telnet: Telnet to the admin port of Varnish (by default port 6082) and use the purge command
    telnet 6082
    url.purge /

    url.purge will take regex – see the Varnish docs for more info.

Posted in Drupal7, Modules | Leave a Comment »

Drupal Site Configuration: Site Information, Triggers and File

Posted by drupallovers on May 14, 2012

People often assume that the basics are easy to master and therefore, don’t require much thought. Things are not quite so simple in reality because while a site’s basic setup is, more often than not, easy to implement, the more subtle problem is in knowing what to implement, and how to implement it in the first place. Precisely understanding what you need from a site is particularly important for this reason.

Does this mean that you should not start working directly on the site unless you know exactly what is required? Not really; like most things, it’s a bit of a trade-off when it comes to starting out with the development of a Drupal website. This is because it is almost impossible to determine exactly what the site will need and how its functionality should be provided until you have been working with it for some time. Often, you will find yourself modifying the behavior of a site based on feedback from the users.

In this article by David Mercer, author of the book Drupal 7, we are going to talk about the following Drupal site configuration topics:

  • Site information
  • Actions and Triggers
  • Shortcuts
  • File system

(For more resources on Drupal, see here.)

Not everything that is available in Drupal’s Configuration section is discussed in this article. Some settings are very straightforward and really don’t warrant more than perhaps a brief mention.

Before we start

It is sensible to make note of a few important things before getting our hands dirty. Make it second nature to check how the changes made to the settings affect the site. Quite often settings you modify, or features you add, will not behave precisely as expected and without ensuring that you use a prudent approach to making changes, you can sometimes end up with a bit of a mess.

Changes to the site’s structure (for example, adding new modules) can affect what is and isn’t available for configuration so be aware that it may be necessary to revisit this section.

Click on Configuration in the toolbar menu. You should see something like the following screenshot:

A quick point to mention is that we aren’t giving over much space to the final option—Regional and Language. This is because the settings here are very basic and should give you no trouble at all. There is also an online exercise available to help you with date types and formats if you are interested in customizing these.

Let’s begin!

Site information

This page contains a mixed bag of settings, some of which are pretty self-explanatory, while others will require us to think quite carefully about what we need to do. To start with, we are presented with a few text boxes that control things like the name of the site and the site slogan.

Nothing too earth shattering, although I should point out that different themes implement these settings differently, while some don’t implement them at all.

For example, adding a slogan in the default Garland theme prints it after the site name as shown in the following screenshot:

Whereas, the Stark theme places the slogan beneath the site name:

Let’s assume that there is a page of content that should be displayed by default—before anyone views any of the other content. For example, if you wanted to display some sort of promotional information or an introduction page, you could tell Drupal to display that using this setting. Remember that you have to create the content for this post first, and then determine its path before you tell Drupal to use it. For example, we could reference a specific node with its node ID, but equally, a site’s blogs could be displayed if you substitute node/x (in node/ID format) for the blog.

Once you are looking at the content intended for the front page, take note of the relative URL path and simply enter that into the text box provided.

Recall that the relative URL path is that part of the page’s address that comes after the standard domain, which is shared by the whole site. For example, setting node/2 works because Drupal maps this relative path to http://localhost/drupal/node/2

The first part of this address, http://localhost/drupal/ is the base URL, and everything after that is the relative URL path.

Sometimes, the front page is a slightly more complex beast and it is likely that you will want to consider Panels to create a unique front page. In this case, Panels settings can override this setting to make a specific panel page as the front page.

The following settings allow you to broadly deal with the problem of two common site errors that may crop up during a site’s normal course of operation—from the perspective of a site visitor. In particular, you may wish to create a couple of customized error pages that will be displayed to the users in the event of a “page not found” or “access denied” problem.

Remember that there are already pretty concise pages, which are supplied by default. However, if you wish to make any changes, then the process for creating an error page is exactly the same as creating any other normal page.

Let’s make a change very quickly. Click on Add new content in the Shortcuts menu and select Basic page. Add whatever content you want for, say the Page not found! error:

Don’t worry about the host of options available on this page—we will talk about all of this later on. For now, simply click on the Save button and make note of the URL of the page when it is displayed. Then head back to the Site information page, add this URL to the Default 404 (not found) page dialog, and then click on the Save configuration button:

If you navigate to a page that doesn’t exist, for example, node/3333, you should receive the new error message as follows:

In this example, we asked Drupal to find a node that does not exist yet and so it displayed the Page not found! error message. Since Drupal can also provide content that is private or available to only certain users, it also needs the access denied error to explain to the would-be users that they do not have sufficient permissions to view the requested page. This is not the same as not finding a page, of course, but you can create your own access denied page in exactly the same way.

Finally, you will need to specify how often cron should run in the Automatically run cron drop-down at the bottom of the Site information page. Cronjobs are automated tasks (of any type—they could be search indexing, feed aggregation, and so on) that should run at specified intervals. Drupal uses them to keep itself up-to-date and ensure optimal operation.

Drupal uses web page requests to initiate new cron runs once the specified interval has elapsed. If your website does not get visited regularly, cron itself cannot run regularly.

Running cron every few hours is reasonable for the vast majority of sites. Setting it to run too quickly can create a huge load on the server because each time the cron is run, all sorts of scripts are updating data, performing tasks, and consuming server resources. By the same token, run cron too infrequently and your site’s content can become outdated, or worse, important module, theme, and core updates can go unnoticed, among other things.

Actions and triggers

Quite often, it happens that for specific events, it is useful to have Drupal automatically perform a specified task or action. An action, in the Drupal sense, is one of a number of tasks that the system can perform, and these usually relate to e-mailing people or acting upon user accounts or content. There are a number of simple actions that are available as well as a few more advanced ones that can be set up by anyone with sufficient permissions.

To configure actions, navigate to Actions in SYSTEM under the Configuration menu in the toolbar:

Default simple actions cannot be modified, so we will ignore these for the moment and focus on creating a new, advanced action. Set up a new Send e-mail action by selecting it from the drop-down list and click on the Create button, as shown in the preceding screenshot. This brings up the following page that can be set according to how this specific action will be used:

It should be clear that the intention of this e-mail is to notify the staff/administration of any new site members. The Label field is important in this respect because this is how you will distinguish this action from the other ones that you may create in the future. Make the description as accurate, meaningful, and concise as possible to avoid any potential confusion.

Also notice that there are several placeholder variables that can be inserted into the Recipient, Subject, and Message fields. In this instance, one has been used to inform the e-mail recipient of the new user name, as part of the message.

A click on the Save button adds this new action to the list where it can be modified or deleted, accordingly:

So far so good—we have set the action, but this in itself does absolutely nothing. An action cannot do anything unless there is a specific system event that can be triggered to set it off. These system events are, perspicaciously enough, called triggers and Drupal can look for any number of triggers, and perform the actions that are associated with it—this is how actions and triggers work together.

Triggers are not part of the topic of Drupal configuration. However, we will discuss them here for completeness, since actions and triggers are integrally linked.

Triggers are not enabled by default, so head on over to the Modules section and enable the Triggers module. With the module enabled, there will now be a new Triggers link from the Actions page. Clicking on this brings up the following page:

Triggers are divided into five different categories, each providing a range of triggers to which actions can be attached. Assigning a trigger is basically selecting an action to apply from the drop-down list of the relevant trigger and clicking on the Assign button.

To continue with our example, select the USER tab from the top of the Triggers overlay and, in the TRIGGER: AFTER CREATING A NEW USER ACCOUNT box, select the newly defined action, as shown in the following screenshot:

Click on the Assign button, and the newly assigned action will show up in the relevant trigger box:

In the same way, a large number of actions can be automated depending on the system event (or trigger) that fires. To test this out, log off and register a new account—you will find that the New User Alert e-mail is dutifully sent out once the account has been registered (assuming your web server is able to send e-mail).

Drupal 7

Drupal 7 Create and operate any type of Drupal 7 website quickly and efficiently

Read more about this book

(For more resources on Drupal, see here.)


Shortcuts are a new feature of Drupal 7 and allow administrators (or anyone with sufficient permissions) to create sets of links that can be accessed by others using the shortcuts bar—directly below the toolbar menu. By default, Add content and Find content are the only two links that are provided, but you may change these regularly depending on what you are working on at any given time.

For example, it may be useful to create a set of shortcuts that involve theme-related links for quick access when it’s time to theme the site. By the same token, adding links to views and displays might be more useful when working on content.

The overlay system is integrated with shortcuts, making it easy for the administrators to add links to their shortcuts. For example, let’s say we wanted a set of configuration shortcuts so that all the main configuration tasks are readily accessible at a moment’s notice.

To do this, we need to first add a new shortcut set. Go to Shortcuts in USER INTERFACE under Configuration, and click on the Add shortcut set link, to bring up the following page:

Now go to your account, and select the Shortcut tab. Select the new Configuration option and save the changes by clicking Change set to ensure that you are viewing the correct shortcut set. Now click on Edit shortcuts in the shortcuts bar to bring up the list of links contained in this set:

Nothing too exciting yet. In fact, this is exactly the same as the default shortcut set. We can add new shortcuts to this list manually by clicking on the Add shortcut link and providing a name and path manually:

Clicking on the Save button shows the new link added to the list and it is also now available in the shortcuts bar on the top of the page.

The other, easier way to add links is simple; click on the plus icon next to the overlay name. A small popup appears to the right of the icon while hovering over it. Take note of this because it indicates which shortcut set the link will be added to.

The new shortcut will appear along the top of the page with the rest of the links.

Anyone with sufficient permissions can create their own set of shortcuts and use them as they choose. The shortcuts system also provides a block that can be added to the site like any other block. Making effective use of shortcuts can help you cut down the wasted navigation time—just remember to select the most relevant set from your account because it is only possible to view one at a time.

File system

How you deal with the file system settings really depends on what type of content you visualize your site using. If you know that most files should be available for anyone to download, then leave the Default download method as Public. By the same token, if you want some control over who can access the files then use the Private method.

Public files can be accessed directly through a browser without having to go through your Drupal website. So, if someone liked a video you posted, they could reference it from their own website, allowing their visitors to see the video using your bandwidth to serve it—obviously not ideal.

You need to keep an eye on this and find out if your host service provides some sort of hotlinking protection to combat this.

Assuming you want to make your download method private, you will need to specify a directory that is not directly available over the web—in other words, it is outside the document root folder.

The same technique is used for the temporary files folder that Drupal requires in order to properly handle any files you or the site users might deal with.

On your development machine, you might end up with something like the following screenshot (Public file downloads):

To make this private, create a folder outside of the web root (but still within the web server folder), add it to the Private file system path option, and click on the Save configuration button, as shown in the following screenshot:

With the new absolute path to the private folder specified (in this case, privatedrupalfiles) there will now be an additional Default download method available for selection, entitled Private local files served by Drupal.

The Default download method is the default behavior. Individual download methods can be set on each file type field added to any content type.

Before continuing, let’s confirm that we can specify a download method for any file without problems. Go to Content types under Structure, and click on the manage fields link next to one of the content types, say blog entry. Add a new field of the File type and save the changes. You will then be able to select Public files or Private files in the Upload destination section on the following configuration page, as shown in the next screenshot:

The important point here is that each file uploaded to the site can be controlled on a field level basis, and more importantly on a field level per content type basis. This is a vast improvement over Drupal 6 which forced either all files to be public or all to be private.

How Drupal controls what type and the size of the files that can be uploaded is a matter for the content type specific configuration page shown in the preceding screenshot. It is not really sensible to allow any type of file to be uploaded to the site. The first thing that will happen if you do this, is that someone will upload a malicious executable file that does something nasty when it runs on the users’ machines, in turn, causing them to say or do something nasty to you.

For example, you might know that for a particular content type, the only type of file that should be uploaded is a small text or .txt file. In this case, you would have something like the following settings:

In this case, we have specified that only ‘txt files’ of less than 50 KB can be uploaded to the blogtext sub-directory. The decisions you ultimately make should be dictated by the needs of the individual site. When in doubt, follow the tenet:

Provide only what is absolutely necessary, and no more!

The actual settings themselves are easy enough to implement, but I suggest you do not add any file extensions that you know the site will not need. Remember that it is possible to cloak nasty software within other file types, so the more variety you allow, the less secure things become.

We can test all of this out by posting a new blog and trying to upload files. Try a range of files, not just ‘txt’ files to see the results. For example, attempting to upload an image file gives the following result:

However, uploading a new file that does meet the criteria set, meets with success and we can check to ensure that the file is present in the proper sub-directory of the file system, as shown next:

As you can see, the site has correctly uploaded the blogtextfile.txt file in the blogtext subdirectory, as specified earlier. The field-based system for file handling in Drupal 7 represents a huge improvement over previous Drupal milestones.


This article has covered a fair amount of ground in terms of setting up the site. We began by looking at some general configuration settings, like Site information, that are important in terms of getting the nuts and bolts in working order. Many of these settings will need to be revisited as the site develops.

While triggers aren’t necessarily part of a discussion on configuration, we learned that they are inextricably linked to actions that can be configured to automate many common site tasks or chores. Again, coming back to actions and triggers every once and a while can help reduce the number of repetitive tasks that have to be completed manually.

Next, we gained the ability to control file uploads and file handling using Drupal 7’s new field-based paradigm. Having fine grained control over how various files are accessed is a great improvement over past incarnations of Drupal.

Posted in Drupal7, Modules | Tagged: , | Leave a Comment »

Workbench: Managing Content Management-1

Posted by drupallovers on April 25, 2012

This screencast is a part of the Workbench learning series. You can find more at the following links:
* NodeOne Drupal Learning Library: nodeone.se/learn-drupal
* The Workbench overview series: nodeone.se/node/1021
* The Workbench main project page: drupal.org/project/workbench

Posted in Drupal7, Modules, Videos | Tagged: | Leave a Comment »

30+ Essential Drupal Modules

Posted by drupallovers on April 19, 2012

  The Big Three

“The big three” are important enough that they deserve a category of their own. Most drupal modules worth using have integrated with one of these three. Their importance simply can’t be stressed enough.

  • Content Construction Kit (CCK) – Part of drupal 7; still a contrib in drupal 6. Allows you to define new content types (e.g. blog entry, event, or employee record…) and add “fields” to them. A field could be plain text, an image, a flash video, or whatever. You can also adjust how these fields display in the live view. No drupal install should be without this module.
  • Views – Broadly speaking, this module empowers non programmers to build dynamic streams of content displaying any number of fields. The content may come from nodes (a.k.a. content types and fields), users, system log entries, etc. You can display this stream in any number of formats including RSS feeds, tables, or just the vanilla view for a content type. You can also create pages or blocks — its very tightly interwoven with drupal. Nearly every drupal module worth using is integrated with this module. Extremely powerful when used in combination with CCK.
  • Panels

    I believe Panels + CCK & Views is a hint at what drupal will look like 3 years into the future. I had to change my pants after the first time I witnessed it. At a very simple level, you could think of it as a layout manager. Create a 1,2,3 column layout. Or a 3 column layout with a full width footer and header, and plop pieces of content in them — say a view, a block, or a node. That description, however does not do it justice. Since version 3, its positioned itself as a replacement for drupal core’s clunky block system. It can now override a node page, and can be used to place content all over the place. It also introduced a concept of contexts, selections rules, and relationships. These are concepts that deserve a series of blog posts, but lets just say its solving some of the weirdest, mind numbing, bug creating problems found in advanced websites. Ironically, I used to hate this module, but after version 3 I will defend its awesomeness to the death!

For Administration Sanity

  • Admin Menu – Quick Dropdown menu to all admin areas. Makes any setting only a click away, instead of 3 to 6 clicks away.
  • RootCandy – A theme specially designed for administration. Drupal 7 comes with an admin theme included, but this is still highly recommended in drupal 6.


Content and SEO

  • Pathauto – Automatically create human readable URLS from tokens. A token is a piece of data from content, say the author’s username, or the content’s title. So if you set up a blog entry to use tokens like [author-name]/[title] then a blog entry by “Phil Withersppon” titled “my great day” will be rewritten example.com/phil-witherspoon/my-great-day.
  • Printer, email, and PDF Versions – There are still people out there who prefer to print out content to read later. This module does just that, and also lets them send your content via email.
  • NodeWords – A very poorly named module that’s great at letting you edit meta tags.
  • Page Title – Lets you set an alternative title for the <title></title> tags and for the <h1></h1> tags on a node.
  • Global Redirect – Enforces numerous well thought out SEO rules, for example since I don’t use this module you could access my content at “http://www.nicklewis.org/node/1062&#8221;. This module however will search for the alias and 301 to the proper URL http://www.nicklewis.org/40-essential-drupal-6-modules. (thanks Jeff!)
  • Path Redirect – Simple idea: make it easy to redirect from one path to another. Does a good job at it.
  • Taxonomy manager – Makes large additions, or changes to taxonomy really really easy and painless.
  • Node Import – Made it shockingly easy to import 2000 csv rows, tie rows to CCK fields (or locations), and even will file it under the right taxonomy terms in hierarchy so long as you plan ahead.


  • Menu Block – Lets you split menus into separate blocks based on depth. Say you have a top level menu link “Articles” with sub menu links “Politics”, “Technology”, “lifestyle”. This block would let you show the sub menus in the right sidebar, and the top level “article” as tabs in the header.
  • Taxonomy Menu – Automatically generate menu items for categories. Handles syncing between taxonomy and menus, and is ready to be used in conjunction with views or panels.
  • Custom Breadcrumbs – Set up custom breadcrumb paths for content so that every page doesn’t just have a breadcrumb back to “home”. (note: i’ve used menu_trails a lot too.)
  • Nice Menus – Drop down menus (for people who are into that kind of thing).

WYSIWYG Editors + Image Uploading

  • WYSIWYG API – The standard integration module.
  • CKEditor – Currently my favorite WYSIWYG editor. WYSIWYG API only supports CKEditor on its dev version (at the time of this writing). For the time being, I use this module instead of WYSIWYG api. Regardless, the rest of the world probably uses WYSIWYG api.
  • IMCE – File browser / image inclusion for WYSIWYG editors. CKeditor is integrated out of the box, WYSIWYG API implementations require a bridge module.

Video and Image Handling

  • Filefield – Base CCK file upload field. Useful on its own, but also required by other essential modules.
  • ImageAPI, ImageCache, Imagefield – These three work together. ImageAPI handles low level integration with server side image processing (e.g ImageMagick). ImageCache allows you to set up presets for automatic resizing, cropping, and a host of other operations you’ll probably never need to use. ImageField then provides an upload field to a piece of content, which you can use imagecache presets to resize in the display. Imagefield is very well integrated with Views and CCK. The paintings on the right show a bunch of images automatically resized using this technique.
  • Lightbox2 – If you’ve set up your imagefields, lightbox2 lets you add another layer of options. For example, display image resized at 300px wide on the page, but blow it up to full size when clicked. Like Imagefield, lightbox 2 is well integrated with Views and CCK. Very powerful combination.
  • Embedded Media Field – Embed video and audio files from dozens of third party providers ranging from youtube, to services you’ve probably never heard of.

User Profile, Ratings & Notifications

  • Content Profile – The core profile module sort of sucks. This turns profiles into nodes allowing you all the options of views and CCK.
  • Voting API + Fivestar – The standard voting widget of Drupal.
  • Notifications – Provides the ability to send emails when someone comments, or replies to a comment. Has a host of other features.
  • Captcha + Recaptcha – Standard Antispam system. In use on this very site.

Stuff Marketers Will Love

  • Webform – We all know visitors love filling out forms. This module lets your marketing team create custom forms, and collect whatever info they want.
  • Google Analytics – Simple integration of drupal with google Analytics.
  • Service Links – Easy “share this” links for content. Supports digg, facebook, delicous and a bunch of other social web 2.0 services.

Events and Calendars

  • Date – CCK field for handling dates, and date ranges.
  • Calendar – Integrated and controlled by views.

Location and Mapping

  • Location – Standard API for collecting addresses and lat/long. Integrated with Views and CCK. Somewhat difficult to use, but its a somewhat difficult problem it solves.
  • Gmap – Display locations in GMap.


For Developers

  • Devel – Offers an enormous amount of information for developers, including: theme template variables, and overrides, browsable data structures, and datasets for performance-tuning. Just the debug function dsm(); makes it worth the download.
  • Backup & Migrate — Greatly eases the pain of moving changes from your local development environment to the live server and vice versa.
  • Drush – Its actually not really module, but a “Swiss army knife” set of tools that are run from a command line. One example command is “drush dl views”: running it will automatically download the latest version of views and place it in the right drupal folder. 1 second command instead of a 1 minute process of downloading from drupal, uploading via FTP. There’s many other commands that are just as useful.


Lists like this can be outdated within six months. Always be on the look out for better and better modules.

Posted in Drupal, Modules | Leave a Comment »

Custom Search Module for Drupal

Posted by drupallovers on March 30, 2012

The Drupal core provides a Search module which is great for many sites. However, it doesn’t provide some of the more sophisticated features that some sites need. The Custom Search module is a good alternative if you want more control over what gets searched, who gets to search, and what results you see.

The Custom Search module adds layers of control and sophistication to the core search module. It’s easy to install and understand, and will give you more control over the search functions on your site. It also integrates with other search modules and APIs.

The core search function and the Custom Search module


The basic elements of the core search module are:

  • A block for front-end display. There is very little configuration available for this block. I’ve named this one “Core Search Block” to make it easy to distinguish from the customized one We’ll be creating.
  • Advanced search is available on search results page. If a user clicks Advanced Search on the results page, a form opens up so you can refine your search. (When using the Garland Template).

This gives you a sophisticated search, but little control over how it’s implemented throughout the site. A good way to expand on this is to add the Custom Search Module. Here’s a summary of the added options.

Basic options:

  • Select which content type(s) to search,
  • Select which specific module search to use (node, help, user or any module that implements search),
  • advanced criteria

Advanced options:

  • change the default search box label,
  • add a default text in the search box,
  • add advanced search criteria,
  • change the default submit button text,
  • use an image instead of the submit button,
  • change the order of all the elements,
  • include some elements in a popup block,
  • add a filter to the results page,
  • show/hide basic and/or advanced search in the results page,
  • show/hide meta data in the results page,
  • multiple search paths

Step 1. Download and install the module

Step 2. Enable the module and its sub-modules


There are three included sub-modules:

  • Custom Search Taxonomy: taxonomy options for the search block.
  • Custom Search Blocks: provides additional search blocks, with different settings.
  • Custom Search Internationalization.

Step 3. Set Permissions for users and administrators

  • The confirmation message will have a link to the permissions. Click it to go directly to the permission settings.
  • Set user and admin permissions for two modules. I wanted everyone to be able to search so I gave anonymous users and authenticated users permissions by checking the boxes
  • You have four sets of permissions to set.
    • Custom Search
      • Admin
      • User
    • Custom Search Blocks
      • Admin
      • User

Step 4. Configure the module

  • Return to the Modules page and click Configure. You can also get to the configuration screen by going to Configure > Custom Search
  • When you land on the configuration page the selected tab will be highlighted. You will be going through all the tabs to complete the full configuration. So when you complete the first page, choose another tab and continue
  • I’m not going to go through every single configuration step. The choices are easy. If you have a need to create refined searches, they will make sense to you. If not, trial and error is the best way to get familiar with them. In this demo I’m going to enable everything.
  • There is one section that may need a little explanation – the Search Blocks tab:
  • Select the number of blocks. One of the great things about this module is that every block can have it’s own configuration settings. Suppose you wanted a block on the home page that searched the entire site, but not the forum. On the forum page you want a block that only searches the forum. In that case you would create two blocks. If you wanted anonymous users to be able to search just some forum topics, and registered users to have more option, you would create 3 blocks, and control which one shows by who’s logged in.
  • I’m just going to create one for this demo. Once you decide on this, add blocks to your site.
  • Be sure to save before moving on.

Step 5. Add blocks to your site

  • Go to Structure > Blocks.

Step 6. Assign blocks to regions

  • The custom search blocks you created will be visible and numbered.
  • Choose the regions for the blocks.
  • The new block is added.
  • The original block created by the core is still there. It’s default label is Search Form. I can’t think of a reason why you would want both of them on the same page unless you’re writing a tutorial, so you can remove the original if you want.
  • Be sure to Save Blocks before you try any configuration.

Step 7. Customize the blocks from the front end


Here are both blocks, the original core search block and the one I just added. Compare the look of the Core one with the first image. You’ll see that some custom features have been added. The first picture just shows an entry field and a search button. Now we can search tags and forums. This is because the new module makes those capabilities available to all the modules.

It also makes customization very simple. When you are viewing the module from the front end, mouse over the title and you will see an icon that looks like a cog from a gear.


This will give you access to the configuration for this particular module. It makes it much simpler if you are going to have multiple search boxes with different types of search. You can define each one while you are on it’s page. It saves time and prevents mistakes.

Step 8. Configure Visibility

  • Clicking Configure will allow you to change the visibility and normal block function.
  • Clicking Custom Search configuration will give you access to define the search box itself.

Step 9. Configure each block to have custom features


From here you can configure what’s include and what type of search you want.



Above you can see what the original search block looks like after I’ve configured some additional elements to show. This will allow you to present a highly customized search experience to your the public and authorized users.

Posted in Drupal, Drupal7, Modules | Tagged: | Leave a Comment »

Multiple Categories with the Drupal Contact Module

Posted by drupallovers on March 30, 2012

The Drupal Contact module is often replaced by the Webform module. However, it can be useful in some situations. For example, image that you have different departments and you want each of them to get a different contact form on your Drupal website. If you’re willing to keep it simple, you can do everything you need with the core Contact module and won’t have to install anything else.

It all depends on knowing how to create categories and blocks.

Step 1. Make sure the Contact module is enabled

  1. Click Modules
  2. Click Save configuration.
  3. Click Configure next to Contact.

Step 2. Add and edit categories.


Click Add category to add a new one.

There is a default category called Website feedback that you can use as well, but we are showing you how to add extra ones. You can edit the default category later if you need to.

Step 3. Configure the category

  1. Give the category a name.
  2. Specify the Recipients
  3. Create an Auto-reply message.
  4. Set Selected. Yes means it will be the default contact form. Since this is a new category, you probably want this to be No. You can only have one default.*
  5. Be sure to click the Save button.

*Selected: When a visitor clicks on the link to the contact form, the categories will show in a drop down list. Whichever one is chosen with a “Yes” will show automatically If you want your visitor to be forced to choose a category before submitting the form, make all of these fields “No”

Continue repeating the process until you have all the categories you want. A “category” can be a different department, a group or individual.

Step 4. Enable the menu link


Jump to the Menus administration page by clicking the blue link in the instruction paragraph. Alternatively you can get their via the admin menu and clicking Structure then Menus.


Step 5. List the links


A Contact menu item (disabled by default) is added to the Navigation menu, which you can modify on the Menus administration page. Click list links next to Navigation.

Step 6. Enable the link


This menu link will go directly to the site-wide contact form. You will see a Contact menu item that is disabled. You can use this one as a guide for creating other menu links.

Step 7. Configure the link

  1. Edit the link title if needed.
  2. Enable the link so it appears on the menu.
  3. Choose the parent link if you want it to be different from the default “Navigation”.

Step 8. Add a block with instructions for the user


Go to Structure > Blocks.

Step 9. Add a block


Step 10. Add the block information

  1. Enter a Block Description. This will not be seen by the public.
  2. Enter a Block Title. This will be seen by the public.
  3. Write your instructions. This will also be visible to the public,

Scroll down the page.

Step 11. Set the visibility settings by assigning it to the Contacts page

  1. Choose “Only listed pages”. The only page we want to have these instructions is the Contact page.
  2. Write “contact” in the text field.
  3. Save the block.

Specify pages by using their paths. Enter one path per line. The ‘*’ character is a wild card. Example paths are blog for the blog page and blog/* for every personal blog.is the front page.

There are other parameters and settings on this page, but for the purpose of this tutorial we only need the basics.

Step 12. Enable the block


You will be returned to the Blocks page. You will find the block you added in the Disabled list with the title you created. To enable it, choose the position from the drop down box.


Choose Help.

This box lists all of the regions available on the template you are using. On the Bartik template, the Help region is right where we want it. You may have a different idea or location on your website.

Step 13. Final configuration then save.


As soon as you choose the region, the block title will now be visible at the top of the page that shows the enabled modules. The will be grouped by region, so this one will be under Help.

Remember to Save – scroll to the bottom of the page


No changes will be saved until you click Save blocks.

Your result


If you followed all these steps you will have a contact form that looks something like this.

  1. There is a link on the menu to the form.
  2. The instructions are in the Help Region in a block you added.
  3. The correct email address shows. (this will change to the right one when the category is selected).
  4. There is a drop down list with the categories you created.

Posted in Drupal, Drupal7, Modules | Tagged: , | Leave a Comment »

Getting Started With Drupal’s Webform Module

Posted by drupallovers on March 30, 2012

Webform is the module for making forms and collecting information from users in Drupal.

After a submission, you can send users a thank-you email as well as sending a notification to administrators. Results can be exported into Excel or other spreadsheet applications. Webform also provides some basic statistical review and has an extensive API for expanding its features.

If you need to build a lot of customized, one-off forms, Webform is a more suitable solution than creating content types and using the CCK or Field modules.

Download the Webform Module


Go to this url http://drupal.org/project/webform, and download the Webform Module.

There are some additional modules that add some functionality and make some operations easier. You can download the optional modules as well. To keep things simple, we’ll use the basic module and show you how to create a simple survey of registered users.


Download the correct version. They may have changed since we wrote this, so be sure to check.

Install the Webform Module


Enable the module


Go to the Modules page and scroll down to Webform and click the check box. Click Save configuration.

Access the form fields


Go to Structure > Content types


Scroll down to Webform and look the right for the links to edit and manage fields and the display.


Click Edit

If you are familiar with CCK in Drupal 6, or Fields, which is now part of D7 core, you will see a familiar interface for adding and managing new fields.


This is not the place where you will be creating forms. Editing here is exactly the same as editing Fields in Content Types, which is a way to make fields available to this content type. From here you can edit fields, manage existing fields, the display and the comment functions by clicking on the appropriate tabs. But creating the actual form is done by adding content in the same way you would add an article.

You won’t need to do much here but review all your choices and see if there is anything you feel you must change. The default values will work for the purposes of our demonstration. After you create your first form and understand the module you might want to revisit the configuration.

Now that the module is installed and the configuration is checked, you can begin building your survey form.

Create your first webform by adding it as content


Go to Content > Add Content > Webform

Don’t get confused over Poll vs Webform. We are creating a form with various types of questions, not taking a Poll. Poll is another content type that is similar, but restricted to multiple selection fields and gathering the statistics on the responses. Webform is a form submission module, and collects the actual responses and stores them in a table for you to review. You can collect almost any type of data using Webform.

Create the basic form details


Give it a title and make the decisions on all basic options. Save this with the save button at the bottom of the page.

Add form components


Now you will see the controls for creating and editing the rest of the form elements. Start adding Form components on the WEBFORM tab.


Give the component a label, choose textfield and then click Add.

We’re surveying registered users, so we are going to automatically fill in their username. A name is basic text field, but we want our registered users to show up on the textfield, so we’re going to make use of Tokens. Using Tokens is just an optional feature.


Enter the token %username in the Default value field.

This will pull the username from the data base and fill it in automatically.

If you don’t see the TOKEN VALUES, you probably don’t have the Token module installed. You only need Token if you want to fill in the default values taken from the data base. If this is going to be a blank field that the user will fill in when they visit the page, you can just leave the Default value blank. I used Token here to illustrate the possibilities available to you.

If you need the Token module you can download it here http://drupal.org/project/token

Scroll down the rest of the page and make any configuration selections you need then click Save Component at the very bottom of the page.

Create a “Select” field


Fill in a new label and choose the Select options type from the drop down. Click Add and complete the options on the next screen

Create the list of options


Go to Options and create Key Value Pairs. These pairs consist of a machine readable key and a plain language value separated by a “|” – This character is called a “pipe” and you can find it by holding shift while pressing the backslash key “\” key on most keyboards.

Key-value pairs MUST be specified as “safe_key|Some readable option”. Use of only alphanumeric characters and underscores is recommended in keys. One option per line.

Save the Component.

Repeat this step for the flavor of the jelly and type of peanut butter.


When you are creating lists, the default type is radio buttons. If you want check boxes or a listbox the choices are farther down on the page. You can also set the field as mandatory or optional. If you click the “Multiple” check box at the top, the list will appear as check boxes. If you choose “Listbox” under DISPLAY you will have a drop down box. Selecting “Multiple” and “Listbox” will allow users to make multiple selections from a dropdown box.

When you create the Jelly type, add Other as a choice. Then add a text field so people can write in their suggestions.

Add a Text field


You can add a text field, or a textarea. A text field is for short entries like names. A textarea will be a large area for entering more extensive written responses.

Other field types you might want to add for your purposes are an E-Mail field or Date Field. You can choose thees types from the dropdown “Type” box.


You can choose other field types from the Type drop down.

Add a preset field type


There is a convenience feature you may want to use. You can create pre-built option lists and add them to your form. The module comes with several default lists. Add one for States if you want to see how this looks on your form. Label it State and then choose the Select Options type and when you get to the next screen, make your selection.


Choose US States from the drop down.

Check your form


At this point your form will look similar to this. You can change the locations of the descriptions by clicking the WEBFORM tab and editing each item and making different configuration selections. Once you have the form ordered the way you like it and all the questions and fields correct. Go back to the WEBFORM tab EMAIL tab and set the EMAIL options.

You can use drag and drop to move form elements to different positions.

Configure the E-Mail options.


Go back to the WEBFORM tab and look for the E-mails sub-tab. Fill in an address and click Add.

Set the email address if you want to receive an email when the form is submitted. You can add multiples.


There are lots of choices to make. Be sure you check every one of them so they are correct for your form. Be sure to save the changes.

Configure the Form Settings


From the WEBFORM tab Click the Form Settings sub-tab at the top of the page. Check and modify settings as needed. Save your changes.

Now you can publish your form exactly like you would publish any other content item on your site. After you’ve had a chance to collect submissions, you will see the results when you are logged in as a user with the correct permissions.


Click Content > Find Content and select the form from the content list and you can find the results tab. This will allow you to see the collection of data you have as well as give you some simple analysis.

Posted in Drupal, Drupal6, Drupal7, Modules | Tagged: , , | Leave a Comment »

A Introduction to the Drupal 7 Media Module

Posted by drupallovers on March 30, 2012

The Media Module is one of the most hyped new modules for Drupal 7. It is often talked about as the best option for handling images, video and audio files in Drupal 7.

However, available information about the Media Module is long on 90 minute conference presentations and short on quick, practical guides. So, in this tutorial we’re going to get right to the point. We’re going show you how to set up the Media Module, what it does and how to use it to add YouTube videos to your content. Let’s go ….

Install the Media Module

Head over to http://drupal.org/project/media and download the Media Module. You will also need the latest version of the CTools module from http://drupal.org/project/ctools.


Understand the Media Module

Go to Structure > Content types > click Manage fields next to a content type.

You’ll see that a new field option called “Multimedia asset” is now available.


This field type will allow you to upload a variety of file types. Click Save and you can decide that those file types are:


If you create a “Multimedia asset” field for you content, the image below shows what it will look like when you go to add content.


Click on “Select media” and you can upload new files.


Most importantly, you can also browse a Library of all the files that you’ve uploaded.


This Library feature is the real reason for using Media. As explained on the Media FAQ page: http://groups.drupal.org/node/19746

“The Media module provides an engine that can be used to manage files and metadata. Individual Media module plugins, as well as the modules they integrate with, will handle media display.”

So the only thing this field can do at the moment is upload files to the library. If you want to actually show the files, you’ll need to rely on extra modules. Let’s see how that works.

Go to Structure > Content types > click Manage fields next to a content type. If you choose to add a File field you’ll now have a Media file selector option.


If you choose to add a Image field you’ll now have a Media file selector option.


Here’s what the Image field will look like when you go to add content.


You’ll be able to browse your new media library and insert an image just as you would do normally.


Adding Video to Content via the Media Module

Adding external videos to the Media module relies on the Embedded Media Field module: http://drupal.org/project/emfield.

That module allows you to hook into all sorts of external sites, provided you have the appropriate module. In this example, we’ll use YouTube so install this module as well: http://drupal.org/project/media_youtube.

Install and enable both of those modules.


Go to Structure > Content types and add a Multimedia asset field.


As you choose the settings, make sure to check both the Video and youtube boxes.


Save that new field.

There is one important thing you must now do to make sure that the videos display. Click on Manage Display at the top of the page.


Normally settings for the video field would be available but in this case I had to click Save before they appeared. Then you can click the cog on the right-hand side, next to the video field.


Set the File view mode to Small, Large or Original and click Update.


Click Save so that your changes aren’t lost.

Now you can go to Add content and use the new video field.


Once you’ve inserted the YouTube URL and clicked Submit, you should see a video thumbnail as in the image below.


Save the content and your video will be showing on the page.


YouTube is a simple and popular example. If you want to use other sources for video or audio, head to http://drupal.org/project/emfield and you’ll see a list of all the options and the modules that they require.


A note of caution: Media is under heavy development. There isn’t yet a stable version of Media. As of mid-February, there is a Release Candidate 3 but not yet a stable version.

Posted in Drupal7, Modules | 9 Comments »