First off: great module. My friend and I were discussing writing our own similar functionality before stumbling across this and realizing that it's already been done. So thanks!

However, we're working on a site that uses Organic Groups with custom themes, and the DesignKit form_alter (which adds the fields for color and images that are defined in the theme .info file to the theme setting form) was not adding the custom DesignKit fields to the custom theme forms. We were able to trace this to the designkit_get_info() function in designkit.module, line 114:

/**
 * Retrieve designkit info for the site's default theme.
 */
function designkit_get_info($reset = FALSE) {
  static $info;
  if (!isset($info) || $reset) {
    global $theme_key, $theme_info;
    if (isset($theme_info, $theme_key) && $theme_key == variable_get('theme_default', 'garland')) {
      $info = $theme_info->info;
    }
    else {
      $default = variable_get('theme_default', 'garland');
      $result = db_query("SELECT name,type,info FROM {system} WHERE type = 'theme' AND name = '%s'", $default);
      while ($row = db_fetch_object($result)) {
        $info = unserialize($row->info);
      }
    }
  }
  return isset($info) ? $info : FALSE;
}

On line 121, there's an IF statement that checks to see if $theme_key and $theme_info are set, and checks to see if $theme_key is set to the default site theme:

if (isset($theme_info, $theme_key) && $theme_key == variable_get('theme_default', 'garland')) {

If that condition fails, then the ELSE statement that follows sets the theme to the default theme. Therefore, it seems impossible for any theme other than the default to be used.

By removing that second condition, the proper .info stuff is loaded, and the form_alter successfully adds those fields to the form.

Is that second condition necessary? If not, I've attached a patch to designkit.module which removes it.

CommentFileSizeAuthor
#1 designkit-custom-themes.patch462 bytesm.stenta

Comments

m.stenta’s picture

m.stenta
he/him
Primary language English
commented
StatusFileSize
new designkit-custom-themes.patch462 bytes

oops. forgot to attach the patch. :-)

yhahn’s picture

yhahn commented

Hm, so I feel your pain. At the moment, designkit uses a single variable namespace for storing its settings but really what it should do is prefix by the current theme name, e.g. "garland_designkit"

Let me think about the ramifications of this.

m.stenta’s picture

m.stenta
he/him
Primary language English
commented

Hey yhahn: thanks for the reply. We're working on this right now... and just discovered what you described (that it uses a single variable namespace) in the preprocess_page function...

/**
 * Turn design choices into theme variables.
 */
function designkit_preprocess_page(&$vars) {
  $info = designkit_get_info();
  $color = !empty($info['designkit']['color']) ? variable_get('designkit_color', array()) : array();
  $image = !empty($info['designkit']['image']) ? variable_get('designkit_image', array()) : array();
...

Would it make sense to use a separate database table to store specific image and color information on a per-group basis?

I'm very interested in getting this to work, and would be more than happy to lend a hand with the programming. I'd like to hear your thoughts on the best method to accomplish it, and/or the ramifications of such a change. Send me a message if you want to discuss.

Just out of curiousity... what's the difference between Spaces Design and DesignKit? Was Spaces Design the precursor to DesignKit?

amorsent’s picture

amorsent commented

I'm not sure that prefixing with the theme would be enough. Multiple spaces could use the same theme, but call for different settings.

I'd also like to know more about the difference between Design Kit and Spaces Design.

verikami’s picture

verikami commented

Hi guys :—)) I also do like this module and just walked to the same problem of differentiation...

For my taste simple namespaceing (I prefer sufixing) could be enough - however I do not know all the ramifications/relations with other projects... quick hack for color I'm using now:

////: designkit.module

// @: designkit_preprocess_page()
  
  $sufix = strtolower($info['name']);
  $color = !empty($info['designkit']['color']) ? variable_get("designkit_color_{$sufix}", array()) : array();

////:

////: designkit.admin.inc

// @: _designkit_form_alter()

  $sufix = strtolower($info['name']);
  $color = variable_get("designkit_color_{$sufix}", array());

// @: _designkit_system_theme_settings_submit()

  $sufix = strtolower($info['name']);
  variable_set("designkit_color_{$sufix}", $form_state['values']['designkit_color']);
  variable_del("designkit_color_{$sufix}");

////:

...however... it will be nice to know yhahn's thoughts...