Quick theme tip: abusing Drupal's $mission variable

Submitted by Nik on


Just a quick tip for an extra, more accessible theming variable. I have personally found that on nearly all the sites I’ve built, I’ve never had a use for the Mission variable. So it struck me that I could probably use this field to output something else; something relevant to the general workings of the site, for sure though.


So, on this site, I have edited the mission variable and put in the copyright notice that you see at the bottom of the page. I saved the config screen and carried on, thinking that it would just be working – I had tested it out on the front page, and the value was appearing where I had placed the $mission variable in the footer area in my page template. No problems, I thought.


Today, I actually noticed that this was not appearing, and I couldn’t work it out for a while, but I trawled through the phptemplate.engine, and in there is some code that conditionally sets the $mission variable on only the front page – perhaps that’s why it doesn’t get used so much?


Anyway, I opened up the template.php file for my theme, and placed in it the code below, in the _phptemplate_variables bit under case 'page' – see here. Now I have a usable variable across all pages of my site, with the added advantage that this is accessible from the admin interface at “site information”. I guess that the theme settings API in Drupal 6 may alleviate this problem, but for simple things like updating the year (which is contained in my © statement) in D5, this is a potential time saver (and face-saver) for administrators.

<?php
  // populate the $mission variable on every page so we can use it universally
  // don't check <front>, it's already handled in phptemplate.engine

  if (!$vars['is_front']) { 
    $vars['mission'] = filter_xss_admin(theme_get_setting('mission'));
  }
?>

Blog Tags: DrupalThemes

Comments

ksenzee replied on

That's a great idea. I've had clients install the theme settings api module for D5 to handle this kind of thing, but that's a bit too heavy if all you need is the copyright date.

Jakob Petsovits replied on

Personally, I prefer to have the copyright statement go into a block, then I don’t have to interfere with the page.tpl.php. Even the traditional mission statement on the front page could go into a block (conditionally showing only on <front>), and it seems like Drupal 7 will go into this direction.

Nik replied on

I understand what you’re saying Jakob – this is perhaps just a tip for those smaller sites where the site editor does not have block access/control. I have personally tended to adopt the method you mention here for more complicated layouts.

For example, if I want to put a closure statement and/or a footer menu, I might need to duplicate a block – in this case I may need to use a php snippet, which Mission does not offer. In this case, a block is the obvious choice. Abusing the mission variable is really basic, and stays within the confines of the simpler side of the administrative interface.

Daniel Nordstrom replied on

Cool. I've used something similar:

$vars['mission'] = variable_get('site_mission', '');

Nik replied on

I have a suspicion that the filter_xss_admin() function used in the initial example (taken from core, as I explained) may be there for a very good reason.

Of course, it’s a fair assumption that the variable is safe, but there is a chance that an administrative user could unwittingly enter data that would allow some kind of attack.

Add new comment