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.

The Contact module is installed with Drupal, but is disabled by default. This step requires that the Contact module be enabled.

2. 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.



3. 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).

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.

4. 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.



5. 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.
6. 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.
7. 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:

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

8. 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:

regions[content] = content

9. Save the file, and then go to the Performance page (admin/settings/performance) and click the Clear cache button.
10. 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.



11. 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.

name = GBI Custom

2. This line defines the name of the module as it will be displayed in the modules listing in admin.

package = Guild Builders Inc.

3. 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.

description = Custom functions

4. The description line provides the descriptive text that appears alongside the module entry in the modules list.

core = 6.x

5. 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.

version = "6.x-1.0"

6. 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.
7. Our file now looks as follows:

name = GBI Custom
package = Guild Builders Inc.
description = Custom functions
core = 6.x
version = "6.x-1.0"

8. 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.
9. 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.