Burningbird Technology Weblogging

Drupal views and taxonomy pages – updated

Drupal provides a way to list out postings by taxonomy term, but not necessarily by vocabulary, directly. I’ve been using a module, vocabindex, to provide a web page that lists out the taxonomy terms for a vocabulary, but it doesn’t provide exactly what I’m looking for: a way to display posts by vocabulary, in addition to displaying posts by vocabulary term.

There is another important module, Drupal Views, that does provide ways of displaying data objects such as posts (nodes) in any number of ways. Since Views has now been officially released for Drupal 6, I decided to replace my vocabindex pages with custom pages created using Views. I’m providing the steps in this post, as I thought others of you might also want to give this approach a try. I also demonstrate a second technique, which I’m just now implementing, providing a way to display both a vocabulary terms view and a vocabulary posts view, together, in one page.

One small caveat before I get into the details: I am fairly new to Drupal, as well as the Views module. Though I’ve had very good luck with my implementations, I’m also open to any recommendations for improvement.

Implementing Vocabulary Posting Pages with Views

To start, you have to download, install, and activate the Views module. Once activated, an entry for Views appears under the Site Building header in the administration page.

Clicking the Views opens a page listing out all existing Views, including some that are installed with the Views module, but aren’t active. None of these pre-existing views provide what I needed, so I clicked the Add button to add a new View.

The first page in the Add View option that opens is a way of providing both a machine name, and a descriptive name, for the View, as well as selecting which Drupal object the View references. In this example, I want to list out information about posts, so I select the nodes option (the default option).

The Views editing page is a nicely designed page with several options, including a set defining overall view characteristics, as well as how to options to pick fields, define sort criteria, add View displays, filters, and so on.

The first thing I did was to add View fields. When you click on the plus sign (+) associated with Fields label, allowable fields (based on picking the Nodes View type, earlier, when the view was named) are displayed. You can check any of the fields present, such as the Node Title, Node Publish date, Taxonomy Term, and Node Teaser I picked for my views.

Once you’ve made your selection, the Views application opens a form for each field allowing you to change the field label, define display characteristics for the date, and whether to link node titles with actual posts. If you don’t want a label for any field, leave the label field blank.

Once the fields are added, you can sort the field order by selecting the up/down sort order icon next to the Fields label. Either a drag and drop option is provided, or a way to renumber the fields is displayed, depending on your theme’s support for Ajax.

After sorting the fields, I next added a Page display. Clicking on the newly created display opens a form to add a URL alias for the display page. I used the same URL that pathauto uses when generating URL aliases for my web posts. Typically, it’s the name of the vocabulary, with white space converted to underscores, and extraneous words such as “the” removed.

After I added fields and a display, the results are previewed below the View defining form. At this time, all posts are displaying, but I only want those for a specific vocabulary, a specific type (Story), and that are published. To fine tune the View, I need to add Filter criteria.

Adding Filters is the same as adding Fields: click the plus sign (+) and you’ll be given a list of fields that will be used by the specific filter. For my View, I wanted the Node: Published, Node: Type, and Taxonomy: Vocabulary choices. Once selected, I’m given a form for each selection, allowing me to set the criteria for the filter item. For Published, it’s a Boolean value of True, for published posts. For the Taxonomy vocabulary, I picked the taxonomy vocabulary for which the view is defined. Lastly, I set the Node type to Story.

Once the fields have been selected and filtered, the remaining task on the data set is to sort the set by publication date, in descending order. Again, clicking on the plus sign (+) for Sort Criteria opens a selection of fields from which to choose. I selected Post date, and when given the form for defining the sort criteria, picked Descending and left the granularity at seconds.

The data set is now defined, and it’s time to focus on the display. First, though, a quick peek at the query used to define the View. Note that though the query is intimidating looking, the View is actually efficient, and best of all, cached by default.

I added a Page display already, but now I want to add a Page title, as well as fine tune how the page displays. The first column in the View form has several different options that, when you click on each opens up forms for making modifications. For my first run through on creating a View, I set the Style to List (other options are Table, Unformatted, and Grid), and the Row Style to Fields (the default, and necessary to select individual fields for the view). I also added a Title, which displays at the top of the page, set the number of items to display to 5, and added a Full pager (the display of page numbers for navigation below the listing of entries).

I save the View at this point, though technically you should save it at various times when creating the view, or risk loosing your work. The only thing left is to add a menu item for my Primary links for the new view, giving the URL defined for the view, and add some CSS styling for the newly generated list items. (View Source provides the class names used for the new display items).

Currently, you can check out the look of the View with my Ajax/JS topic page, but no guarantees how long this exact view format will last, because I’m in the process of tweaking the views (covered in the next sections). In the meantime, here’s a screenshot.

Row Style: Node not Fields

In the previous View definition, the Row Type in the Basic Settings was set to Fields, which means that I had to pick out the fields used for the View. Another approach I could have taken was to set Row Type to Node, in which case the fields displayed are defined in the node template. This simplifies creating the View because you don’t have to define every View field, nor do you have to add new CSS entries for the new View fields. I currently use this approach with my MisouriGreen Places vocabulary View.

Of course, by using the Node Row Type, you also don’t have fine control over which fields are displayed for the View, their order, or the CSS used. However, it cuts the time to create the View considerably.

I like the look of the View page just defined, but there’s one thing missing: the original listing of general Vocabulary terms for the Vocabulary that the Vocabindex module provided. I get postings for all terms, and I can click on the Vocabulary term associated with each posting, but there’s no way for a person to go to a specific type of posting, directly—or to discover easily what all the terms are for the vocabulary. That led to a little experimentation, and the final change I’m making to my Views.

Adding an embedded Block View within a Page View

What I want is a page that has two display items in it. The first is the listing of posts by vocabulary. The second, though, is a list of vocabulary terms, each linked to a separate page that lists just the posts for that vocabulary term. The logical approach would be to list the terms at the top of the post display pages. That led to the next iteration of my View design.

First, I actually created a new View just for my vocabulary terms, selecting the Taxonomy object in the view name page, rather than Node.

Since the View type is Taxonomy, rather than Node, the field choices differ, and your choice limited to the taxonomy related fields, such as Term and Term Description. Other than that, you can filter and sort, just like with the Node view created earlier. The only other option that differs from my Node page view earlier is that I set the number of items to display to unlimited, and I don’t attach any paging.

Lastly, the major difference with this view and the ones previously created is that I’m using the block display, rather than the page display type. This has one interesting impact on the view: when you use the block display, the View is added as an option to the Drupal Blocks page, which means you can use the View anywhere you can use a Block. This is pretty sexy stuff, and one has to hold oneself back before going mad with the possibilities.

Once the taxonomy term block view is created and saved, I next need to embed it in the Post page View.

I’m going to use embedded PHP to display the terms block view, so first I need to open up the Modules Administration page and check the one labeled “PHP Filter”, if I don’t already have it selected. Checking this installed module option adds a new Input format type: for PHP code snippets. This means that I can define the Input format for an item to be Filtered HTML, Full HTML, or PHP Code, and for the latter, Drupal processes the PHP code snippet as code, not text.

I then open the page-based view I created earlier, the Graphics vocabulary view for this example. In the View, there’s an option to add a Header for the Page display. By default, there is none, but clicking on it opens an input text box for adding whatever you want in the header. In my case, I’m going to be adding a little markup and some PHP.

I did a lot of exploration trying to find the code that would work to involve the block level View in the header of the page. The function that worked for me was module_invoke, a generic module hook function that can be used to invoke the code for any Drupal object. There’s some gaps in the documentation of this and other methods, but the following worked with my view:


The first three parameters are written out, as is, and don’t change. It’s the fourth argument that differs based on the block view’s name. For instance, my block view listing the terms for the Graphics vocabulary is graphics_terms. However, what you want is the delta for this block, which I found by actually going to the Blocks database table for the Drupal database, and looking for the delta field.

I discovered through experimentation that the general format for the block delta is block machine name-block-1, the machine name being what you gave the block view when you first created it. For instance, my graphics term view is named “graphics_terms” so the delta would be “graphics_terms-block-1”.

Once you have the block, returned from the module_invoke function call, you can print out any data associated with it. I’m only printing out the block content. Combined with some formatting markup, the text I added to the header for my Graphics vocabulary page is:


$block = module_invoke('views', 'block', 'view', 'graphics_terms-block_1');
print $block['content'];


<h2 class="page-title">Writings about Web Graphics</h2>

I also changed the Page title to “Web Graphics Categories” so that each section, terms and posts, will be titled appropriately in the page. You can see the result in the currently styled Graphics vocabulary page. Note that the terms are all listed out, and re-appear on each posting page. Since the view is cached, this duplication shouldn’t result in another query to the database. However, to simplify the page, I turned Ajax handling on for the pager (another View option). The page is now static, with only the posts updating, as you navigate through the pages.

Following is a screenshot of my non-tech vocabulary page, which demonstrates the combined terms/posting views.

I’m in the process of converting all my vocabulary pages over to this terms/post format, but as I learn more about Drupal, and as other modules are released, how I achieve this effect may change. If I do adopt another approach, I’ll update this page to reflect whatever changes I make.

In the meantime, to simplify the vocabulary creation, I’m using the Views clone capability (available in the Views List Page) to clone the Graphics vocabulary and Graphics terms views, and just making modifications where appropriate to change the text of the titles and the vocabulary item. The time to make these changes is only about 5 minutes for each vocabulary item.


There is another module currently in development, the Panels module, which seems to handle multi-dataset pages much more efficiently. For instance, I can create blocks that take arguments, and so create just one taxonomy term block, rather than have to create a separate one for each taxonomy term. I’ve tried to find out how to pass in arguments for block views using module_invoke, but no luck.

In addition, there are also View API functions, which might be a better fit for loading views. However, I’ve not had good luck with these, just yet, though I am still experimenting.

In the meantime, I have exactly the page I want when accessing each of my vocabulary menu items. Hopefully this might be useful for your own efforts, and if you have any questions, holler. If you have any refinements, or suggestions, please leave a comment and thanks in advance.

Now, what new Drupal toy should I try playing with next…


Thanks to a suggestion from Merlin, I’m now using the views_embed_view function to embed the view, passing in the taxonomy identifier as argument. The following screenshot shows the generic block view, which is defined like the block view above, except that rather than filtering on the taxonomy, the taxonomy identifier is passed in as an argument.

The code to use in the header for the Web node view uses the views_embed_view function, passing in the taxonomy identifier of 9 in the argument array, and the name of the view (‘terms_by_vocab’), and view display (‘Block’):


$arg[0] = 9;
$output = views_embed_view('terms_by_vocab', 'Block', $arg);
print $output;

<h2>Writings about the Web</h2>

The same generic taxonomy term block view can now be used to list out the taxonomy terms within each of the page views.


Kindle Coupon

I imagine this will kick start Kindle sales: MobileRead reports that Oprah Winfrey calls the Kindle her favorite gadget. All due respect to the Big O, I could care less, except that there’s supposedly a $50.00 coupon associated with her favoritism, which you can use when you buy a Kindle. The coupon code is OPRAHWINFREY, lasting until November 1.

I haven’t been writing much about my Kindle, something I plan on changing at my newly updated Just Shelley site. In the meantime, the Kindle is not a bad gift idea, and $50.00 saved is $50.00 saved.

PS Rumor has it that the UK Kindle is on its way, but you know how rumors are.

PPS Perhaps Om Malik will buy a Kindle for Stacey now that he can get a $50.00 discount.

PPPS Oops, no go for the UK Kindle just yet.


Maintenance Tasks

I’m incorporating my Just Shelley weblog into my regular feed, and several of the stories showed up “fresh” yesterday. My apologies for your getting inundated with my writing from yesterday.

We resolved the domain. I will be donating the domain to the SVG Interest Group, and they will be creating a Planet SVG as part of the new general SVG web site. Hopefully, we’ll be able to find more SVG-related feeds to add to the aggregation lists, as I know there are sites I’m missing.

I’ll keep the current aggregation site up and running until we make the transfer.

Just Shelley

Blogher Women in Tech Series featuring…Me

Virginia DeBolt did me the honor of interviewing me for her first Women in Technology series at Blogher. If you’re curious about my early years, my views on the semantic web, women in technology and how to modify the computer tech curriculum in order to obtain greater diversity, whether I like animals more than people, as well as some of the tech folks I read on a daily basis, you might want to check it out.

Warning, though, it is all about me, me, me.

And you will be tested.


OpenOffice for Aqua

Last week I made the switch from NeoOffice to OpenOffice for Aqua on the Mac.

I’m impressed with the overall appearance of the application, and the functionality. Most importantly, I was able to process Word documents with templates without problems and without loss of functionality.

The application is very fast and responsive on my PowerPC laptops, and from what I’ve read elsewhere, it’s actually better on the Intel-based machines. It doesn’t have the lag that I’ve found with newer versions of NeoOffice when clicking on a menu item and the menu contents displaying. Nor does it seem to absorb as much of the machine’s resources.

I can open and work on several different types of documents, at the same time, and not have performance or stability problems. Overall, it’s quite efficient, as well as including all the features most, if not all, of us need from an office toolset.

OpenOffice includes the following tools:

  • A fully featured text document editor, including support for both macros and templates, as well as all features necessary for sophisticated document creation and management. You can also track and show changes, as well as autocorrect and format, embed tables and images, add a media player, and incorporate a bibliography database.
  • A spreadsheet tool that provides any number of formatting capabilities, simple to use chart creators, all the spreadsheet functions you need and want, and some interesting Scenario and Solver tools I haven’t had a chance to explore.
  • A presentation tool with templates that can incorporate any number of graphics and themes, providing slideshows, the ability to package the presentation— the usual presentation software suspects.
  • A database creation tool that also uses ODBC and JDBC to connect to an existing database, either remotely or locally.
  • A drawing tool that provides a good deal of functionality in order to create nice looking illustrations.

The application is still in candidate release status, so you may want to wait until the finished release. However, if you’re a Mac user, with either a PowerPC or Intel-based machine, give the application serious consideration.

Did I happen to mention it’s open source?