This hour builds on views, panels, and pages to show you how to build dynamic content views and modify pages—including Drupal’s built-in pages. You can use and reuse the components and complexity that you have now mastered to help you build large and complex sites that are, nevertheless, simple for end users, as well as easy for you and your colleagues to design, build, and maintain. In addition, you will see how to move beyond websites to incorporate content and database management features that take advantage of Drupal.

In Hour 14, you saw how to construct a view that retrieves and displays data from the database. You saw not only how to hard-code the selection criteria, but also how to expose the interface, as shown in Figure 23.1.

Figure 23.1. Allow users to select the data to display in a view.

In this hour, you will see how to construct a dynamic view—one in which the data is selected based on an argument that is passed in as part of the URL. Figure 23.2 shows a dynamic page in which the data is specified in the address rather than being hard-coded in the view or set by the user.

Figure 23.2. Create a dynamic page.

Creating a Dynamic View

Building a dynamic view has just a few variations from building a static view. After the view has been created, you can create a page variant so that your page will be complete.

This example is built on a section of the Y2KX.net site that has been shown previously. For now, all that is important to know is that there is a taxonomy vocabulary called Site Tags. Its identification and content settings are shown in Figure 23.3. (Whether forum topics are included as requiring a tag in this vocabulary depends on your particular data.)

Figure 23.3. Use a new or existing vocabulary to tag your site’s data.

The settings shown in Figure 23.4 mean that you can rely on every node in every major content type having at least one Site Tags tag. This is not required at all for this example to work. However, if you will be relying on taxonomy tags to retrieve data, you are better off if you know that the data has been properly tagged. (In other words, it is not only nice to have those tags, it is essential. Without them, data can be lost forever.)

Figure 23.4. Your site is more robust if at least one tag is required for each node.

Try It Yourself: Building a Dynamic Page

This is similar to building a static page or a page with a user-selected search criterion. After each step, you normally click Update. Click Save when you are finished. If your Internet connection is not reliable, or if you want to be certain not to lose your work, you might want to click Save several times to save intermediate versions of your work. If you do this, you may get some error messages that some items have not been provided. Do not worry; you will get to them in a later step.

1. Create a new view. Go to admin/build/views and click Add. This opens the page shown in Figure 23.5. Name the view and provide a description. Because this view is designed to be reused, it is called general_view. The description (seen only by administrators) reminds that it is driven by dynamic arguments. A view like this will show any type of node with the appropriate vocabulary term. Make certain that you choose the Node option for the view’s content. When you are finished, click Next at the bottom of the page.

   Figure 23.5. Add a new view.

   
2. After you click Next, the familiar view editor appears, as shown in Figure 23.6.

   Figure 23.6. The view editor opens.

   
3. Add three fields by clicking the plus sign (+) next to Fields in the center of the view. The fields you want to add are Node: Title; Node: Teaser; and Taxonomy: Term. Adding Taxonomy: Term will make debugging easier as you check to see the proper data is being retrieved. You can easily remove it later. Because these fields are in both the Node and Taxonomy sections, you need to set the pop-up menu to <All> so that all of them are displayed in the list. Check the three check boxes and click Add at the bottom of the page. This was described previously in “Adding Fields to the View” in Hour 14, “Working with Views.”
4. You are now walked through the settings for each field. The first one, Teaser, requires no changes to the default settings unless you want to remove the label from the field. Just erase Teaser: from the Label field. When you are finished, click Update. Drupal moves on to the next field, Node: Title, as shown in Figure 23.7.

   Figure 23.7. Adjust the label and link status for Node:Title.

   
5. Remove the Title label if you want to, and click the last check box to link the title field to the full node. Click Update and move on to the final field where, again, no changes are necessary. When you click Update for the last field, you will see a preview of the data, as shown in Figure 23.8.

   Figure 23.8. View the preview.

   
6. As you can see, the data is a bit of a jumble. Go back to the view editor and click the double-headed arrows next to Fields in the center of the view editor. This lets you rearrange the order, as shown in Figure 23.9. Move the title to the top; it is up to you whether teaser or term description should come next. As soon as you click Update, the preview display will look much better.

   Figure 23.9. Rearrange the field order.

   
7. When you were building a static view in Hour 14, you next selected a filter for the desired data. Do not create a filter for a dynamic view: instead, create an argument by clicking the + next to Arguments, which is to the left of Filters and above Fields. You will be able to set the argument, as you see in Figure 23.10. The field that you want to set will be Taxonomy: Term. It is actually more efficient to use Taxonomy: Term ID, which is a number, but for now, the term itself can make debugging easier and provide a more robust interface. (Add this to a to-do list so you can come back to it if you want.) Click Add to add the argument.

   Figure 23.10. Attach the first argument to a field.

   
8. Specify the way in which this argument will be handled. The next page that you see is shown in Figure 23.11. You can accept the defaults. The most important is the set of check boxes that determine what you will display if the argument is missing. The two best choices are usually all values or the page missing error. Depending on your site and how you program it, searching for a taxonomy term that does not have data associated with it may or may not be an error. (If you are worried that a missing argument will cause too much data to be retrieved, rest assured that a pager will be placed on the results pages to minimize the maximum amount of data to be retrieved at any given time.)

   Figure 23.11. Set defaults for a missing argument.

   
9. You have specified how the argument will be used. Further down the page, you can specify how the argument is validated. You know that this argument is a taxonomy term, so you can ask Drupal to validate it. If you were using the argument as the title of a page, no validation would be necessary. You can validate for users, nodes, and taxonomy terms. Figure 23.12 shows the validation options for a taxonomy term. You set the action to take if it does not validate.

   Figure 23.12. Set the argument validation options.

   
10. Complete the process at the bottom of the page, as shown in Figure 23.13. You can specify capitalization rules for the argument (this makes sense if you are using it for a page title). You typically transform spaces to dashes in the URL. And, if you are retrieving data that might have no values, you can choose not to show the items in the summary. In this case, you do not have to worry, because one of the items you are retrieving is the node title and every node has a title. Click Update when you are done. You can add another argument if you want. Remember that you assign the arguments in sequence, so you determine which argument is used to select data, which is used for a title, and so forth. It is solely by sequence.

    Figure 23.13. Complete the argument specification.

    
11. So far, you have been building the default view. Save it after your last update. Now, add a page display, as shown in Figure 23.14.

    Figure 23.14. Add a page display.

    

    You will immediately have an error, as shown in Figure 23.15. A page requires a path.

    Figure 23.15. You need to have a path for a page display.

    
12. In Page Settings, the path is set to None. Click None to set a path, as shown in Figure 23.16. If this is going to be a utility view, you may want to give it a generic name, such as general.

    Figure 23.16. Set a path for the view.

    
13. You are ready to test. Open a new window and type in your path. In this case, the full URL would be yourwebsite.com/general/y2k-problems (if that is one of your taxonomy terms). Remember to replace spaces with dashes.
14. You can tidy up the view using any of the other view settings. One common change is the addition of a pager, as shown in Figure 23.17 (and in the resulting view, shown previously in Figure 23.2). You may want to sort the data, for example. If you have followed the steps here, it may be time to remove the Taxonomy: Term field, which is most useful for debugging.

    Figure 23.17. Add a pager.

    

You can use pages and panels to modify built-in pages. You will recognize some of the interface from the view editor—in particular, the notion of pages that are in code and that can have variants you create. This enables you to override built-in pages. The example shown here lets you override the basic Create Content page.

Why would you do this? One reason is that you might like it laid out differently for your use or the use of your colleagues. But, particularly with a site that has extensive user contributions (or contributions from advanced users), the data entry pages may need tweaking to make them more specific. You may want your logo on them, for one trivial point. You can relabel fields, but by modifying the entire page structure, you have the ability to make it fit into a corporate look and feel. In any event, it is worth experimenting with; you already know the basics (and a lot more!).

Go to Administer, Site Building, Pages (admin/build/pages), as shown in Figure 23.18. You will see any pages you have created there. You will also find some built-in pages that, by default, are disabled.

Figure 23.18. See existing pages.

Edit the first page—node_edit, the page used when adding or editing a node—by clicking Edit. After you click Edit, you will be on the summary page for that page, as shown in Figure 23.19. Whether or not variants are shown depends on your Drupal installation and settings. You will add a new one in the next section.

Figure 23.19. See the summary.

Click Add a New Variant at the bottom. The page shown in Figure 23.20 opens.

Figure 23.20. Add a new variant.

Set the page title if you want. Then, click Create Variant to open the now familiar page shown in Figure 23.21. You choose the layout for your variant.

Figure 23.21. Choose a layout.

After you choose your layout, click Continue. As you can see in Figure 23.22, you are back in the world of pages and panels. The only difference now is that you have some additional panels you can add. Click Add Content, as shown in Figure 23.22.

Figure 23.22. Add content.

You have new categories of content that you can add in addition to the content types you have seen before. Figure 23.23 shows the Form content choices. These are the components of the Add Node form.

Figure 23.23. Choose from new components.

Figure 23.24 and Figure 23.25 show the top and bottom of a Create Content page created in this way. (The basic layout is the Flexible layout.)

Figure 23.24. Create content: top.

Figure 23.25. Create content: bottom.

The emphasis in this book has been on developing websites with Drupal because that is how many people think of using it. But, remember that Drupal is a Content Management System (CMS), and in some ways, its web capabilities are extensions of that core. You can use Drupal to build powerful database solutions that, subject to your security settings, might be visible on the web to the public or visible only to a limited group—perhaps certain users or perhaps only people on your intranet.

This section describes how you can combine Drupal core functionality and built-in modules to produce a solution to a very common problem: project tracking. The example shown here is specific, but it has a multitude of real-world parallels in various fields.

The data structure is simple:

The Drupal implementation will use two CCK field types: node references and user references. These differ from the fields that contain data, such as text. They contain references to other nodes or to users. Drupal makes it easy to set these up, as you will see in this example.

You can build sophisticated views to display projects and their status, but just using the basic Drupal interface with no customization, you can work with the project tracking data you will develop. Figure 23.26 shows what a project node will look like.

Figure 23.26. Build a project tracking system.

The project node is a custom content type that has three fields added: status, client, and coordinator. Status is a text field, client is a node reference field, and coordinator is a user reference field. In the default display shown in Figure 23.25 both client and coordinator are displayed as links to the appropriate data.

Figure 23.27 shows the revision log for a project. This requires absolutely no work on your part other than entering the data in the log for a new revision. Revisions are built into Drupal.

Figure 23.27. Drupal revisions manage project phases.

As you see in Figure 23.28, Drupal automatically maintains the link between coordinator and projects. Figure 23.28, all the projects for a given coordinator are shown in the Related Content area of the user’s profile, and they are presented as links on which you can click.

Figure 23.28. Drupal tracks projects for a coordinator.

You have seen how to build views that are driven by arguments placed in their URLs. One view can serve up any number of different permutations of data without changing any links or code. You have also seen how to extend the new Drupal interfaces into the data entry area.

If you have a lot of user-created content, sit with the users to find out how they would like their data entry page to look. Gathering a focus group together can be useful. Do the same for dynamic views. Try to avoid one-on-one interviews; you will wind up with at least as many choices as people you have talked to.