Problem/Motivation

Site has 2 themes enabled, Theme A is the default theme, Theme B is also enabled. I make several blocks and edit their skins with the Skinr UI under the section for Theme A. I do not add any skins to these blocks under Theme B. Everything is happy when viewing these blocks on most pages.

The same blocks are also displayed on pages that are part of an Organic Groups, "Group A", ie. withing an OG context. Group A has a group_theme field (compliments of OG Theme module) set to Theme B. I want pages that are part of the Group A context to use Theme B which is not the site-wide default.

When I view pages within the group context (such as Group A front page or articles posted to Group A), the rest of the page uses Theme B as it should. But Skinr uses the skin settings from Theme A and NOT Theme B. In other words, within a group context, Skinr ignores the group's theme setting and applies skins to blocks using the default theme settings.

Skinr = 7.x-2.x-dev
Organic Groups = 7.x-1.1
Organic Groups Theme = 7.x-1.0

Proposed resolution

I have modified function skinr_current_theme(...) in skinr.module. I added an 'if' block at the end of the function to check for the presence of an OG context and if so, check the group entity for its group_theme field and return that theme instead. It's working well for my site now.

The function now reads:

function skinr_current_theme($exclude_admin_theme = FALSE) {
  global $user, $custom_theme;
  
  if (!empty($user->theme) && drupal_theme_access($user->theme)) {
    $current_theme = $user->theme;
  }
  elseif (!empty($custom_theme) && drupal_theme_access($custom_theme) && !($exclude_admin_theme && $custom_theme == variable_get('admin_theme', '0'))  ) {
    // Don't return the admin theme if we're editing skinr settings.
    $current_theme = $custom_theme;
  }
  else {
    $current_theme = variable_get('theme_default', 'bartik');
  }
  
  // Here's what I added: *********************************************
  if($group = og_context()){
    // We're in an OG context so use the groups' theme unless we're on an admin page
    $group_theme = $group->getEntity()->group_theme['und'][0];
    // does this access check take into account the possibility of $group_theme being empty or non-existent?
    if($current_theme != variable_get('admin_theme', '0')){
      $current_theme = $group_theme;
    }
  }
  
  return $current_theme;
}

Remaining tasks

I am very new to Drupal, I've only been doing this for about 2 weeks and I'm an embedded developer by trade, not a web guy. So I would be very happy if
a) someone tested my code or tells me there's some simple fix for this I'm not seeing
b) someone tells me what I'm doing wrong/right--I really want to learn this Drupal thing properly

Thanks All!

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

noland’s picture

And is this even a Skinr problem? Or should it be fixed by OG Theme?

noland’s picture

Title: Organic Groups theme not applied in group context » Organic Groups theme skins ignored in group context
noland’s picture

And I have no idea what the 'und' is for in "group_theme['und'][0]", what is that for? is that going to break under some conditions?

moonray’s picture

Hrm. Well, adding support for OG specifically is a bad idea. It'll work for you purposes, but for the general purpose it's better to determine why Skinr is picking up the default theme and not the overridden one. The most likely reason is that the overriding is done after Skinr does its thing; we'd have to somehow change the order. (the OG context probably sets the global $custom_theme variable)

As for 'und'... it's short for undefined, which the the LANGUAGE_NONE constant defined by drupal core. If multiple languages are enabled, the value will change depending on the set language of the OG.

moonray’s picture

Issue summary: View changes

removed the tag within

noland’s picture

Status: Active » Postponed

Ok. So the above fix is working for me now and once I get more comfortable with things I can look into OG Theme and perhaps a better way to achieve the theme change.

noland’s picture

Issue summary: View changes

fixed a bug that was generating warnings in my fix, I apparently don't know how to use drupal_theme_access()

moonray’s picture

Status: Postponed » Needs review
FileSize
7.3 KB

Skinr's checking for the current theme was based off of Drupal 6 implementations. This patch upgrades it to use Drupal 7 checking which makes it compatible with themekey and og_theme modules.

  • Commit ffd1aaa on 7.x-2.x by moonray:
    Issue #1311046 by moonray: Fixed custom theme detection for...
moonray’s picture

Status: Needs review » Fixed

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.