If you have developed Drupal websites before, you already know that you can only get so far in developing a site before you run into the need for Views. The first part of this chapter describes views, what they are typically used for, and how we will take their use to the next level. If you are already familiar with views, feel free to skim this chapter.
The remainder of the chapter will be used to describe our project site, its underlying need, and how we will fulfill it.
A straight-forward case for a content management system is an online magazine, a website that will contain articles. They will be written by various authors on various topics.
So, we have a framework that allows us to store and edit the articles. We also have a front (home) page on which we show 'teasers', excerpts of the articles. The articles are shown based on which was most recently published. We can specify that an article is published (available for viewing), and that it can be selected by the framework to show on the front page. We can also specify that an article should remain on the front page until we remove it, which is known as making it 'sticky'.
Let's take a look at the Drupal CMS in action. Drupal is the brainchild of Dries Buytaert, and is a shining example of what can be achieved with an Open Source project. I have created a fresh installation, named the site, and added two articles.
We can see that the CMS has lived up to it's promise (implied by the virtue of being a CMS), and we have a nice, clean layout, our two articles as teasers, well-positioned, and links (Read more) to pages containing the full text of each. The system works very well, and can provide a functional site with very little effort beyond installation and configuration.
So, our magazine begins to accumulate enough content for us to want to have 'departments', each focusing on specific topics, or categories. With that done, we want a page for each department. The first of these will be 'Travel'. Great! Just a couple of points: How do we do what the front page is doing, on another page? Having that page how do we show only articles that are about travel? We can mark the articles as being about travel through the use of taxonomy terms, but how do we specify that we want to display only articles so marked?
The short answer is, we can't. Not with Drupal right out-of-the-box.
However, if that were the final answer, this would be a very short book. The fact is that many great ideas and decisions go into the making of Drupal. One of these was to make the install package as 'light' as possible. In other words, instead of bogging down the installation with tons of options that may or may not be used, have them available as add-on modules.
A straight-forward case for a content management system is an online magazine, a website that will contain articles. They will be written by various authors on various topics.
So, we have a framework that allows us to store and edit the articles. We also have a front (home) page on which we show 'teasers', excerpts of the articles. The articles are shown based on which was most recently published. We can specify that an article is published (available for viewing), and that it can be selected by the framework to show on the front page. We can also specify that an article should remain on the front page until we remove it, which is known as making it 'sticky'.
Let's take a look at the Drupal CMS in action. Drupal is the brainchild of Dries Buytaert, and is a shining example of what can be achieved with an Open Source project. I have created a fresh installation, named the site, and added two articles.
We can see that the CMS has lived up to it's promise (implied by the virtue of being a CMS), and we have a nice, clean layout, our two articles as teasers, well-positioned, and links (Read more) to pages containing the full text of each. The system works very well, and can provide a functional site with very little effort beyond installation and configuration.
So, our magazine begins to accumulate enough content for us to want to have 'departments', each focusing on specific topics, or categories. With that done, we want a page for each department. The first of these will be 'Travel'. Great! Just a couple of points: How do we do what the front page is doing, on another page? Having that page how do we show only articles that are about travel? We can mark the articles as being about travel through the use of taxonomy terms, but how do we specify that we want to display only articles so marked?
The short answer is, we can't. Not with Drupal right out-of-the-box.
However, if that were the final answer, this would be a very short book. The fact is that many great ideas and decisions go into the making of Drupal. One of these was to make the install package as 'light' as possible. In other words, instead of bogging down the installation with tons of options that may or may not be used, have them available as add-on modules.
First, we will create a vocabulary that will contain our department names. We'll set it so that its entries are created as tags when creating the article (Story). In the following images, we'll create a vocabulary and see the resulting screen that shows it.
The create vocabulary is now available for the addition of terms.
With our vocabulary created, we'll edit our travel article.
We will also add a tag to it, which we'll later use to identify this as a travel article.
We can see an immediate change on the front page, as a result of assigning a taxonomy term to our article.
The taxonomy term is included in the display of our article teaser. All the pieces are in place and ready for us to create our View.
Enter Earl Miles, also known as merlinofchaos within the Drupal community. There is a 'trinity' of modules available for Drupal that offer an amazing leap in functionality (he wrote two of them), and Views is one of those modules. A view is originally a relational database term, referring to a temporary arrangement of information in the database so that it can be presented in a meaningful way which is different than the underlying table layout. The Views module accomplishes the same thing, and provides the glue to tie itself in to the rest of Drupal and, especially, the ability to theme the result with templates. In other words, it gives you the ability to look at Drupal content in a way you would otherwise be unable to (without custom code).
So, for example, our magazine can create a View that allows us to view content as we do on the front page, but with the selection of that content filtered in a way that we define, which in this case would be by department. In fact, let's do that.
In order to create a View, the Views module needs to be installed. Ours already is, and the details for that are given in Appendix A. We'll navigate to the Views page. Via the menu, it would be Admin | Site Building | Views. We'll use the URL, which is admin/build/views.
The idea behind a View is to control the building of an SQL statement, in order to retrieve only the rows that we want. In this case, the rows will be nodes, which is why we created a 'Node View'.
The following image shows the sections of the Views panel labeled as they relate to an SQL statement.
We want to select only the nodes that have the taxonomy entry of the department we want, which in this case will be travel. There are three ways we can accomplish this:
1. Filter: We can specify a selection filter (equivalent to an SQL 'where' condition) requiring the taxonomy term to be equal to 'department'.
2. Exposed Filter: The same as the Filter option, but exposing the filter to the user so that the value can be changed.
3. Argument: An argument also creates an SQL 'where' condition, but can be set externally to the View and passed in the URL.
We're going to select the argument method. The reason is that in accepting an argument that defines the taxonomy term instead of specifying it in the View, we can create a page capable of showing any department. How will we get the argument passed? Simple. We'll get to that once we create the View.
There are two filters that we do want to create. Even though we'll be accepting the taxonomy term as an argument, we still want to make sure that we're only selecting Story nodes and that the nodes are marked as published.
1. The filter selection is grouped by the source of data. We want the Node items, and we'll check the boxes for Node: Published and Node: Type.
5. We want the travel articles to appear in the order of most-recent to oldest. We could select Node: Published date as our sort, but if an article is subsequently re-edited, the published date won't change, but we want it to move to the top of the list. So, instead, we'll use Updated date.
7. We'll define our argument next.
9. For its settings, we'll leave everything as it is. We are then specifying, by default, that if no argument is passed, all department articles will be presented, and if a department is requested that does not exist, a 404 page will be given. In our current context we don't really care about the handling, because we will be controlling what is requested. The one caveat would be if a taxonomy term was removed, but the menu choice for that department was not.
1. We see that we have article teasers showing, with links to view the entire article (the article title is one, and the Read more is another). Wait! Wasn't the whole idea to show the articles for only the travel department? What is the Taming the Shrew article doing here? We haven't provided an argument to our preview, and if you remember, when no argument is present, the behavior we defined is to show all articles. Let's supply an argument. We need to have the tid of the taxonomy term in order to use it as an argument. If we hover the mouse cursor over the term travel, and look at the link URL in the bottom of our browser window, we can see what the tid is.
2. We can now enter the tid into our Live Preview window and see what happens.
4. The only thing left to do in the View itself is to define a path to access it. As strange as it may seem, at this point there is nothing to access. We have not actually defined a display entity for this View. In other words, right now there is no output we can access from outside the View edit. We need to create a display. If you look at the top left of the View panel, above the Add Display button, you see that Page is the current choice, which is the one we want. Another choice in the drop-down list is Attachment, which is what this book is about. We'll start using that choice in Chapter 2, Attachment Views—A New Beginning.
5. For now, we'll click the Add display button.
7. We'll name the path "displays".
8. We can now save the View. The only thing left to do is create a way to invoke it.
1. We set out to be able to display articles for the travel department, and at this point, that is the only taxonomy term that we've defined. We need to edit our menu and add a choice. The menu editor is at Admin | Site Building | Menus (admin/build/menu) and from there, we want to select the Navigation menu to edit.
2. We want to add a menu choice to this menu.
4. We'll navigate back to the home page, and select our new Travel Department menu choice.
This is an example of what a View can do for us. We can create further menu choices for various departments too.
This is fine for showing all the articles for our Travel department. However, what if we want our department page to provide the user a list of articles from which to select an article to view? We could define our View to present fields, instead of nodes, and then the page would show a list of titles, but the page would name when the user selected a title, and they would have to click the Back button, or some such, to return to the list and choose another title. What if we want the list and the article to appear on the same page? Two separate areas communicating with each other?
That is the secret of Attachment Views, and we will begin looking at them in Chapter 2. Here, we have one more thing to do, and that is to present our project site.
The project site
During the course of this book, we will be creating a website. The website is part of an actual project, and the development is live and occurring in parallel with the writing of the book. With this chapter actually being written last—because it's declarative about the direction of the book, and it's always easier to do that in hindsight—I can say now that I wouldn't recommend this approach when the site is for a client. Minds change, business needs change, things get delayed (but deadlines don't), it can make things messy! That said, it hasn't been too bad, but be forewarned!
The website is for Guild Builders, Inc. of Rancocas, New Jersey, a commercial construction firm. The site will be their first web presence. It will serve as an initial point of sales information for clients, and a primary point for initial information about opportunities for subcontractors interested in providing services.
The business functions to be addressed (and the resulting pages, in parentheses) are:
A 'landing' area (home page)
A way to contact the company (contact page)
Sign-up capability for subcontractors (subcontractor registration and profile)
Information about jobs open to bid (jobs page)
Biographical information about Guild Builders staff (bios page)
Examples of prior projects (prior-work page)
Company information (about us page)
An easy way for management to view the above (control panel)
These would seem to be independent, as pages on a static site. However, we're going to kick it up a notch. If we look more closely, we can see that many of these are related: Prior Work to Bios (the project manager), Subcontractors to Jobs, About Us to Prior Work, and so on.
What we're going to do throughout the book is use Attachment displays (I'll be using that term synonymously with Attachment views) liberally to provide a visual and structural linkage between the functions on the same page. So, for example, when we choose an example of Prior Work, we will be presented information about the job and information about the project manager all on the same page!
The project site uses the current version of Drupal 6 (6.13 at the time of this writing...oops...make that 6.14...don't blink) and several add-on modules. The details of the modules and their configuration are given in Appendix A.
We are also going to use a handful of custom content types too. Story and Page are the installed content types of Drupal. We have created some that contain fields suited for the type of content they are. The details of these are given in Appendix B.
It's time for you to move on to Chapter 2, and time for me to write the appendices!
In this chapter, we learned what Views are, and what a standard View can provide to us in functionality that Drupal, as freshly installed, cannot. We also learned what the project site will be, and how we can deliver its requirements through the use of Views, and in particular, Attachment Views.
In Chapter 2, we will be creating the first View for our project site and our first Attachment display for a View as well.