When creating a multisite setup using just the 'settings.php' file to control the theme(s), and a fresh database, only 'Bluemarine' works - All other themes fail to load in this manor.

This can be circumvented by using a working ('Bluemarine') theme, logging into each site individually, selecting the relevant theme from the 'Admin' interface, logging-out then modifying 'settings.php' to suit... but this isn't ideal, especially if you have many sites.

I apologise for not mentioning this sooner as I did notice this back in 4.6, but hopefully it can be fixed in time for the official 4.7 release.

CommentFileSizeAuthor
#6 bootstrap.conf.require_once.patch884 bytesnjivy
#3 bootstrap.conf.init.patch410 bytesnjivy

Comments

njivy’s picture

njivy commented
Title: Multisite 'Theme' issue » $conf in settings.php not honored

I am experiencing the same problem: The values of $conf as defined in settings.php are lost.

A little probing suggests that variable_init() receives an empty $conf array when it should not. I'm still poking around.

njivy’s picture

njivy commented

conf_init() improperly initializes $conf to array(). 

function conf_init() {
  global $db_url, $db_prefix, $base_url, $base_path, $base_root, $conf;

  $conf = array();
  require_once './'. conf_path() .'/settings.php';

As the next line of code suggests, the settings.php file may have been loaded previously. If so, $conf should not be emptied.

I encountered this bug because I applied Jeremy's filecache patch (http://drupal.org/node/45414), which also loads settings.php.

I am working on a patch.

njivy’s picture

njivy commented
Status: Active » Needs review
StatusFileSize
new bootstrap.conf.init.patch410 bytes
njivy’s picture

njivy commented
Status: Needs review » Active

Some people in #drupal have suggested this patch introduces security concerns.

chx’s picture

chx commented
Status: Active » Needs work

I do not know whether the problem is fixable at all, if register globals is on, then you are opening a huge security hole, so $conf must be properly init'd.

njivy’s picture

njivy commented
Title: $conf in settings.php not honored » $conf reset when settings.php require()'d before conf_init()
StatusFileSize
new bootstrap.conf.require_once.patch884 bytes

This patch intends to ensure that $conf is initialized before loading settings.php and that the process occurs only once.

Jeremy's filecache patch (http://drupal.org/node/45414) would also need to be updated to reflect the change in this patch.

A grep through Drupal core and contrib revealed no other instances where settings.php is loaded.

chx’s picture

chx commented
Priority: Critical » Normal
Status: Needs work » Closed (won't fix)

You are fixing something which is not a bug but will be introduced as a bug b another patch. That's not a good idea.

chx’s picture

chx commented

oh, and Panther's issue is IMO fixed in HEAD.

Panther-2’s picture

Panther-2 commented

Hi njivy & chx, thanks for your input so far.

I'll check the latest CVS (HEAD) later and see if the 'Theme' issue is now resolved.

Panther-2’s picture

Panther-2 commented

The 'Theme' issue is *still* a problem even within the CVS build (from the Drupal 'Download' section).

Though this bug has been downgraded to 'Normal' priority please bear in mind users of these multisites/subdomains are unable to login in any obvious way... as that block is not shown.

Maybe njivy's patch can be reconsidered ???

njivy’s picture

njivy commented

Panther, are you using a standard Drupal CVS installation without any modifications?

Also, is the theme you specify using $conf in settings.php already "enabled" in Drupal?

chx’s picture

chx commented

Oh, I thought it's the $conf is ignore issue. No this is something else, but it's won't fix too, because the current theme is not something you set in $conf. You can however, both in 4.6 and 4.7 use the PHP variable $custom_theme, like this: $custom_theme='pushbutton'; this will force the theme to be pushbutton.

Panther-2’s picture

Panther-2 commented

njivy: I'm am using the which-ever version is supplied through Drupal's 'Download' section ('CVS' option within the pulldown menu).

chx: I apologise if I'm being stupid, but now I'm a little confused. How/where should I use $custom_theme='THEME_NAME'; and is this really necessary ??? If it's the case that $conf = array('theme_default' => 'THEME_NAME'); does not work can it please be removed from the instructions at the bottom of 'settings.php' ???

njivy’s picture

njivy commented

The $conf trick should work, but only if the theme is already "enabled" in Drupal.

chx’s picture

chx commented

Oh, theme_default also works, you are right.

In 4.7 you will be able to cook an install profile which enables the theme for you because njivy is right that you need it enabled before the $conf can be used.

Panther-2’s picture

Panther-2 commented

So the theme needs to be 'Enabled' first, that's fair enough (now I know), but how exactly can I do this without logging-in each time/what do you mean by 'Cook' ???

Is there another variable I'm unaware of, like $conf = array('theme_enable' => 'THEME_NAME'); (this would be the most logical/obvious option) ???

I apologise again if this is a stupid question but I want to be 100% clear on what needs to happen - Probably worth mentioning this in the multisite notes/'settings.php' as well.

chx’s picture

chx commented

there is a hook_install now. that's all.

pulpzebra’s picture

pulpzebra commented
Version: 4.7.0-rc3 » 4.7.0

Drupal 4.7.1/Register_globals ON/PHP 5.0.4/Multisite installation

I noticed a strange behaviour from drupal here... Although themes are enabled, if I set a theme via the $conf array, only the bluemarine theme exposes the user and navigation menu. Therefore, not only I need to enable the theme I need to use, which is quite ok, but I also need to activate the basic menu blocks for each theme.

Is there a way to get around this?

Thanks,

Paolo

njivy’s picture

njivy commented

Please open a new bug report or feature request for new questions.