Drupal's Building Blocks: Creating Views

This chapter is from the book 

In this chapter, we talk about the Views user interface (UI) and discover how each function works. We look at how each piece creates part of a query, and how the results of those queries fit into pages and blocks. We also discuss the most important filters you may need and explore how to create relationships between node content that does not otherwise share information. RSS, styles and fields, and the Views Bonus pack are other important topics when determining what you want out of your view.

Views UI

The Views 2 UI is significantly different from the original Views UI. The rewrite for Drupal 6 allowed for a complete change of the Views control page, bringing the power of AJAX to the Views creation system. The new interface is cleaner, is packed with a large number of features, and gives a distinct clarity to each piece of functionality.

Users of the original versions of Views had to deal with arrows that moved parts of the page around, fields that looked like they might work together but really didn't, and overall an interface that just wasn't very clean. Moreover, when building a query, users really couldn't get a good idea of what the view would ultimately look like unless it was out where other users could see it publicly. This could lead to some ugly or confusing pages temporarily, until the view was completed. For the most part, Views represented a huge step forward over having to custom build your own queries all the time, but there was definitely significant room for improvement.

Several months were spent in the design of the Views 2 UI. The revised UI is compact and clean, allowing users to easily see exactly which part of the view is currently being worked on, which changes have been made, and, most importantly, what the finished view will look like.

When Views is installed, it creates a new menu item under Administer >> Site building >> Views. This menu item is the base Views page. The Views UI consists of four main pages: List, Add, Import, and Tools.

There are nearly limitless applications in the real world for Views. Any time you need a list, Views is there. In regard to the examples introduced in this book, you could use Views to create a list of the most recent recipes entered, the most recent batches brewed, shirts available in a particular size, and so on. If you add pictures of a glass of your homebrew, you could use Views to display only the batches for which you have uploaded pictures, and more.

List

The landing page for Views is the List page. On this page is the list of default views provided with the module install. By default, all of these views are disabled, allowing the administrator to determine which views, if any, might be needed immediately. It also prevents new items from displaying on pages where they may not be expected; the frontpage view, for example, will override your front page. There is also a link to the Getting Started page. It is an example of Advanced Help, and will guide you through the creation of a simple view. Figure 7-1 is an example of what your default Views landing page should look like.

Once you have created views of your own, they will also be listed here in alphabetical order. This list can be modified through the group of drop-down menus found at the top of the list. These drop-downs consist of filters and sorts for the Views themselves.

The first row of list drop-downs are the filters. They filter out any Views that do not match the criteria given:

• Storage: Filters on whether the view is local and in your database (normal), whether default views are stored only in code (default), or whether both code and database are used for storage (overridden).
• Type: Different than the content type. This filter narrows down which sort of content pieces are contained in the view.
• Tag: Lists all tags that are available for currently available views.
• Displays: Lists which type of content sections views can be displayed in.

Two types of sorting criteria may be applied in Views. Sort by creates the list by a single particular piece of information about the view, while Order creates an ascending or descending list ordered by the rest of the drop-down choices.

Note that multiple filters as well as both sorting options can be used to change the list of views, narrowing down that list considerably. This makes a case for sites with large numbers of views in use to tag each view with keywords that make it easier to find; this approach allows the Tag filter to be used to minimize the initial returned list. Clicking the Apply button causes your sorts and filters to be executed, returning the list you requested.

The list of default views available is intended to simulate some of the most basic tasks a new Drupal site may need to accomplish. Each view gets a box of its own, displaying the pertinent information about that view. Each view can have many pieces of information, most of which can feed back into the filters.

The next thing to focus on in the Views list page is the title bar for one view. This darker bar contains four pieces of information. In italics is the storage level of the view—normal, default, or overridden. Next is the type of view, which is listed in a normal font and affects the Type drop-down menu. Third is the emphasized text, which is the actual view name. After that, in parentheses, is the tag that is used for that particular view. At the end of the bar is a group of links: Edit, Export, Clone, Delete. For a default view, only the Enable link will be available until the view is enabled. For views that you create, all four links are present at all times. You cannot currently disable a view that you have created.

Inside the box itself are up to four more pertinent Views clues to serve as differentiators for each view. The left column may show the Title, Path, and Display, assuming they have been configured for that view. Title is the human-readable name, much like the Display Name for a field. Path defines the Drupal-specific URL that would take you to a page that displays this information. In italics is the display type, which may contain block, feed, page, or date browser. On the right side of the box is a short description of the purpose of the view or its functionality. This area may also provide prerequisite information on which modules need to be enabled to provide the view with data.

Add

The Add pages are where all of your view definition takes place. This self-contained, multi-step process keeps the majority of your work on the same page so that you can easily see which parts of the view definition you have changed. The Views UI gives clues as to what has or has not been changed in the display. In the default display for a given view, when a change is made, the changed setting is highlighted and shown in boldface until the changes are saved. Note that if any of the form settings are open for editing in the view, the save button for the overall view will be disabled until the edit itself is saved or cancelled. These pages are also where all of your edits for an existing view will take place.

More clues come at the end of the submenu bar, which contains an italicized note stating whether this is a new or a changed view. This message persists until the changes are saved. The submenu bar is explicit, telling you exactly which view and display type you are editing. At the end of the bar are links to export the view, to clone the view, and, if you are editing, to look at the page in which the view will appear. Exporting a view will give you the code to import the view into another installation. Cloning a view is useful for experimentation. For example, you might want to try some different settings on a view; cloning will let you do that while leaving your original view intact. Cloning also gives you a base to work with if you want to create multiple similar views. For instance, you may have a view of recent comments but also want a view with recent comments for a particular node type. You might clone the recent comments view rather than re-creating it.

Exercise 7-1. Enabling and Changing the Default View

In this exercise, we'll enable a default view and make a small change to become familiar with the Edit page.

1. Navigate to Administer >> Site building >> Views.
2. Scroll down to the Glossary view.

3. Click the Enable link on the right side of the title bar.

   It will take a moment for the view to become enabled. When it does, the page will refresh and the view will move up in the list and into the enabled views, which are sorted alphabetically by default.

4. Click the Edit link next to the view (Figure 7-2).
   

   Figure 7-2 Edit: one of the available options for an enabled view

5. Under the "View Settings" box, click the word "default" next to "Tag."
6. Scroll down the page to the "View details" box (Figure 7-3) and change the word "default" to anything else. You can change the tag or remove it all together.
   

   Figure 7-3 Changing the tag for the view

7. Click the update button.

   Your change has not yet become permanent; Views allows you to make multiple edits before saving the view. It will let you know that you've made changes. Figure 7-4 shows you what your submenu may look like after you have updated but not yet saved the changes to the view.

   

   Figure 7-4 Changing the tag for a default view turns it into a new view

   You can scroll down to the bottom of the page for a look at the preview; we'll discuss this feature later in the chapter.

8. Click the Cancel button at the bottom of the edit section. We don't actually want to change the tag.

When you add a display type, all settings appear in a lighter, italicized font until changes are made. If a change is made to a setting so that it differs from the default, that setting will then appear in a normal-weight, non-italicized font. This system enables you to quickly identify exactly which parts of the view have been modified. The "gear" icons indicate styling options are available for that setting. Some boxes for settings have a plus sign (+) in the box title bar (as seen in Figure 7-5); clicking it automatically opens a corresponding add menu that allows you to select and configure a new option for that set of configuration options. For example, click the plus sign next in the Filters title bar to add a new filter to your view. In the same title box, a small up/down arrow icon will appear when two or more options are available in that section. Click this icon to rearrange the items within that group of settings.

Views Add Creation Page

The Views Add creation page is the first page you encounter when you are creating a new view. It requires two pieces of information, view name and view type, and suggests two others, view description and view tag. The view name can be a combination of alphanumeric characters and underscores; names should use all lowercase letters for consistency. The view description is a text field where you should enter a sentence or two to describe the purpose of the view. A view tag is useful for grouping or separating your views if you are using them for specific topics or purposes. Finally, each view must have a type that determines which content it will look at to create the view. The type determines the primary table that Views will access for data.

Here are the types of views:

• Node: Node views are likely to be the most common type of view on a site. The node type creates lists of any node content.
• Comment: Comment lists can be retrieved from nodes, but there may be times when you want only comment information. The view may be faster, but there is a tradeoff in security.
• File: File limits views to information about uploaded files. It is useful for seeing which files are taking up space in your installation.
• Node revision: This limits the view to revision information—useful for determining which users are making changes, and which changes are being made.
• Term: Use this view type with taxonomy; it helps to create lists of taxonomy terms.
• User: This type breaks down user information and helps with showing which users have accounts, and what they are doing.
• Access log: This view can show what your users are accessing, and what they are having trouble accessing. An access log view can help filter down the log so it becomes easier to spot site problems.

Once a view is created, the type of view cannot be changed. If the basic definition is not correct for your needs, the view will have to be re-created. Choosing a particular type means that only certain filters, fields, and other Views functionality will be available once that type is chosen. Figure 7-6 shows the form used to create a new view.

Left-Side Tabs

Along the left side of the UI is a group of tabs (or drawers). These tabs show which displays the view currently has configured and give you the ability to add new displays. A display is a place or way the view may be shown to users of the Web site. All views have a default display. The default display contains the initial and any edited settings for that view. The default display is not actually used anywhere within Drupal itself—something that may confuse new users. It simply is a container, the initial state of the view.

Four display types are used for actual visual placement:

• Page: Displays the view as an entire page complete with a menu and URL.
• Feed: Helps set up the format for an RSS feed.
• Block: Creates a view that will be placed within a block.
• Attachment: Helps to add a view to another view.

The first tab will be the default setting for the view; if you are not sure which display you are editing, the main window will provide this information. Figure 7-7 shows an example of one of the views included with the Views module. It has been edited; yours may not look exactly the same.

New displays are created by using the drop-down menu and can be an attachment, block, feed, or page. Adding a display allows you to refine the view for that type of display. For example, you may wish to use a view within a block; you could create a display setting specifically to format for a block. You could then create a page display and use the same view, but format it differently to take advantage of the greater space allotted to a page. Choose a display type you want to add, and click the "Add display" button.

The last drawer is the Analyze button. At this time Analyze has only a minor level of functionality, but like the rest of Drupal, it is very pluggable and can be expanded by those developers who wish to do so. Its purpose is to do a low level of error checking on your view to see if anything is obviously wrong. The Analyze feature was originally added to ensure that a view has content that will display. Some members of the Drupal community suggested that a view should contain a filter that required the content being displayed to be published. There are reasons why this approach is not necessarily a good idea, so the filter is not present. Analyze will notice when you have not set a filter that displays some amount of data and warn you of this potential problem.

View Settings

View settings is the first box in the first column of the main display. It appears only in the default view settings, as it is pertinent to the entire view for all display types. This box contains the Tag field, which can be edited to add or remove tags even after the view is being used. To change the tag, click on the tag itself—this will allow you to change both the tag and the description of the view.

Basic Settings

The basic settings are the first level of definitions. They define the core of what your view will look like, and may occasionally have slightly different effects depending on the display type. Notice the italicized lettering for the display in Figure 7-8. Most settings for a display will be italicized unless you modify this default behavior.

Name is the name for this particular display. Only the administrative interface sees this name.

Title is the displayed title of the view itself and will show wherever the view is. It will be the block title in a block view, or the title of the page if the view is an entire page. You may leave it as "Title" for a default view, but you may want to name it if it is a display, or if you are using a cloned view and the title will be the same wherever it is used on the site.

Style determines how the view itself will actually appear; it does not affect the rest of the page. Your view can be shown in a grid, list, table, or unformatted. Any style other than unformatted will be associated with further settings that customize that style; these options are reached by changing the style or by using the gear icon. Choosing a style determines the look of the view. Each style can be formatted in different ways, from completely unformatted, to a basic list to a neatly stacked grid. Each style type has the ability to group the output by one of the fields that are being displayed; if the post date is in the view, grouping by that date will gather all content added on the same day into one group. Also note that for styles (and for row styles), you can change the look by using template files to specify exactly what you want—more on that topic when we talk about theming in Chapter 9.

The grid style allows you to choose a number of columns that will appear on the view. You may choose to align your view horizontally (top left to bottom right) or vertically (column A from top to bottom, column B from top to bottom).

Lists can be either ordered or unordered. Ordered lists will number the view results. An unordered list provides output similar to the unformatted style. It is significantly cleaner and easier to read than an unformatted view, however, thanks to the bullets that appear next to each entry returned.

Tables are the most complex output format. The table display is clean and easily understandable by most users. By default, each column in a table display contains one field. Columns can be changed to use multiple fields if this formatting is desired. In the style options (which become available when you click the gear icon), choose a field. In the Column drop-down menu next to that field is a list of all other fields available—assuming you have already added fields. Change the drop-down choice to one of the other available fields. This step can be repeated so that all of your fields are in the same column, but only the main column item can be sorted. When multiple values appear in the same column, the Separator field can be used to distinguish between the fields in the column. Separator may use regular characters or HTML. If multiple values are being used, it is highly recommended that you use the   (single space) for separation, if nothing else. Bullets and the pipe (|) character are also common and valid separators, although it is recommended that &nbsp be placed around these characters for additional readability.

Tables can also be sorted by column, which creates a clickable header. You may choose a column to be the default column on which the table sorts and specify whether the sort is ascending or descending.

The unformatted style provides a simple, basic list of all items that match the query. Each row is a returned field, but lacks any special spacing or styling. This style is potentially useful for lists of names, but may be hard to read for many users if multiple fields are returned.

Row style determines how each row in the view itself will be styled—as a node or as a field. If the Style setting is using Table, Row style will be missing from the Basic settings box. Row styles may use fields or nodes, with each type displaying one per row. When using fields, you have the option of making each of the fields appear inline rather than stacked, and you can provide a separator just as the full view style does. The node style is exclusive to using selected fields (the fields box), and gives you the option of showing just the teaser instead of the full node. In addition, you can put comment links or comments themselves in the view.

AJAX may be available for use in some cases. The "Use AJAX" option specifies whether you will use AJAX in the view for exposed filters, table sorting, and paging. Be aware that using AJAX will keep the entire page from refreshing, which may cause issues with links.

Pagers make it easy for your users to skip forward and backward in your view, which is a very useful ability within large views. Two types of pagers are available, should they be needed. A mini-pager shows the current page of total pages and uses forward and backward arrows (<< 1 of 6 >>). Mini-pagers are well suited for use within block displays because they fit more cleanly than a full pager. A full pager displays a list of page numbers plus first, previous, next, and last options so that users may easily jump multiple pages. Pager element is a number that can be used to identify a pager within each page. If multiple pagers are used within a page, each one needs to have a different identifier.

Every view needs to have a number of items to return by default. The "Items per page" option sets this number, and can provide a helpful limit. Using a set number can increase the return time of a page—something most Web sites see as a critical function. You can also offset or skip some number of items in your view.

Views can have multiple displays, which may be linked together easily by using the More link. Checking this box will add a More link to the bottom of the view. On a block display, such a link will take the user to the page display version of that view, which may contain significantly more data. This capability could be used to link a teaser to a full article, link the archive of this month's posts to the full archive, or link a short block of recent comments to a full page of recent comments.

Distinct adds the SQL statement DISTINCT to your query, which attempts to remove any duplicated records from the view. Completion of the Distinct operation takes time, which may be considered a performance problem in some cases.

Access places restrictions on what users can see the view, either by user role or by general permissions. You can create roles for users or change user permissions under Administer >> User management >> Roles or Permissions.

Caching is one of the newest features to Views. This pluggable cache is not the same as the overall Views caching. Rather, it lets you cache each display separately if you wish, or cache the entire set via the default. The standard options are the ability to cache the query results and/or the entire rendered output. You may cache one and not the other. In addition, you may assign different lengths of time to each cache; the menus provide options ranging from 1 minute to 6 days.

The Header adds a header to the view. A header is simply some text that will appear above the view. It can be set to appear even if the view has no results for display, which helps let the user know that the page did display, even if no actual data was returned. The Footer is essentially the same as the header, except that it appears at the bottom of the view. Either of these elements can be used to provide an explanation of the view or other pertinent information about the view.

Empty text is text that can be displayed if the view returns no results. It lets the user know that the view has completed its processing. Such text is more useful than just returning an empty result, and is clearer than using just a header or footer. In essence, this text lets the user know that the query mechanism did not crash; there are simply no results.

Finally, there's the theme. Theme is not actually a setting; it is informational in nature. It lists template files that the different parts of the view may be using. This display is similar in nature to what you would see if you looked at a page with the Devel module. The template in use by each piece of the view appears in bold font, so you can see exactly which files are being used. You may have display, overall style, and row style themes within the same view. You can also rescan the template files in case you make changes to the names of .tpl files. Clicking the "Rescan template files" button will clear the theme registry.

Display Specific Settings

Each display type also has a settings box in the first column that appears below the Basic settings box. Figure 7-9 shows one example of display settings.

Page has two settings, path and menu. Path is the Drupal-specific path to the page that contains the view. Remember that this path is not a full URL; http://www.example.com/ is assumed to be the base URL, with additional information being tacked on to the end of this URL. When you click on the path setting, you will see the entire base URL but you must enter the remainder of the path. The path statement can take arguments.

Menu gives you options for adding a menu item as a normal menu entry, a tab, or a default menu tab; you can also not add any menu item at all. When creating a menu item link, you should give it a title and determine whether it should have a weight. The menu also has further options that become available when you click the gear icon, which determine exactly where that menu item should go.

Block has only one setting: admin. This simple description of the block is intended to make it more easily findable in the Administer >> Site building >> Blocks page. The admin setting is a name, and should be relatively short and clear.

If your display type is a feed, two options can be changed. Path is the same as it is for page settings; this time it is the path to the XML feed page, whose filename often ends in .xml. The second option is "attach to," which creates the feed as part of one of the other displays. This gives feeds a similarity to attached views.

The settings for attachments also are different from the settings for other displays, as they are not actually changing the display of the attached view. Instead, the attachment settings determine where the attached view will be placed and which information will be inherited from the view it is attached to. Arguments and exposed filters may or may not be inherited from the parent view. Exposed filters comprise any of the filters in the view that are made available to the person looking at the view; they can be changed when they are displayed. The attachment can be positioned before the parent view, after this view, or both before and after the view. This group of settings also has an "attach to" option, but it is used to attach the view to one or more displays or to make it part of the default display. Every view built on the default would then have the secondary view attached.

Relationships

Relationships is the first box in the second column. This and all remaining boxes to set up views have clickable titles. Clicking the title will tell you if that group is using the settings from the default view or if it is using an override. With relationships, you can create links between data that may not be otherwise related. A complex structure can be created by using relationships.

Clicking the plus sign (+) opens the section for adding a new relationship. The different types of content (not content types!) that can be added are grouped together. A drop-down menu allows you to choose which items are available for relationships so that you can more easily find the piece you are looking for. Many groups may be available, and the list changes depending on which content types are available on your site and which other modules you have enabled.

When you add relationships, the number of fields available may increase significantly. For example, you may want users to rate your content. Modules are available to perform this task. However, Views doesn't have a good way to link the various kinds of data together on its own; it needs a relationship. You can create a relationship between voting data and node data, for example, so that they can be displayed together in the list.

Arguments

The section for adding an argument looks very similar to the section for adding a relationship. The main difference is that many more types or pieces of content can be added as arguments. Arguments act in a fashion similar to filters, but with more exposure to the user. Chapter 8, which is devoted to arguments, discusses this issue in depth.

Fields

The setup for fields looks significantly like that for arguments and relationships. The fields settings, however, add the actual fields that will be available in your view. This is where you determine which pieces of information will appear in the view and which order they will appear in. Using this feature, you might give a short preview of a group of stories or see a list of recent comments. Fields do not have to be visible to a user to be included in a view.

Sort Criteria

SQL's sorting mechanisms come into play in the Sort criteria settings. You may sort your view by one or more fields. If you do not specify a sorting criterion, the view will sort itself in ascending alphabetical or numerical order on the first field available to the view. If you wanted to see content posted by users per day, you would add the sorting criteria User: Name, and then Node: Post date, as shown in Figure 7-10. You may also add the criteria in the opposite order, as they can be rearranged using the rearrangement tool.

Filters

Filters can be used to limit the fields returned for your view. Note that this limit is based on actual data, unlike the "items to display" link in the Basic settings box, which puts a straight limit on the number of fields. This area is where some especially important criteria for your views are stored. If you wish to publish a view for general use, any information obtained from nodes will usually be taken from published nodes.

Overrides

Overrides are another part of a change from the default setting. If a setting is changed, it may need to be overridden. Each of the clickable box titles (relationships, arguments, filters, sort criteria, and fields) allows you to override the default display. When you click on the title, the box at the bottom of the configuration screen tells you whether you are using the default display. From here, when you update the settings, the update will be pushed to the default display. If you want this change to affect only the current display, you must override the defaults.

Validation

Many of the parts that you can use to define a view require a setting, especially for displays other than the default. If your view does not have the correct settings selected, a red warning box, similar to Figure 7-11, will appear. It indicates which settings are missing or set incorrectly. In other cases, such as when no content is available to the general user base being made available for display, a yellow warning box will appear to inform you of that fact. Until the validation errors are corrected, the live preview function will be unable to display a view.

Live Preview

The live preview feature represents one of the biggest steps forward in usability for those individuals who are new to using Views. Live preview shows you exactly what your view will look like to your Web site visitors, allowing for changes to be made quickly and easily without needing to click back and forth and constantly reload pages (see Figure 7-12).

Other basic information about the view is also presented as part of the preview. This information includes the query that is used to create the view, the title and path, and statistics on how long it takes the query to actually build and execute as well as how long it takes the view to fully render.

Import

The Import page has a simple purpose: to import a view from another site or installation of Drupal. If you have exported a view, you may enter a new name if you wish, or leave the view Name field blank. Remember that the view name must consist of alphanumeric characters, but may use underscores. Paste the exported view into the text box and click the Import button. Views will then attempt to import the view. If this operation is successful, the Edit page will appear, allowing you to customize the view.

Tools

The Tools pages provide help with troubleshooting and updating your views to the new version. There are two subtabs within the Tools section: Basic and Convert.

Basic

The Basic tab comprises a list of check boxes that can be selected to enable features that are helpful for performance optimization, troubleshooting, or general placement of some of the query information within the user interface. This page also contains the highly important Clear Views' Cache button. If you are changing your views, and they are not appearing correctly on your actual displayed pages even though they worked perfectly in the preview, you may need to clear the cache. At the bottom of the page is a drop-down menu that allows you to select where the performance statistics should be placed; this location is entirely up to you.

The check boxes on the Basic tab are documented within the page display itself, and should be easily understood in general. Many of these features are designed to work with the Devel module or to turn off functionality that may be causing problems either for the view or for the browser itself.

"Add Views signature to all SQL queries" tacks an additional field that does not need processing onto the SQL query when it is being built. When looking at an SQL WHERE clause, you will see a 'VIEWS' = 'VIEWS' string that indicates Views was used to build the query. When you are searching through an extensive log file to determine which queries may be causing problems, this string makes a Views query easily identifiable. It is recommended that this flag be used only during troubleshooting, even though it does not appreciably change the query. Why process more than you have to?

Views caching can be disabled across your site with the "Disable Views data caching" check box. This setting may be useful during the creation of new views and especially during the retooling of an existing view. Views may cache a tremendous amount of data in an effort to quickly display a view; this data can come from multiple tables, other modules, or other existing views. Trying to maintain this cache can place a significant burden on performance. If the cache is not used, Views is forced to rebuild each view every time it will be displayed on a page. If that view has to call other views and other modules to return information, things can get very ugly, very quickly.

The next two boxes deal with queries and live preview. We've already seen that the live preview shows you what your view is supposed to look like. Normally, your preview will be displayed and the query used to create that view and its corresponding details will appear below it. These settings boxes allow you to put the query above the preview ("Show query above live preview") and to show all of the queries that are run to create the view ("Show other queries run during render during live preview"). When troubleshooting, these settings can help you determine if a query is being called multiple times when it should not be.

If you have created a view and have the ability to edit it, you may see [Edit], [Export], and [Clone] links over the top of a view that appears in the public section of your site. These are called hover links. You can turn them off by selecting the "Do not show hover links over views" check box. Hover links are useful for quickly reaching the Edit page for the view directly from the view itself. This is much quicker than digging into admin/build/views/, finding the correct view, and hoping you've got the right one.

Web site developers should be concerned with the performance of their sites, especially if the site is professional in nature. Views can interact with the Devel module and provide performance and query statistics. Such data helps you determine how long your view and its container are taking to render—again helping you find bottlenecks in system response.

The last check box continues a core tenet within Drupal development—that the entire user interface should work without JavaScript. If you are having problems with using the Views UI because of your browser, or you're just that concerned about JavaScript security, you can turn off JavaScript for views. The interface should degrade and be completely usable without it; it just won't be as pretty or as easy to use.

Bulk Export

The Bulk export page provides a method for exporting all of the code that creates a particular view. Figure 7-13 is part of this page. Quite simply, you can choose one or more views to export, and have the code available and easy to store in the source control repository.

At the bottom of this page is a box labeled "Module name." This box's purpose is to help you export a view that you can then easily import directly into a module. If you enter a module name, parts of the code will contain pertinent hooks into the module.

Convert

The Convert tab is likely to greatly interest users of Views 1. Views 1 is not being converted to Drupal 6, and Views 2 is not being backported to Drupal 5. This leaves users in the unenviable position of having to upgrade their Drupal version as well as Views at the same time to maintain a functioning Web site.

The Convert tool checks the database to see if it contains any Views 1 views and then gives you the opportunity to convert each such view to the Views 2 format. It is highly recommended that you use a test site to do so. Using a test bed to convert the view means that you can then export it and later import to the live site once it is upgraded. You have to do the conversion only once, and it can be perhaps ahead of time; this eases the pain of upgrading.

Be aware that due to the extensive changes made between Views 1 and Views 2, the actual views are likely to be altered somewhat by the conversion process. You will need to spend some time examining each converted view to ensure that it still shows (or doesn't show) what is expected. If you have not yet upgraded to Views 2, consider exporting your views from the previous version. Once the upgrade is complete, you can import these views via the Import tab. It will take you directly to the editor and give you a clear idea immediately if the view needs work before being made public once more.

With all of these boxes, check boxes, and settings, it's easy to lose track of where you're going. The next exercise takes you through the creation of a new view.

Exercise 7-2. Creating a View: Recent Content

In this exercise, you will create a simple view. Before proceeding with this exercise, make sure you have several nodes created for one of your content types. This example will create a default view for use in displaying the most recent content of all types.

1. Navigate to Home >> Administer >> Site building >> Views and click the Add tab.

2. Use the following values to populate the initial view creation page:

   Field	Value
   View name	recent_items
   View description	Most recent items posted
   View tag	base
   View type	Node

   Notice that this data doesn't actually say "shirts" or identify any other content type specifically. We are creating a more generic view that can apply to all content types—giving us something we can clone later to create a view for a specific content type. For now, we'll use the "base" tag to indicate it's a view we intend to start from to create others.

3. Click the Next button to proceed.
4. In the View settings box, notice that our tag "base" is now shown. To change the tag later, come back to this page and click the word "base."
5. Under the Basic settings, do not change Name or Title. When we are doing a display, we might want to change these settings, but not yet.
6. Change the Style to an HTML list and update the settings. This action will bring up the style settings. The default is an unordered list; leave it alone, and update the settings. Notice one of the red warning boxes at the bottom of the page: Display Defaults uses fields but there are none defined for it or all are excluded.
7. Row styles are set to fields by default. For now, leave this setting as is. Attempting to update this choice will also generate an error message.
8. Skip to the Fields box. Click the + sign to add two fields: Node: Post date and Node: Title (you can access the Groups drop-down menu and choose Node to find these fields more quickly).
9. You will be presented with the configuration screen for Node: Post date. Use these values to configure the field, and then update the settings:

   Field	Value
   Label	Clear the label—by default, this says "Post date"
   Exclude from display	Unchecked (this is the default)
   Date format	Custom
   Custom date format	F j, Y

10. The UI will immediately take you to the configure screen for Node: Title. Use these values for the fields, and then update the settings:

    Field	Value
    Label	Clear the label—by default, this says "Title"
    Exclude from display	Unchecked
    Link this field to its node	Checked

11. Live preview should now be displaying data. Use the up/down arrow on the Fields box, and switch the order of the field display so that Title is first, followed by Post date. Update the settings, and review how the live preview has changed.
12. Click the + next to Sort criteria and choose Node: Post date. Change the sort order to descending and day. These criteria force the most recent posts to be displayed first.
13. Click the + next to Filters. Choose Node: Published. Checking the box on the configure page means that only published nodes will be displayed in the filter for any user.

Your default display is now complete. Your live preview should now display a list of all nodes and dates on which those nodes were published. Each node title should also link directly to that node.

Now that you have completed development of a base view, you can clone the view and set filters so that only one type of node is displayed in the view. At this point, we also need to create displays for the view so that it can be placed into Web pages.