Interactive Page Regions with Drupal 6: Part 1

Exclusive offer: get 50% off this eBook here
Drupal 6 Attachment Views

Drupal 6 Attachment Views — Save 50%

Use multiple-display views to add functionality and value to your site!

$26.99    $13.50
by J. Ayen Green | March 2010 | MySQL Content Management Drupal PHP Web Development

In this two-part article by J. Ayen Green, author of Drupal 6 Attachment Views, you will learn the following:

  • How to configure Drupal's Contact system
  • What the default Contact system does (and does not do)
  • How to add just a little pizazz to a page with an Attachment view and a module
  • How to add the Contact form to a view
  • The first steps you need to take with Drupal's module architecture and hook mechanism
  • How to modify the Contact form via a custom module
  • How to use an add-on module to make the Contact form available in a view
  • How to create an Attachment view

Lots to do—let's get started!

Activity 3-1–Configuring the contact subsystem

  1. Navigate to the Contact form admin page (admin/build/contact) and click Add category.
  2. The Contact module is installed with Drupal, but is disabled by default. This step requires that the Contact module be enabled.

  3. The Contact form will open. The information that we need to provide in it is a title in the Category field, an e-mail address in the Recipients field to which the contact e-mails should be sent.
  4. We've made a contact form available. Normally, the form would be shown on a page of its own, but we need the form to be shown in a view, and will eventually point our menu choice to the view instead of the normal contact page. The contact form isn't a node, feed, or any of the typical constituents of a view. So, how do we bring it into one? There are different approaches, but the easiest will be to use another add-on module: Content form blocks. We'll navigate to its administration page under Settings (admin/settings/contact_form_blocks).
  5. This step requires that the Contact form blocks module be installed. This step requires that the Contact form blocks module be installed. Information about this module can be found at http://drupal.org/project/contact_form_blocks.

  6. The Contact module allows you to create categories of contact, such as feedback to the administrator, contact between users, and so on. On this site, the only contact that will be enabled is from users to the site owner. There's not a whole lot to configure here, since we only have one category of contact configured, but this is where you select which contact category will be available as a form inside a block. The following screenshot shows this configuration form ready to be saved.
  7. Having saved that information, the module will have created a block for our use in the contact-us view. Go to the list of blocks (admin/build/block) and see. Remember to scroll down to the Disabled section of the list to find the block, because it's not been assigned to a region yet. Because we named the contact category General, the block will be called Contact form: General.
  8. We want to assign the block to appear in the content area of our page, but the theme we are working with has not exposed Content as a region for our use. Let's change that. In the directory sites/all/themes/acquia_slate is the file acquia_slate.info. Edit it.
  9. There is no mandatory order within a theme's .info file, but they are small enough that you should be able to find what you need at a glance. Look for a group of lines that each begin with the word 'regions,' as shown below:
  10. regions[sidebar_first] = sidebar first
    regions[sidebar_last] = sidebar last
    regions[banner] = banner
    regions[header_top] = header top
    regions[header_first] = header first
    regions[header_middle] = header middle
    regions[header_bottom] = header bottom
    regions[preface_sidebar] = front preface sidebar
    regions[content_top] = inner content top
    regions[content_bottom] = content bottom
    regions[postscript_first] = postscript first
    regions[postscript_middle] = postscript middle
    regions[postscript_last] = postscript last
    regions[footer] = footer
    regions[node_bottom] = node bottom
  11. Each of those lines defines a region to which blocks can be assigned. We need to add one. Between the regions [content_top] and regions [content_bottom] lines insert the following:
  12. regions[content] = content
  13. Save the file, and then go to the Performance page (admin/settings/performance) and click the Clear cache button.
  14. Return to the blocks page and assign the Contact block to the Content region, as shown in the following screenshot, so that it will appear along with our View content.
  15. We need to configure the block, otherwise it will appear along with every piece of content on the site. We'll click configure, and set the block to appear only on a specific page, as shown in the following screenshot. We'll need to provide the path of that page, but it doesn't exist yet. Luckily, the block administration does not validate the path. Since we'll have to do it at some point anyway, we'll create a name for our eventual view, contact-us, and use it here.

With the contact form now being hooked into a block, and the block configured to show in a single view, we need to create that view so that we can see the contact form.

Activity 3-2–Creating the contact-us view

  1. The contact-us view we're going to create is simply going to be the glue for our pieces. By using a content type to provide contact information on the page, the site owner can easily have different versions of the page to use at different times of the year (like Google does on their home page) simply by creating a new node of the Location content type and having the desired one enabled. The view will make use of that content. Go to the views page (admin/build/views) click Add, and choose to create a Node view.
  2. At this point, we're not interested in configuring the view to provide any content. In fact, what we want to do is prevent it from showing content. The reason is that the block we created, which will contain the contact form, will appear in the content region of the page showing this view. We don't need any other content at this point. However, we cannot save this view as it is, because, by default, the Row style is set to Fields, and we have no fields selected. So, click on Row style and change it to Node.
  3. Having changed the Row style to Node will allow us get past the problem of not having defined any fields, and will allow us to save the view. However, that setting without any filters in place will cause the view to select every node, whereas we want it to select none, for now. There is no filter choice for Null display, but we can accomplish the equivalent easily. Select the filter Post date and set it to a date for which we know there are no posts.
  4. Lastly, we want to create a Page display and assign a path to it, so that we can access the view. Name it contact-us.
  5. The view is ready to save. The panel settings are shown in the following screenshot.
  6. With our skeletal view saved, navigate to its path (contact-us) and get a first look at the current contact form, as shown in the following screenshot:

The location information isn't displayed at this time, because we have not yet created that content. The important thing here is the contact form. The site owner wants to capture when someone completes the form, which would not be available given only the form's current fields, namely Company, Street address, and Phone.

There isn't an admin mechanism for adding fields to the contact form, but there is a relatively easy way to do it, once you know how, and that's by creating a module.

What's a Module?

A module is how we can add our own logic to what Drupal does- to add extra functionality, or to alter the behavior of Drupal's existing functionality. With some web applications, the only way to do this is to change the existing code ('core' in Drupal parlance). The problem with that is that when a new version of the application is released, not only will those changes need to be made again to the new version, but in some cases the code you originally changed will be different in the new version, so that the changes you made originally cannot be made in the same way. Fortunately, Drupal's module architecture and the ability to hook into its events remove any need to change the core code.

Let's create a module!

Activity 3-3–The Guild Builders module

We'll go through the steps of creating our module, which will give you the basic knowledge that you need to decide whether you'd like to investigate the topic further. A module typically has up to four core files: the file core to its functionality (the .module file), a file that describes the module to Drupal (the .info file), a file that provides installation and removal instructions to Drupal (the .install file), such as for creating database tables, and sometimes included files to separate out functional parts of the module (.inc files). Our module will only require the former two.

  1. Creating the .info file. Open a text editor and add a few lines.
  2. name = GBI Custom
  3. This line defines the name of the module as it will be displayed in the modules listing in admin.
  4. package = Guild Builders Inc.
  5. We could omit this line, which would cause the module to be located in the other section of the modules listing. However, we want it to appear in a section of its own, and this line provides a title for that section.

  6. description = Custom functions
  7. The description line provides the descriptive text that appears alongside the module entry in the modules list.
  8. core = 6.x
  9. The core entry specifies which major version of Drupal the module is meant to work with, such as 5.x, 6.x, or 7.x.

  10. version = "6.x-1.0"
  11. Finally, this line specifies the version of our module. It's meant to work with Drupal 6.x and is the first version of our module, and since we will not be releasing a pre-release version (0.x), we'll make it version 1.0.
  12. Our file now looks as follows:
  13. name = GBI Custom
    package = Guild Builders Inc.
    description = Custom functions
    core = 6.x
    version = "6.x-1.0"
  14. We need to create a directory in which our module will live. We already have the path sites/all/modules in which add-on modules are placed. First, create the path _custom, in which to put our own modules, so that we can find them easily. Put the underscore at the start of the name so that it appears first in the directory list.
  15. Next, add the path guildbuilders as the home for this module. So, we now have the path sites/all/modules/_custom/guildbuilders, save our text file to that path as guildbuilders.info.
Drupal 6 Attachment Views Use multiple-display views to add functionality and value to your site!
Published: February 2010
eBook Price: $26.99
Book Price: $44.99
See more
Select your format and quantity:

Creating the .module file

  1. Open a new blank document in a text editor. Begin this one with an opening php tag, since the module file will contain php script.
  2. <?php
  3. Next, we're going to add a function. Our connection into Drupal is provided by way of a 'hook'.
  4. Drupal and Hooks

    Certain events occur, in a fixed order, whenever a Drupal web page request is fulfilled. One such event is a form being created. Drupal allows us to 'hook' into this event. It provides entry into the process at the point where the form has been created, allowing the opportunity for a module (or modules) to alter the form before it is shown. This entry point is known as form_alter, and the hook as hook_form_alter. If we create a function, replacing 'hook' in the name with our own function name, our function will be executed at the appropriate time.


    function guildbuilders_form_contact_mail_page1_alter(&$form,
    $form_state) {
  5. We could simply hook into the form_alter event, which would then invoke our function when any form in the website is ready to be displayed. We would then have to check to make sure that it is the form we want that is about to be rendered. Instead, we have used an alternate version of the hook, providing a function name that specifically identifies the form name in which we're interested. In the line, given previously, are the following components:
    1. guildbuilders: The name of our module.
    2. form_alter: The event we are hooking.
    3. contact_mail_page1: The name of the form we are hooking.
  6. The hook, form_alter, is separated in this instance, because we specify which form we're altering.

    How do you find the form name to use? Look at the page source of the page with the form, and find the

    tag. It's the ID. However, any hyphens need to be changed to underscores, so contact-mail-page1 becomes contact_mail_page1.

     

  7. Looking at the existing form, we see that the label for the name field is currently Your name. We want it, instead, to be Name. The colon is not part of the label, it is provided automatically. Let's change the field label.
  8. $form['name']['#title'] = 'Name';
  9. Likewise, change the label for the e-mail field from Your e-mail address to E-mail.
  10. $form['mail']['#title'] = 'E-mail';
  11. We're going to be changing the order of the form's existing fields, as well as specifying the order of the new fields. The existing fields have no order specified. They appear on the page in the same order in which they appear in the array. Use the key, #weight, to affect the relative field order. Start by assigning the starting weight to a variable, and to the first field.
  12. $weight = 0;
    $form['name']['#weight'] = $weight;
  13. Each field we add is, itself, an associative array, comprised of the following fields:
    • #type: The form field type, such as textfield, textarea,and so on
    • #title: The string to use for the field's label
    • #maxlength: If used, the maximum number of characters that should be allowed
    • #default-value: The value to be used if the user doesn't supply one
    • #required: True/false, signifying whether the field must have an entry
    • #weight: The order in which the field should appear compared to the others
    •  $form['company'] = array(
      '#type' => 'textfield',
      '#title' => 'Company',
      '#maxlength' => '50',
      '#default_value' => '',
      '#required' => true,
      '#weight' => ++$weight
      );
      $form['address'] = array(
      '#type' => 'textarea',
      '#title' => 'Business street address',
      '#default_value' => '',
      '#required' => false,
      '#weight' => ++$weight
      );
      $form['phone'] = array(
      '#type' => 'textfield',
      '#title' => 'Phone',
      '#maxlength' => '20',
      '#default_value' => '',
      '#required' => true,
      '#weight' => ++$weight
      );
      $form['mail']['#weight'] = ++$weight;
      $form['subject']['#weight'] = ++$weight;
      $form['message']['#weight'] = ++$weight;$form['message']
      ['#weight'] = ++$weight;
      $form['submit']['#weight'] = ++$weight; $form['submit']
      ['#weight'] = ++$weight;
      }

    We've defined each of the new fields, and assigned a weight to them, incrementing it each time. Then, we change the weight of some of the forms that were already part of the form, to move them to the bottom.

  14. One more function is needed. We've added the desired fields in the contact form, but they also should be included in the resulting e-mail. To accomplish this, we will create a function that hooks mail_alter() and adds our new fields.
  15. function guildbuilders_mail_alter(&$message) {
    if ($message['id'] == 'contact_page_mail') {
    $message['body'][] = 'Company: ' . $message['params']
    ['company'];
    $message['body'][] = 'Business Street Address: ' .
    $message['params']['address'];
    $message['body'][] = 'Phone: ' . $message['params']['phone'];
    }
    }
  16. That concludes our work on our custom module. Now we need to enable it. Go to the modules page (admin/build/modules), and enable the module.
  17. The next step requires that the Utility module be installed. Information for this module can be found at http://drupal.org/project/util.

  18. The module listing in this site is a bit different than usual, as shown in the following screenshot. The Utility module has been installed so that a weight can be assigned to a module. With our module, we will assign a weight of 99. The reason for this is that we will be using CAPTCHA with this form, and in order to ensure that the CAPTCHA field appears in the correct place on the form, we need to make sure that our fields are added after the CAPTCHA. The only way to do that is to assign a weight to our module which is higher than the weight of the CAPTCHA module.
  19. The last thing to do before trying out our module is to clear the cache (admin/settings/performance).
  20. Cache needs to be cleared to get Drupal to recognize a module, hook, or template whenever one is added or removed, but not if we've edited existing code.

  21. Having cleared the cache, once again, invoke our view. The results are shown in the following screenshot.
  22. If you are logged in when viewing the form, the e-mail field will contain your e-mail address.

>> Continue Reading Interactive Page Regions with Drupal 6: Part 2

 

[ 1 | 2 ]

If you have read this article you may be interested to view :

Drupal 6 Attachment Views Use multiple-display views to add functionality and value to your site!
Published: February 2010
eBook Price: $26.99
Book Price: $44.99
See more
Select your format and quantity:

About the Author :


J. Ayen Green

J. Ayen Green has developed software since inventing the abacus, created websites since [insert name du jour] created the Web, and has been a Drupaler somewhat longer than his current D.O. uid (you try settling on an id when your real name is Dries Webchick). A writer and columnist of sorts, a poet of metered sorts, husband, father, friend and rascal, when not plugged in Green enjoys nature, dogs, horses and other critters, kayaking, zip-lining, spicy food, the arts and other cultures. He and his wife, Sofía-Aileen, make their home in New York City.

Books From Packt


Drupal E-commerce with Ubercart 2.x
Drupal E-commerce with Ubercart 2.x

Drupal 6 Performance Tips
Drupal 6 Performance Tips

Alfresco Enterprise Content Management Implementation
Alfresco Enterprise Content Management Implementation

Joomla! 1.5: Beginner's Guide
Joomla! 1.5: Beginner's Guide

jQuery 1.4 Reference Guide
jQuery 1.4 Reference Guide

Magento 1.3: PHP Developer's Guide
Magento 1.3: PHP Developer's Guide

PHP 5 E-commerce Development
PHP 5 E-commerce Development

MySQL Admin Cookbook
MySQL Admin Cookbook


Code Download and Errata
Packt Anytime, Anywhere
Register Books
Print Upgrades
eBook Downloads
Video Support
Contact Us
Awards Voting Nominations Previous Winners
Judges Open Source CMS Hall Of Fame CMS Most Promising Open Source Project Open Source E-Commerce Applications Open Source JavaScript Library Open Source Graphics Software
Resources
Open Source CMS Hall Of Fame CMS Most Promising Open Source Project Open Source E-Commerce Applications Open Source JavaScript Library Open Source Graphics Software