Quick theme tip: abusing Drupal's $mission variable


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

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.

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.

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.

Cool. I've used something similar:

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

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