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!
Comment | File | Size | Author |
---|---|---|---|
#6 | skinr-custom_theme_detection-1311046-6.patch | 7.3 KB | moonray |
Comments
Comment #1
noland CreditAttribution: noland commentedAnd is this even a Skinr problem? Or should it be fixed by OG Theme?
Comment #2
noland CreditAttribution: noland commentedComment #3
noland CreditAttribution: noland commentedAnd 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?
Comment #4
moonray CreditAttribution: moonray commentedHrm. 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.
Comment #4.0
moonray CreditAttribution: moonray commentedremoved the tag within
Comment #5
noland CreditAttribution: noland commentedOk. 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.
Comment #5.0
noland CreditAttribution: noland commentedfixed a bug that was generating warnings in my fix, I apparently don't know how to use drupal_theme_access()
Comment #6
moonray CreditAttribution: moonray commentedSkinr'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.
Comment #8
moonray CreditAttribution: moonray commented