Big news! At long last, the DP has launched it’s first public web site on Drupal at http://34st.com for our weekly arts and entertainment magazine, 34th Street. We’ve been working on developing an alternative to College Publisher since I started my term as Web Editor-in-Chief at The Daily Pennsylvanian in January. After months of waffling and pressure we decided to move ahead with development and committed to launching a new website. And finally, we’re here.

Theming with Zen

Last time, I wrote about the data structure underlying our website running on Drupal and promised that I would write again about theming.

The Drupal theming layer is quite powerful, but can also quickly become incredibly complex. It also depends on module developers to play nicely and make all their code easily themable. It also requires a designer to learn how to work with Drupal and all it’s eccentricities.

Drupal themes depend on layers of overrides and hooks. Drupal core provides a default layout, which can then be modified by modules, then the template engine, then the theme and finally an optional subtheme. At each layer the previous output can be modified or overridden. That way, if someone were designing a set of themes or wanted to present options for a user to customize the site’s look and feel it could degrade gracefully.

Since we weren’t worrying about any of those things, we did nearly everything in the top-most sub-theme layer.

Luckily for us the Zen starter theme makes much of this easier.

To develop our theme, we were lucky enough to have a great starting point in the amazing Zen starter template and it’s great documentation. We made a Zen subtheme as a folder within Zen with their Starter Kit.

Note: One big mistake I made when we started working on our subtheme was naming it “34st”. As it turns out, many of the theme override functions require you to name them THEMENAME_functionname. Unfortunately, PHP variables can’t start with numbers so after some frustration and griping I had to rename the subtheme.

node-type.tpl.php
Content Templates provides a view of all available variables and example values.

Many places advise themers to use the Content Templates module to theme different content types. With Zen however, I found it much easier to just create files in the sub-template directory with certain naming conventions. For our article content type, a file named node-article.tpl.php themes it. For an issue, node-issue.tpl.php contains the theme. Since these files are theming a node, it’s possible to see all the variables in the array by simply doing a <?php print_r($node); ?> in a human-readable format. Content Templates, however can do the same thing, and with a much nicer interface.

For the most part, after finding all the appropriate variables, we simply plopped them into the appropriate places in the template. But, within these template files, we still have complete access to PHP and the entire Drupal API. Which of course means that I get lazy. <pre lang="PHP" line="1">field_byline[0]['view'] != '') && ($node->field_byline[1]['view'] == '')): ?> <div class="article-byline"> <div class="author-teaser-name-nodelink">By field_byline[0]['view'] ?></div> </div> field_byline[0]['view'] != '') && ($node->field_byline[1]['view'] != '') && ($node->field_byline[2]['view'] == '')): ?> <div class="article-byline"> <div class="author-teaser-name-nodelink">By field_byline[0]['view'] . ' and ' . $node->field_byline[1]['view']; ?></div> </div> field_byline[0]['view'] != '') && ($node->field_byline[1]['view'] != '') && ($node->field_byline[2]['view'] != '')): ?> <div class="article-byline"> <div class="author-teaser-name-nodelink">By field_byline); print $node->field_byline[0]['view']; for ($i=0;$i<$numauthors-1;$i++) { print ', ' . $node->field_byline[$i]['view']; } print ' and ' . $node->field_byline[$numauthors-1]['view']; ?> </div> </div> </pre> That’s my code for handling all the different possibilities for multiple authors on a single article. For more elegant code, this should be higher up in the templating than the .tpl.php file, but it’s much easier this way.

Teaser versus Full views
For each field, one chooses how it will be displayed in the teaser, and in the full node.
For each field, one chooses how it will be displayed in the teaser, and in the full node.

For each field in a content type, you can choose two ways of displaying it. The Teaser is used when the node is being viewed on the front page, or in a section listing, and Full is the whole article is being read. Pretty self-explanatory. But it does mean that in each .tpl.php file you have to theme both. Here’s a sample.

We also get other fun template variables like $is_front so we can do things like so.

elseif ((($teaser) && (!$page) && ($is_front)) || (($page) && ($teaser))):
	/*
	 * This first case is for articles that are on the front page or in the sidebar.
	 * articles in the current issue. The second half of the OR only happens when node_view is
	 * manually called like node_view($node_object,$page=TRUE,$teaser=TRUE);
	 *
	 */

For reference, here’s the three different views of a single article.

if ((($teaser) && (!$page) && ($is_front)) || (($page) && ($teaser))):
if ((($teaser) && (!$page) && ($is_front)) || (($page) && ($teaser))):
if (($teaser) && (!$page)):
if (($teaser) && (!$page)):
if (($page) && (!$teaser)):
if (($page) && (!$teaser)):
Importing Data

We received our archives from College Publisher as a set of CSV files. My next post will address how we imported those archives.

What did you think of this post? Got more questions about our Drupal install? Leave a comment. The new website is 34th Street Magazine, poke around and leave us some feedback!

How we did it in Drupal, Part 2 of X
  1. How we did it in Drupal, Pt. 1 of X - The Data Structure
  2. How we did it in Drupal, Pt. 2 of X - Theming with Zen