Several students on work-study at Epic University have been tasked with building a job posting website for their school. The university needs to have the site built in a short amount of time (not to mention cheaply) on its internal servers. Because of its flexible entity and field system, user management, and low cost, the students chose to download Drupal and get started building a site.

The Human Resources department requires that university faculty be able to post job openings, which include a description, department, contact person, and salary information. Users should be able to sign into the site and view both a list of all available openings and lists of openings within a single, specific department. Additionally, users should be able to apply for a specific position, and to view a record of all positions to which they’ve applied.

The Field module provides an extremely flexible framework for creating forms to enter content. The ability to add custom fields to forms is a new feature in core for Drupal 7. In Drupal 6, all of this functionality was provided by the Content Construction Kit (CCK) module. Most of CCK is now integrated into core, but there is still a contributed CCK module in Drupal 7. The main reason for this is to provide an upgrade path for Drupal 6’s CCK fields to Drupal 7’s core fields. Since we are not upgrading, but instead building a new Drupal 7 site, we won’t need CCK for this project.

Upon installing a new copy of Drupal, you’ll see two content types provided: “Article” and “Basic page.” They both have a Title and Body, which are the basic fields provided when you create a content type. Any additional content types that are created will also contain a Title field and (optionally) a Body field.

Using the Field and Field UI modules, pictured in Figure 3-2, you may add any number of custom fields to any content type. Combined with the ability to create custom content types, core lets you create completely customized forms for adding content. Figure 3-3 shows the “Basic page” form after we’ve added a few custom fields, such as an additional text field, an image field, and a set of radio buttons.

Figure 3-2. The Field UI module provides the ability to add fields to entities, including nodes, comments, and users

Figure 3-3. The “Basic page” content type form, after adding custom fields

Another new feature in Drupal 7 is the ability to add fields to any entity in the system: users, comments, and taxonomy terms, with more options offered in contrib through the means of modules such as File Entity or Drupal Commerce. For example, it’s now possible to add tags to users, or attach an upload field to comments.

When it comes to actually using fields, it is important to understand the various pieces involved. There are three main concepts to cover: field types, widgets, and displays.

Displays, View Modes, and Formatters

Complementing the configuration of how field data is input, you can also determine how field data is output and displayed to end users. There are two aspects to configuring fields’ display: configuring the output of the individual field (such as where its field label is displayed and how its value should be shown), and configuring the overall way in which fields are shown when viewed in certain contexts.

Each type of entity presents one or more view modes (e.g., RSS feed, search results, teaser, or full view) and can be configured to show or hide certain fields or change their output depending on the context in which the entity is being viewed. You can either configure default settings applicable to all view modes, or override the defaults by providing a custom display setting for one or more specific view modes. By default, Drupal provides a custom display override for node teasers to change how your fields are displayed on full content (and RSS and search results pages) versus on the teaser view on the default home page. This also means, however, that if you want the fields to look the same in both view modes, you have to update both the Default settings and the Teaser settings—custom display settings do not inherit the default display settings.

In Figure 3-4, you can see the Manage Display tab for the core “Basic page” content type, which shows the Teaser custom display settings enabled. Once a custom display is enabled, a new subtab will appear in the upper-right corner of the settings page.

Figure 3-4. Manage Display settings with custom Teaser tab

Table 3-3 contains a list of default view modes provided by Drupal core’s entities, and like everything else in Drupal, contributed modules can provide additional view modes. There are two subtabs on this page, Default and Teaser. The Default settings will control the look of the content for all view modes, except those that are checked off in the Custom Display Settings fieldset at the bottom of the page. By default, core enables one custom display: the Teaser. So with the default core settings, the changing settings on the Default tab will control how the fields look on the Full content, RSS, Search index, and Search results displays.

Content types on your site have a settings page to manage its display settings, which you can access by going to the administrative toolbar and clicking Structure→“Content types” and then clicking the “Manage display” link for your desired content type (admin/structure/types/manage/<content type name>/display). Other entities expose this same screen closer to their own configuration pages. For example, the field display management screen for user accounts is at Configuration→People→“Account settings”→“Manage display” (admin/config/people/accounts/display).

Table 3-3. Default view modes provided by Drupal core, and the entities to which they can apply

View mode	Entities	Description
Default	All	This type of display is the fallback, and will be used if no better matching view mode is found. In general, it’s best to stick to the defaults if you can, because once you’ve customized another view mode, keeping things in sync means changing the display configuration in multiple places.
Full content	Node	This view mode is used when a node is being displayed with all of its associated data, like on the http://example.com/node/1 page.
Teaser	Node	This view mode is used when a node is being displayed in the trimmed or summary view, like on the default home page at http://example.com/node.
RSS	Node	This view mode is used with a piece of content in an RSS feed like the home page’s http://example.com/rss.xml.
Search index	Node	This view mode controls which fields are searchable. It can be useful to hide fields from the search index view mode in order to provide better search results.
Search result	Node	This view mode controls which fields will display on a search result page.
Full comment	Comment	Comments do not have teasers. This view mode represents when the entire comment is being viewed, such as on a http://example.com/node/1 page.
Taxonomy term page	Taxonomy	For taxonomy terms, this view mode dictates which vocabulary fields will appear on a taxonomy listing page such as http://example.com/taxonomy/term/1.
User account	User	For users, this view mode shows fields on the user profile, on pages such as http://example.com/user/1.

Within each display settings page, you control the output of the fields using formatters. For example, long text with summary fields can be displayed as the full text or the summary, or hidden altogether, as seen in Figure 3-5. A full list of fields and the formatting options they provide can be found in Table 3-4.

Figure 3-5. Configuring the display of a field formatter

Other modules may add other formatters, giving you a plethora of ways to display information. The core “Image styles” feature, covered in Chapter 4, is an example; it allows the display of thumbnail or full images, and provides those display options as formatters for Image fields.

Keep in mind that the formatters available depend on the type of data, once again making it very important to choose your field type wisely. For example, set up a field as an integer, decimal, or float if you’ll be displaying numbers.

Table 3-4. Fields and the field formatters they have available

Field type(s)	Formatters available
Boolean, List (float), List (integer), List (text)	Either display the label on the field selection (default), or the actual key stored in the database, such as 0 or 1 (key).
Decimal, Float, Integer	Specify how to show the thousands separator (decimal point, comma, space) and specify whether to show the field prefix/suffix (such as $). For float and decimal fields, specify the decimal marker (decimal point, comma) and scale (digits after the decimal point). Can also display the raw, unformatted value.
File	Files can be shown as a filename linked to the file, a table containing the file link as well as the file size, or simply the raw URL to download the file.
Image	Specify the image style (original, thumbnail, medium, large) and whether to link the image to the uploaded file or the piece of content to which it’s attached.
Text, Long text, Long text and Summary	Display the field contents as formatted text (default), plain text, or text trimmed to a certain character length.

Reusing Existing Fields

Once you have created a field to add to an entity, you can reuse that field in other entities. This can be a useful time saver, and also allows you to create listing pages of multiple content types that share the same field, once we start talking about Views.

There are two “classes” of configuration on fields:

• Field-specific settings, which specify the field type and other options that dictate its database storage, such as the field length and the number of values it can store.

• Instance-specific settings, which dictate options used only on this field in the context of a particular entity or content type. Examples are its field label, the type of widget to present to admins, and whether or not the field is required.

Reusing a field on a different entity requires you to keep the same field type and name, as well as anything else under “[field] settings,” but you can customize the field for each different instance by using the “[entity type] settings” for the field. You can see how this looks on a Department field on a Job content type in the configuration screens shown in Figures 3-6 and 3-7.

The Job Settings section indicates how this field will look and behave only on the Job content type. The Department Field Settings section determines the global settings for this field, no matter which content type it is used in. In this example, we have a Job content type with a Department select list field. We can reuse the Department field as many times as we like, but the Department field settings, which in this example determine the list of departments to choose from, will be the same across all instances of the field. However, we can change, per instance, settings such as the label, and whether it is required, the help text, and the default value.

Reusing fields can be very helpful if you need to use the same information across multiple entities. However, it can also be restrictive if you’re trying to customize elements such as the allowed values for the field per instance. Make sure you only reuse fields when the instances are really identical.

Figure 3-6. Field settings that are specific to the content type

Figure 3-7. Field settings that are global for all uses of this field

To get started with our job posting website, let’s think about the different content types needed to build all the functionality that we require. The site requires two different types:

We will need to relate job applications back to the appropriate job openings, as well as relate jobs back to the appropriate contact person. The node reference and user reference fields provided by the contributed References module, mentioned earlier in the chapter, will be an essential tool.

To build this site, we’ll need to go beyond the default “Basic page” and “Article” content types offered by Drupal core. When you’re building out content types in Drupal, it’s best to start with a mental picture of what the form looks like that you’re trying to build. Figure 3-8 shows a sketch of both the job and job application forms that we’re shooting for.

Figure 3-8. A mockup of the forms required for the job website

The Job content type will contain all the information we need to store about a particular position that’s available at Epic University. It will need the following core fields:

Let’s walk through the steps to create this new content type with the core fields we have available. We’ll get to noncore fields later in the chapter.

Figure 3-9. Adding a new Job content type

The References module is a contributed module that allows you to create relationships between nodes and/or users. When you download References, you will see that you actually have a package of several modules: References, Node Reference, and User Reference. References is the central module and is required by the other two. The Node and User Reference modules provide the actual fields that you can use to add to your site. In Drupal 6, these modules were included as part of the main CCK package.

Creating a reference field comes in very handy when you have content that has a relationship to another piece of content. A classic example of this would be a music site. You can have three content types: Artist, Album, and Song, which are obviously related to each other, but each is a unique kind of content that has different fields. If we use a Node Reference field in these content types, we can identify which Album node a Song node “belongs” to, and likewise we can identify which Artist node an Album “belongs” to. Using References, we can reuse the information we already have (Artist and Album nodes) instead of having to re-enter those values each time we create a new song. Once we create these references, we can easily display that information on the content type itself, and we can use that relationship within Views to create custom lists of related content. So we can have an Artist node that displays all of the albums for that artist, and the Album nodes can display all of the songs, or we can use Views to list all of the songs by a particular artist. You can do the same thing with users on your site using the User Reference module.

Now we need to add a primary contact for this job position. This will usually be the person creating the entry, but we’ll allow the user to enter any of the possible faculty members on the site. This will be done as a “User reference” field, provided by the contributed References module. References is included in the source code that accompanies this book, so if you are using the source code, you can just enable the modules. If you are not using the source code, you should get a copy of the References module and add it to your site, as explained in Chapter 2.

When finished, your completed Job content type should look as pictured in Figure 3-13.

Figure 3-13. Job content type with Department, Salary, and Contact fields

For usability, it’s often important to display forms and page contents in a specific order, and to add formatting so that it’s more clear what data is being presented. The following steps will take you through some minor customizations to the way fields are displayed.

Let’s take a look at what all of our hard work has accomplished so far. Navigate to “Add content”→Job (node/add/job), from either the Shortcut bar or the Navigation menu. It should look as pictured in Figure 3-14.

Figure 3-14. The Create Job form with no display customization

This works for basic data entry, but there are a few things that we could do to make our job posting board more intuitive for our faculty members:

This section will cover how to make these sorts of cosmetic changes to fields.

Taking a look at the content after it’s created, we’ll see that it’s not entirely pretty. Figure 3-17 shows the default output of our Job type when we view the content. The department is still listed underneath our description; the labels are included above each field, making the page longer than it needs to be; and the salary could really use a comma. Fortunately, we can use Field Formatters to change the display of the job content a bit more to our liking.

Figure 3-16. The Job form as seen by a user in the “editor” role

Figure 3-17. Default output of the Job content type

Now you can see that our labels are displayed next to the values, rather than on a separate line. A comma is automatically placed in the correct location for the Salary field. Nice!

Figure 3-19. Job content after configuring the field display

The last step is to fix up our Teaser display as well, since that has its own custom settings and won’t automatically inherit the defaults we just set. We can also make some subtle changes in the display for that view mode.

Now that the university is able to create job positions, it would be helpful if prospective employees could submit résumés to the positions in which they’re interested. We’ll create another content type for this purpose, called Job Application.

That finishes the configuration of the form for the Job Application content type. Let’s take a look at the finished form as a user in the “authenticated user” role. After logging in with the username user and password oreilly, create a new application by clicking “Add content”→Job Application (node/add/job-application) in the sidebar. The form should look as shown in Figure 3-22.

Figure 3-22. The job application form, as seen by any authenticated user

Because job applications won’t be as visually important as job listings, we’ll skip configuring the display options for this content type. But if you’re feeling sparky, you can still make these changes by logging back in as the administrator, going to the administrative toolbar and clicking Structure→“Content types,” and then clicking the “Manage display” link for the Job Application content type (admin/structure/types/manage/job-application/display). After a user creates a new job application, it should look something like Figure 3-23.

Figure 3-23. A job application piece of content

An important thing to note in Figure 3-23 is how our node reference field (Job) appears when given a value. The default behavior is a link to the original piece of content that is referenced. Clicking on the Alumni Director link from this application will take us back to the Alumni Director job. There are other ways to display node reference fields as well, which can be explored in the “Manage display” tab on the Job Application type (admin/structure/types/manage/job-application/display).

The Views module provides listings of data on your site: users, comments, nodes, and more. Any listing of data provided by the Views module is called a view, which we’ll always refer to in all lowercase to distinguish it from the Views module, which is capitalized. Figure 3-24 shows examples of some of the listings that can be built with the Views module.

Figure 3-24. Several types of views created by the Views module are visible on Grammy.com

Creating a basic view entails selecting the fields you would like displayed (node title, author name, image, etc.), how you would like that list to be filtered (only display “story” node types that are published), how you would like the listing to be sorted (newest stories on top), and what you would like the list to look like when it’s displayed (a block showing a bulleted list of headlines).

In more technical terms, Views is a visual SQL query builder. When you build a view, you are essentially constructing a query that Views will pull from your site database. However, the Views module has significant advantages over a handcoded query. Some examples:

More than anything else, Views can significantly speed up the development of your site, without your having to learn module development or a single line of PHP. Views can form the backbone of outputting content on your site.

SELECT title FROM node WHERE nid = 10

SELECT [fields]
FROM [base data type and any relationships]
WHERE [filters or contextual filters]
ORDER BY [sort criteria]

The typical way to create a new view is to go through a one-page wizard that sets up the most common settings used in views. You can either stop there and use the results of the wizard, or you can continue with a more advanced configuration of the basic view that has been created so far. Figure 3-25 shows the wizard interface. The full Views interface is pictured in Figure 3-26.

Figure 3-25. The wizard interface for building a basic view

Data Types

When building a view, the first thing that you will need to determine is exactly what sort of “stuff” is going to compose your list. In the background, Views is building database queries and, just as if you were writing some SQL by hand, you need to start with an idea of what the central data in your query is going to be. You have a lot of different kinds of data in your Drupal site. Content and users are probably the two most easily recognized and most often used, but you can also build lists of taxonomy terms, files, comments, and more. You need to select your data type when you start building your view, which you do in the wizard, where it states Show and provides a select list of data types you can list, as shown in Figure 3-27.

Warning

You will notice that once you select a data type, you can’t change it in the main Views interface, as you can for the other settings you select on the wizard page. The view name and data type are key information, and the only way to change those settings is to build the view over again from the start.

Figure 3-26. The full Views setting interface

Figure 3-27. Selecting a data type for building a view

Once you select your base data type, the interface will provide the correct options to build your list for that data type. Different kinds of data have different properties that Views can use. You can also tie in additional information from other data types as you build your view, using relationships. For example, I may want a list of content on the site, but that list can be enhanced further by gathering more information about the users who created the content and adding the user data to the view as well. We’ll talk more about relationships and how to use them later, in Relationships.

Displays

A display determines how a view will be presented to the user. A view can have multiple displays, and can even create several pages listing the same content in different ways. The upper-left corner of the Views interface lets you choose which display you are editing. Figure 3-28 shows adding a new display to a view.

Figure 3-28. Adding a new display

By default, there are four different kinds of displays, each serving a particular purpose. Other modules may also add extra display types:

Attachment

Think of attachments as essentially subviews: a supplementary display that can be attached above and/or below other types of displays. This display type can be helpful for giving a view context or adding a glossary when your view is being filtered. An example could be a view displaying a list of tracks beneath a view displaying albums.

Block

You can position views exposed as blocks in sidebars or any region from the Blocks configuration page by going to the administration toolbar and clicking Structure→Blocks (admin/structure/block).

Feed

The Feed display type creates a customizable RSS feed to which users may subscribe using an RSS reader. Feeds can both receive their own URL and be attached to any block or page display.

Page

Makes a page with its own URL in which the view occupies the main content.

The Views module provides many exciting options to easily configure the display of your content. The settings for the first display you create will also be the default settings for any future displays; however, each display can have its own settings that override the view defaults. To change any value within the Views interface, click the option represented as a link, and the configuration for that option will appear in a pop-up modal screen. Figure 3-29 depicts the settings for all displays versus an override for a specific display, along with an example of italicized text being used to indicate an overridden value.

Figure 3-29. Configuration when overriding a default value

Warning

Pay very close attention to whether the font for an option in the Views administration screen is italicized. Italics indicate that a setting is being overridden for that particular display, meaning that changes to it will only affect the given Page or Block. You must specifically override settings on displays; otherwise, they will affect the defaults—and thus all other non-overridden displays—regardless of which display is currently selected.

It’s also important to pay attention to the particular display you are editing, as the settings change slightly between display types. Some of the most important configuration options for a view are available only when you are configuring a particular display. For example, to set a URL for a Page view, you have to be configuring a view’s Page display. The URL is presented as an option within the Page settings, displayed in the middle column of the interface. The display-specific section for a Page view is shown in Figure 3-30.

Figure 3-30. The available settings may change, depending on the display type that is being edited

One other thing to be aware of in the Views interface is how you add and rearrange the data settings. There is an “add” button on some sections for adding items. You will also notice that the “add” button sometimes has a small down arrow next to it. If you click the arrow instead of the word “add,” you will see more options, like “rearrange” for the ordering of fields, or “and/or” for determining the logic of your filters. You can see an example of this interface in Figure 3-31.

Figure 3-31. Adding data items and accessing additional actions

OK! Enough conceptual mumbo-jumbo; let’s start getting our hands dirty with Views!

The requirements of our site include two particular views. One view is frontend-facing, showing all the available jobs to users of the site. Faculty users (more specifically, users in the “editor” role) will use the second view to review the list of applicants who have applied to various jobs.

The first step to using the Views module is to enable it. The Views module has two parts: the Views module itself, which handles the low-level “plumbing,” and the Views UI module, which presents the screens used to configure the views. Additionally, “Advanced help” is an optional module that provides useful inline help for modules such as Views.

Jobs View

The “jobs” view will provide a listing of jobs at Epic University, categorized by department. The completed view will be similar to the one pictured in Figure 3-32.

Figure 3-32. A sample page from the jobs view, listing jobs in the Sciences department

1. Get started by visiting the Views configuration page by going to the administrative toolbar and clicking Structure→Views (admin/structure/views).

2. Click the “Add new view” link at the top of the page, as shown in Figure 3-33, and populate the form with the values from Table 3-19. This screen is designed to set up the most common things used in a view. Your screen should look as pictured in Figure 3-34. These initial settings will provide us with a view that shows a listing of jobs, with its information displayed in a table, and a pager to move from one page of results to another if there are more than 10 items. It will also have a menu item in the Main Menu, which leads to a page showing the view. Lastly, we are adding an RSS feed so people can follow the latest job postings with an RSS feed reader.

   

   Figure 3-33. Add a new view

   

   Figure 3-34. Initial view information

   Table 3-19. The Jobs view configuration values

   View setting	Value
   View name	Jobs
   Description	Checked; “A list of available positions at Epic University”
   Show	Content of type Job sorted by Newest first
   Create a page	Checked (default)
   Create a block	Unchecked (default)
   Page settings
   Page title	Available positions
   Path	jobs (default)
   Display format	Table of fields
   Items to display	10 (default)
   Use a pager	Checked (default)
   Create a menu link	Checked; Menu: Main menu; Link text: Available positions
   Include an RSS feed	Checked; Feed path: jobs.xml (default)

3. After clicking the “Continue & edit” button, Views takes you to the main view-building interface, where we will tweak some of our settings to refine the view. Scroll down to the bottom of the page, and you’ll see a live preview of what your view shows so far. Excellent!

4. When we created the view, we selected the Table display format, and the wizard automatically filled in that we would use fields. It didn’t let us choose which fields, though, and by default it only provides the Title field in the view. However, we definitely want more information than that. Let’s correct this problem by adding a few fields to the view. We want to display the Title, Post date, Salary, and Contact for each job.

5. Click the “add” button in the Fields area to start adding new fields. Include the fields from Table 3-20, as pictured in Figure 3-35. To speed up entry, you can select Content from the Filter selection to filter the list of available fields by only those pertaining to that group, or start entering characters in the Search field to limit the results. Note that we already have our Title field, so we just need to add the other three.

   Table 3-20. Fields for the Jobs view

   Fields: Add Fields	Value
   Content: Contact	Checked
   Content: Post date	Checked
   Content: Salary	Checked

   

   Figure 3-35. Fields for the Jobs view

6. After you click the “Apply (all displays)” button, Views will display the configuration forms for each field, one by one, to allow you to configure each field’s options. When you’re finished entering each of the values from Table 3-21 and pictured in Figure 3-36, click the “Apply (all displays)” button to proceed to the next field’s settings. The values listed in Table 3-21 assume you will leave the rest of the fields’ default settings in place and only make the modifications indicated in the table.

   Table 3-21. Individual field configuration for the Jobs view

   Defaults: Configure field setting	Value
   Content: Contact	(Leave the defaults)
   Content: Post date	Date format: Time ago (with “ago” appended)
   Content: Salary	Thousand marker: Comma

   

   Figure 3-36. Field configuration for the Jobs view

7. Click the drop-down arrow next to the “add” button in the Fields section, select the “rearrange” item, and drag the fields in the following order, as pictured in Figure 3-37:

   • Content: Title

   • Content: Post date

   • Content: Salary

   • Content: Contact

   

   Figure 3-37. Rearrange fields for the Jobs view

   Once you have rearranged the fields, click the “Apply (all displays)” button to save your changes.

8. Now that our view has fields, you should save the view by clicking the Save button. If this button is grayed out, be sure to finish editing whatever field you’re editing; then the button will be activated again.

9. At this point, we can pause and take a look at our view so far. If you scroll down the view edit screen, at the bottom, you will see a preview area. It automatically updates as we change the settings for the view. Our view currently looks a lot more table-like, as pictured in Figure 3-38 (with some sample content in it).

   

   Figure 3-38. The Jobs view preview

10. Our view is coming along nicely. One thing that we did not include was a Department field in this listing, because our requirements actually call for a directory-type listing. That is, the first page of our Jobs view should display a list of departments, and then clicking on the department should provide a list of jobs inside. Because it would be tedious to create a view like this for each department, we’ll accomplish this requirement with a contextual filter, a very powerful Views feature.

    To get started implementing this directory-type listing, we’re going to go into the Advanced section of the Views editor. Click on the Advanced fieldset to open the settings, and then click the “add” button next to Contextual Filters. As before with fields, you can search or filter to narrow the list of items. Select “Content: Department (field_department)” from the list and click the “Apply (all displays)” button. Then enter the settings from Table 3-22, as shown in Figure 3-39.

    These settings will look like total gobbledygook at the moment, so let’s step through them. What we’re after is a directory at http://www.example.com/jobs/<department> which, if no department is specified, will show a list of departments along with the total number of jobs they offer.

    The “When the filter value is not in the URL” section indicates what the view should do when the URL http://www.example.com/jobs is accessed, rather than http://www.example.com/jobs/athletics. Here, we are asking it to display a list of department names in ascending order. The Summary style will display the titles of the various departments, along with the number of jobs within that department next to it. This type of view can be very useful for directory listings. The Views module also allows you to control how the dynamic URL and title are displayed. The “%1” in the Title looks a bit funny; this will be replaced by the department name dynamically when the page is viewed (%1 means “the first context value for this view”).

    Finally, we do some path transformations to keep URLs consistently lowercase and dash-ified, even if the “real” department name contains capital letters and spaces.

    Table 3-22. Contextual filters for the Jobs view

    Setting	Values
    When the filter value is not in the URL	Display a summary (checking this will expose a bunch of other settings, but they can be safely ignored)
    When the filter value is in the URL or a default is provided	Override title: Checked (in the text field that appears, enter “Jobs in the %1 Department”)
    More	Case: Capitalize each word Case in path: Lower case Transform spaces to dashes in URL: checked

    

    Figure 3-39. Contextual filters configuration for the Jobs view

    Be sure to save the view when you’re done.

Note

We added only one contextual filter in our Jobs view. But you can add as many contextual filters as you like. They don’t even have to be the same type. This way, you can get multipage structures, each drilling down additionally on the items that should appear in a list.

We’re now finished with the Jobs view! The final view screen should look as pictured in Figure 3-40. Take a look at our view by closing the overlay and clicking the new “Available positions” link in the Main menu. After we add this contextual filter, our view contains a nice hierarchical structure! It should be similar to Figure 3-41.

Figure 3-40. Completed Jobs view configuration

Figure 3-41. The root level of the Jobs view, with a summary display contextual filter

Clicking on any of the options will take you to a filtered listing within that category, such as in Figure 3-42. Pay attention to the URL also as you move between pages. It should be similar to http://www.example.com/jobs/administration or http://www.example.com/jobs/athletics. This is the way arguments work in Views: the path we specify displays the summary view, then any “directories” (such as administration) under that URL are taken as arguments.

Figure 3-42. Inside the Filtered view, when the context “sciences” is passed in

This concludes our introductory view, where we’ve used several features of Views. This example used a Page display, added some fields, and used contextual filters in a simple manner. In our next example, we’ll create a view that uses multiple displays, and gets a little bit trickier.

Applications View

The Applications view will serve both as a tool for administrators and as a reference for users. It will provide the following displays:

• A listing of all job applications in the entire system as a single page

• A listing of all applications for a particular job, displayed as a tab on the job page

• A listing of applications filled out by the currently logged-in user, displayed as a block in the sidebar

Taking all these pieces together, the final view should display something similar to Figure 3-43.

Figure 3-43. The multiple displays of the Applications view

Create the view and default display

In this view, we’ll be setting up several displays and then overriding the defaults within each display. By setting up a large amount of the configuration in the default display, we’ll save work when we need to change properties that are common to all displays.

1. Start by getting to the Views administration area by going to the administrative toolbar and Structure→Views (admin/structure/views). Click the “Add new view” link, and enter the settings from Table 3-23 into the wizard, then click “Continue & edit”.

   Table 3-23. Add view settings for the Applications view

   View setting	Value
   View name	Applications
   Description	Checked; “A list of submitted applications, by job or user”
   Show	Content of type Job application sorted by Newest first
   Create a page	Checked
   Create a block	Unchecked
   Page settings
   Page title	Applications (default)
   Path	applications (default)
   Display format	Table of fields
   Items to display	10 (default)
   Use a pager	Checked (default)
   Create a menu link	Checked; Menu: Navigation menu; Link text: Applications (default)
   Include an RSS feed	Unchecked (default)

2. Now we’ll set up some default fields. Click the “add” button in the Fields area. Check off the fields described in Table 3-24 and click “Apply (all displays).” Then configure each field’s settings, clicking “Apply (all displays)” once again after each screen.

   Table 3-24. Default fields for the Applications view

   Defaults: Field	Values
   Content: Job	(leave the defaults)
   Content: Post date	Label: Application date Date format: Short format: 12/04/2011 - 9:30

There is one more field that would be very useful in this view: the name of the user who submitted the application. If we look for the username in the list of fields we can use, though, we won’t find it. The closest field in the list is “Content: Author uid,” and the help text underneath it states “The user authoring the content. If you need more fields than the uid add the content: author relationship.” The uid is only a number, like 4 or 206, and isn’t really that helpful. We do want more fields than the user ID number—we want the name—so we will need a new Views module trick that we haven’t used yet: Relationships. Figure 3-44 shows a diagram of how relationships work. All of our Job Application nodes have an author uid associated with them. We can use that ID to connect with the rest of the user information in the database, and then pull out the bits we want once we’ve created the connection.

Figure 3-44. If two objects share a bond, Relationships can pull in data from one to another

1. Using relationships is a two-part process.

   First, you must identify the relationship—that is, tell Views what your connector piece is, and second, you will need to use that relationship to add the fields or other data that you want to the view. Let’s create a new relationship we can use. Open the Advanced fieldset to expose more settings, and click the “add” button next to Relationships. “Select Content: Author” and click the “Apply (all displays)” button. Since all content will have an author, we can make the resulting query more efficient by checking the “Require this relationship” checkbox. Click “Apply (all displays)” once more, and that’s all there is to it. We have added in the relationship, and now we can start using it.

2. Click the “add” button in the Fields section once again, and this time you will see more options than before. There is now a whole group of fields available in the User group. Select the User: Name field and click “Apply (all displays).” You will see that it is using the relationship we just created. Change the field’s Label to Applicant Name and click “Apply (all displays)” again.

3. We now have all of the fields that we want for our view. Click the down arrow next to the “add” button and select “rearrange.” Put the fields in the following order and click “Apply (all displays)”:

   • Content: Post date

   • Content: Title

   • (author) User: Name

   • Content: Job

4. Now we need to change one last, very important setting. The default access to this view is set to allow anyone with the “View published content” permission to see the view, but we want to allow only “editor” members on the site to have access to review all the applications. This is also why we put the menu item for this view in the Navigation menu and not the Main menu, meant for all users. In the Page settings section, click the “Access: Permission” link. Use the settings from Table 3-25 to restrict access to this display and click “Apply (all displays).” When you’ve finished, the settings should look as pictured in Figure 3-45.

   Table 3-25. Page display access restrictions for the Applications view

   Settings	Values
   Access restrictions	Role
   Role	editor

   

   Figure 3-45. The Applications view so far

   Warning

   Restricting access to the view only prevents unprivileged users from accessing the view display at http://www.example.com/applications; it does not prevent an unprivileged user from typing in http://www.example.com/node/4, where node 4 is a job application that is not hers. Protecting this kind of node-level access control requires the use of a node access module. See Taking It Further for some suggestions on resolving access concerns.

5. Save the progress on the Applications view by clicking the Save button.

This concludes the default configuration of the Applications view. We have a basic view of applications on the site, which are displayed in a page, with a menu item in the Main menu, as pictured in Figure 3-46.

Figure 3-46. The Applications view page display in action

Create the Job Tab display

We’ve created a page containing all the applications on the entire site. Although this might be helpful for watching incoming applications, it’s not entirely helpful for our jobs’ contact people, who will be primarily interested in only the applications posted to one job. To fill this need, we’ll make a display that limits the applications to just one job, using a contextual filter. We’ll also need to create a new relationship to connect the application to the job being applied for so the contextual filter has something to work with. To make this page easy to find, we’ll add it as a tab on the job node pages (see Figure 3-47).

Figure 3-47. The Applications view displayed as a tab on a job node

If you’ve left the Views administration area, return to it by going to the administrative toolbar and clicking Administer→Structure→Views→Applications→Edit (admin/structure/views/view/applications/edit).

1. Click the “+ Add” link in the Displays bar, as shown in Figure 3-48, and select Page.

   

   Figure 3-48. Adding a new Page display to the Applications view

2. The new display gets the name Page by default. To help distinguish it from the original Page display we created, we’ll rename it to Job Tab, because this page will be displayed as a tab on job nodes. Click the Page link next to “Display name” just below, change it to Job Tab, and then click Apply.

3. To display the information required on this tab, we will need to override our default settings. We need to have a relationship to the job to which the applicant is applying, and a contextual filter to bring in the job ID. However, these settings are specific to this one display, and should not affect the default page we already set up.

   Fortunately, Views solves this with its display overrides concept. At the top of the configuration screen for each of our Views elements, there is a drop-down preceded by the word “For.” This defaults to “All displays” with the assumption that we want to update the settings across all of our view’s displays. To limit our changes to just this display, we need to select the override option, as pictured in Figure 3-49.

   

   Figure 3-49. Override settings for a View

4. First, let’s add a relationship to the application’s job so we can pull the job’s elements into our view. Open the Advanced fieldset, click the “add” button for Relationships, add the settings from Table 3-26 (shown in Figure 3-50), and click “Apply (this display).”

   Table 3-26. Default relationships for the Applications view

   Defaults: Relationships	Values
   Content: Job (field_job)	For: This page (override) Require this relationship: Checked

   Once you have applied your changes, you will see that you have an active override in the Views editor, indicated by the section title (Relationships, in this case) being italicized, as pictured in Figure 3-51).

   

   Figure 3-50. Relationship configuration for the Job Tab

   

   Figure 3-51. Overriding the Relationships portion of a view

5. Similar to the Jobs view that we configured earlier, we can filter down the listing of applications by adding a contextual filter to the display. We’ll add a contextual filter that filters the list of applications to a single job node. Click the “add” button for “Contextual filters,” select “Content: Nid,” and use the values from Table 3-27. Remember to override these settings for just this display. The Content Nid contextual filter allows us to filter by one particular job’s ID. Here we’re using another feature of Views’ contextual filters: a validator. Views will check the node ID passed in to the URL and verify that it belongs to a job node. Click “Apply (this display)” when done.

   Table 3-27. The Job Tab “Content: Nid” settings for the Applications view

   Settings	Values
   For	This page (override)
   Relationship	field_job
   When the filter value is not in the URL	Display contents of “No results found”
   When the filter value is in the URL or a default is provided	Override title: Checked; “Job Applications for %1” Specify validation criteria: Checked Validator: Content Content Types: Job Validate user has access to the content: Checked

6. We set our view to “Display contents of ‘No results found’,” but this is blank by default. Let’s add something more useful there. Click the “add” button next to No Results Behavior (right under Relationships). Select “Global: Text area” and enter the following text: “No applications have been submitted.” Then, click “Apply (all displays).”

7. Now that we’ve set up an argument for this display, we need to give it a URL. Use the settings from Table 3-28 to set up the Page settings and click Apply. We don’t need to worry about overriding here, because these settings are always per display.

   Table 3-28. Job Tab display page settings

   Job Tab: Page settings	Values
   Path	node/%/applications
   Menu	Type: Menu tab Title: Applications

   Similar to using %1 in the title of the contextual filter, we’re using the percent symbol to specify that the first context value will be in the middle of the URL. You can use this approach to add tabs to user pages also, such as user/%/my_display, or any other page in Drupal with a dynamic path.

8. And finally, we no longer need the Job listed on this display; it would be redundant, as we’ll be looking at the job directly. Click the drop-down arrow next to the “add” button in the Fields section, and select “rearrange.” Override this section for this display by changing the For field to “This page (override).” Then click the “remove” link for the Content: Job Job field, and click “Apply (this display)” to save your changes.

   Warning

   If you want behavior specific to one display and not others, be sure to change the For setting to “For: This page (override).” The Views module’s settings default to affecting all displays within that view. You can end up accidentally deleting this field from more than one display if you’re not in override mode. If that happens, you will need to add the field back to the main Page display, and then remove it again from the Job Tab display.

9. Click the Save button to save the view, which should now look like Figure 3-52.

   

   Figure 3-52. Applications view with new Job tab

We’ve now added a tab to all job nodes (for users in the “editor” role). Visiting a node that has applications should look similar to Figure 3-47, shown earlier.

Create the Applications block display

The last display that we’re going to assemble will be available to all users of the site. It will be a block that will show all the job applications that the currently logged-in user has submitted on the site. We’ll also change the style of this display from a table to a list layout, because it will need to be displayed in the narrower sidebar column. The final display will look similar to Figure 3-53.

Figure 3-53. The front page with the User Applications display as a block in the right sidebar

If you have left the Views configuration screen, return to the Applications view by going to the administrative toolbar and clicking Structure→Views→Applications→Edit (admin/structure/views/view/applications/edit). We’ll start by adding a new display to this view:

1. Click the “+ Add” link in the Displays bar and select Block from the display list.

2. Now we’ll need to override some settings. Click the Title link to see the configuration screen, change For to “This block (override),” and change the title to My Applications. Click “Apply (this display).”

3. Change the Format to an unordered list by clicking the Table link in the Format section, and once again changing For to “This block (override),” and selecting “HTML list” as the format. Click “Apply (this display).” We can keep the default configuration, so just click “Apply (this display)” again to complete the change.

4. Now configure a description on the block that will show up in the block administration area. Under “Block settings,” enter a block name of User Applications and click Apply.

We’ve now set essentially three names or titles for this block. Here’s a rundown of where each title will be displayed:

Display Name

Used within the Views interface as the name of the display. Shown in the Displays bar at the top of the Views editing screen.

Title: Title

Used as the block title when it is displayed to the end user.

Block settings: Block name

Used to refer to the block when arranging blocks by going to the administrative toolbar and clicking Structure→Blocks (admin/build/block).

Because this is a block that will live in the sidebar, we’ll want to display far fewer fields so that it fits nicely in the narrower region of the page. To do this, we’ll need to override the Fields area of this view.

1. Click on the down arrow next to the “add” button in the Fields section and select “rearrange.” Select “This block (override)” and then click the “remove” link for the “Content: Post date Application date” and “(author) User: Name Applicant Name” fields. Click “Apply (this display)” to save your changes.

2. Configure the remaining fields as indicated in Table 3-29. Since we already did an override in the Fields section, by removing a few fields in the previous step, you will notice that the configuration for these fields defaults now to “This block (override).” Once you override any part of a section, everything in that section is considered to be in override mode.

   Table 3-29. Block fields in the Applications view

   Block: Field	Values
   Content: Title (Application title)	Create a label: unchecked
   Content: Job (Job)	Create a label: unchecked Formatter: Title (no link)

3. Reorder the fields by clicking the down arrow next to the “add” button and selecting “rearrange,” so that the job comes first, then the title of the application.

4. Because we need to limit this display to job applications by the current user, we need to add a filter to the display. We’ll leave the two existing filters in place—“(Content: Published (Yes)” and “Content: Type (= Job application)”—and add a single new filter for User: Current. Make sure we are using an override by selecting “This block (override)” then check off the User: Current filter and click “Apply (this display).” Select Yes for “Is the logged-in user” and click “Apply (this display).” This step will allow the block’s contents to change dynamically depending on who the currently logged-in user is.

5. One last item, which is easy to overlook, is that our poor regular users on the site will not be able to see the view. We have the permissions set up to only allow access for editors on the site. In the Block Settings section, click the Role link next to Access, select “This block (override),” then change the selection to Permission. The permission defaults to “View published content,” which is fine, so click “Apply (this display)” once again to finish.

6. Save the view, which should now look like Figure 3-54. Your configuration for the User Applications block display is now complete.

   

   Figure 3-54. The completed Block display for the Applications view

7. By adding a new Block display, we’ve added a block to the Drupal site. Before it is visible anywhere, though, we need to enable the block. In the administrative toolbar, click Structure→Blocks (admin/structure/block) and scroll down to the Disabled section to find your new block, User Applications. Place it in the Sidebar Second region and save your changes.

Whew! After that whirlwind tour of views, you should now see a sidebar block showing any jobs you’ve applied for.

The basic job website that we’ve built only touches on the surface of the capability of Field and Views. There are a lot of possibilities for extending the functionality of this job site by adding more fields to both the Job and Job Application content types. Here are a few modules that could be used to take things a bit further with our job board:

This chapter taught you how to use two of Drupal’s fundamental “building block” modules: Field and Views. These modules constitute the cornerstone of Drupal’s power and are used extensively throughout the rest of the book. Field is used to model your website’s content by adding extra fields to hold different properties, and Views is used to display lists of your website’s data.

Besides the basic features of these modules, this chapter also introduced you to the methodology for Drupal site building. Rather than installing monolithic packages, in Drupal each module provides specific functionality, and works together with other modules to enhance their functionality. As we created fields for our different content types, References was working together with the core Field module. While making listings of content, Views retrieved information provided by both core modules and References. This sort of cooperation between modules serves as the foundation for the rest of the book, as more modules join the party and give new shape to our sites.

Here are the contributed modules that we referenced in this chapter:

These are some other resources that we referenced and community resources for learning more about the new concepts introduced in this chapter: