Audean Wiki

User Tools

Site Tools

You are here: Audean Wiki for Mediacore services » Drupal at OSInet » Adding settings on Drupal themes
Trace:
dr:themesettings

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
dr:themesettings [2006/08/09 22:22] – fgmdr:themesettings [2020/11/23 17:23] (current) – external edit 127.0.0.1
Line 1: Line 1:
 ====== Adding settings on Drupal themes ====== ====== Adding settings on Drupal themes ======
 +===== WARNING =====
 +
 +A module called [[http://drupal.org/project/themesettings|themesettings]] by John Albin is now available on Drupal.org, with much more expanded functionality. The documentation on this page only applies to my initial proof-of-concept module, which should be considered obsolete now that this official module exists. The goals and basic mechanism are identical for additional settings, though, so you may want to read the explanation here since the code is in a much simpler form in the initial module.
 +
 +===== Themes need settings =====
  
 For some time now, I've been feeling the need to have some themes be more easily customizable by admins, without their needing to tweak files. Alas, the themeing system is normally limited to the smallest common denominator defined by <theme>_features, accessed from admin/themes/settings and admin/themes/settings/<theme> For some time now, I've been feeling the need to have some themes be more easily customizable by admins, without their needing to tweak files. Alas, the themeing system is normally limited to the smallest common denominator defined by <theme>_features, accessed from admin/themes/settings and admin/themes/settings/<theme>
Line 5: Line 10:
 Since tweaking the various themeing mechanisms seemed complicated, I took a short route, and created the "themesettings" proof-of-concept module. The idea is simple: if themes can't have settings, modules can register whatever path they want and then invoke whatever theme code they want to. So.... Since tweaking the various themeing mechanisms seemed complicated, I took a short route, and created the "themesettings" proof-of-concept module. The idea is simple: if themes can't have settings, modules can register whatever path they want and then invoke whatever theme code they want to. So....
  
-As the first step, we'll add new settings to a theme, by declaring a <theme>_settings function. The theme we'll be using for the demo is called "admin".+As the first step, we'll add new settings to a theme, by declaring a <theme>_settings function. The theme we'll be using for the demo is called "admin" and is basically the usual PHPtemplate-based [[http://drupal.org/project/box_grey|box_grey]] from Drupal.org
  
 ===== Adding settingability to themes ===== ===== Adding settingability to themes =====
- 
 ==== Creating the settings function for theme "admin" ==== ==== Creating the settings function for theme "admin" ====
  
-In the admin.theme file, we'll add the admin_settings function. If the theme is a plain PHP theme, it will already exist. If it is a PHPtemplate theme, the file will have to be created. +In the admin.theme file, we'll add the admin_settings function. If the theme is a plain PHP theme, it will already exist. If it is a PHPtemplate theme, as in the case of our "admin" theme, the file will have to be created. 
- +<code php>
-<php>+
 function admin_settings() function admin_settings()
   {   {
Line 27: Line 30:
     '#description'   => t('CSS string for a background color. It will be applied to nodes.'),     '#description'   => t('CSS string for a background color. It will be applied to nodes.'),
     );     );
- 
   return system_settings_form('admin_admin_settings', $form);   return system_settings_form('admin_admin_settings', $form);
   }   }
-</php>+</code>
  
 Proof of concept example, no more: we just define a setting for the theme to use later on. In this case, it will be a CSS background color. NOTICE: a true world example should not take input and store it without some sanity checks. Proof of concept example, no more: we just define a setting for the theme to use later on. In this case, it will be a CSS background color. NOTICE: a true world example should not take input and store it without some sanity checks.
- 
- 
- 
  
 ==== Using the setting: node.tpl.php ==== ==== Using the setting: node.tpl.php ====
  
 With the "admin" theme being based on PHPtemplate, we'll modify node.tpl.php to apply our parameterized color to all nodes. This example just changes the first line with an inline style: With the "admin" theme being based on PHPtemplate, we'll modify node.tpl.php to apply our parameterized color to all nodes. This example just changes the first line with an inline style:
- +<code php>
-<php>+
 <?php <?php
 echo '<div style="background-color: '  echo '<div style="background-color: ' 
Line 50: Line 48:
 if ($page == 0) ... if ($page == 0) ...
 [...the rest of the file is unchanged...] [...the rest of the file is unchanged...]
-</php>+</code>
  
-Ugly inline styling, but this is just a demo, so we don't care.+Ugly inline styling, but this is just a demo, so we don't care. I add the "! important" clause to make sure it is being forced even if rules cascade from elsewhere in the CSS files to change that background.
  
-===== The themesettings module =====+===== Hooking it up =====
  
-<php>+At this stage, we obviously have a color-parametered node.tpl.php, and a form-generating function that could store and retrieve that color.  
 + 
 +We now need to tell Drupal to stitch this together, and for this we'll need a module. 
 + 
 +==== The themesettings module ==== 
 + 
 +<code php>
 // themesettings.module for Drupal 4.7 // themesettings.module for Drupal 4.7
 // (C) 2006 FG Marand  // (C) 2006 FG Marand 
Line 145: Line 149:
   return $ret;   return $ret;
   }   }
-</php>+</code> 
 + 
 +===== How does it work ? =====
  
 +There's nothing magic to the module: 
  
 +  * it registers a set of paths in the admin area by implementing hook_menu
 +  * to know which themes implement this non-standard extension, it needs to know whether the <theme>_settings function is defined, so it loads the .theme file : by default only the current theme is loaded, and storing the function in the .theme file allows a minimal system load.
 +  * for PHPtemplate themes, the .theme file won't be loaded except for admin/theme/settings2/* pages, meaning this has absolutely no additional load on the system when not performing configuration.
 +  * for plain PHP themes, the .theme file is already loaded anyway, so parsing this function only adds a few CPU cycles, but no additional file inclusion, so the additional load remains minimal too.
  
 +Please try it and comment on [[http://blog.riff.org/2006_08_10_how_to_add_settings_to_custom_drupal_themes/|my blog]], or on IRC (I'm fgm #drupal).
dr/themesettings.1155162131.txt.gz · Last modified: 2020/11/23 17:23 (external edit)