Better support for sub-themes

The Custom Theme Settings API has been updated for inclusion in Drupal 6 and I will be backporting the D6 API for Theme Settings API 5.x-2.0. So let me briefly describe how phptemplate sub-themes will work in Drupal 6:

• Drupal 6 will have .info files for themes which will make sub-themes easier (and they won’t have to be subdirectories of the main themes.)
• Any file in the main theme’s directory will be used unless that filename exisits in the sub-theme’s directory. For example, sub-themes without template.php files will use the main theme’s template.php. Sub-themes with template.php files will NOT automatically have access to the main theme’s template.php; they will have to include that file if they want its functionality.
• (Not yet committed to D6. See #57676) Custom Theme Settings will be called from THEMENAME_settings() or phptemplate_settings() functions inside the template.php file.

I’m going to mark this lack of non-clunky sub-theme support as a bug. It will be fixed in 5.x-2.0.

The method you describe, Alexander, is probably the best way to do it with the 5.x-1.0 version of the module.

To make migration to 5.x-2.0 easier, I would do the following:

In the maintheme.theme file, write:

function common_settings($settings) {

  // Set the default values for the theme variables
  $defaults = array(
    'example_credits' => 1,
  );

  // Merge the settings and their default values
  $variables = array_merge($defaults, $settings);

  // Create the form using Form API
  $form['example_credits'] = array(
    '#type' => 'checkbox',
    '#title' => t('Show credits'),
    '#default_value' => $variables['example_credits'],
  );

  // Return the form
  return $form;
}
function maintheme_settings() {
  // Pass the saved theme settings
  return common_settings(theme_get_settings('maintheme'));
}

In the subtheme.theme file, write:

include "../maintheme.theme";
function subtheme_settings() {
  // Pass the saved theme settings
  return common_settings(theme_get_settings('subtheme'));
}

And then when 5.x-2.0 comes out you can nix the maintheme_settings() and subtheme_settings() and rename common_settings() to phptemplate_settings() and move it into maintheme’s template.php file.

A lot of people have their own Sauron-inspired, CSS-Zen-Garden-like theme. I’ve got one, too! Good luck; it’s doable.

About your P.S.:

The THEMENAME_settings() function just uses FAPI. So it would depend on what form widget you used. If you had a multi-value select box or series of checkboxes, I believe it will store those values as an array.

let me subscribe here... and say something to the currently so called "bug".

I've build a theme with ~20 subthemes. all themes have their own theme file, while they sometimes have different settings. The thing you are trying is a general problem until you do not have a page.tpl.php in your subtheme directory... if you have this problems i'm sure you do not have a page.tpl.php in the subtheme directory, isn't it? Therefor all the main theme *.tpl.php files are used while you have a "CSS only subtheme"...

To solve this problem you must create a page.tpl.php in D5. You can include the main files... but you need the page.tpl.php file. After this step you get what you want. Have a look to my yaml theme package... check out and see how to workaround this general theme engine problem in D5.

This is not a bug of this module... it's an unimplemented feature of theme engine in drupal core! i think this should be set to "won't fix" for 5.x or postponed to D6.

Spend some time on "YAML for Drupal" Theme http://www.yaml-fuer-drupal.de/de/download, please. I've done what you are trying, but you cannot get out with a CSS only subtheme without a page.tpl.php (+ node.tpl.php files and others) in the subfolder of a main theme. i've included the main theme files (for e.g. node.tpl.php) except page.tpl.php and you can take the idea out of my themes...

I know this is not what a theme developer expect. I hoped this is different when i started over, but it wasn't. If you'd like to get this working in a supported Drupal way you need to go the way i used or alter Drupal core. I think you don't like the last way and if you don't like the way i used - it may be unsupported.

Maybe there is another Drupal way (i'm not aware about), but nevertheless there is no need to change the module to support something Drupal themself do not support!

It now seems unlikely we need to fix this.