Blocks are not inherited when switching themes

Getting this for Minnelli also, installing was no problem but thereafter visiting the blocks page content disappears, Garland no problems.

Sorry, no idea why the priority auto switched back to normal, resetting....

Uhm, have you installed fresh or just updated HEAD and run update functions? Because this block was introduced in an update function which was added earlier and then modified, if you updated HEAD, you won't get this block.

I updated from head, but then as test dropped the db and did a clean install, same problem.

Ok, reproduced. No blocks are inherited from Garland in D7 when switching themes.

subscribe

BTW, to temporarily fix this issue in your system, run this SQL command:

UPDATE block SET status=1, region='content' WHERE delta='main';

That will enable the content block and place it in the content region. You'll still need to enable some additional blocks on admin/build/block to get things working right, but that will get you started.

Marked #473108: Empty page when changing the theme as duplicate of this.

I pictured the block being moved during theme enable. chx pointed out though that something very funny is going on.

D7 seems to be doing "make a tab for every theme in the themes/ directory."
D6 does "make a tab for every theme with its "enabled" checkbox checked."

D7's behaviour is wrong and should be fixed.

Can confirm that the behaviour one would expect, where when you enable a theme and its content region gets populated, appears to be happening. The problem is with D7's access check which is not properly hiding themes it should be. Thus people are going into this page without hitting the themes page first and "hilarity" is ensuing.

Chx has a fix for the access callback. Patch coming up shortly.

The patch in #12 works to show the main block.

Regarding #13. D7 also only makes a tab for every enabled theme. The problem is that it comes with no theme enabled and then it displays the tabs for all themes while D6 doesn't.

Even if you do enable the themes, you still need the patch cause no content is shown otherwise when you change the theme, but... the patch works only in the initial case of no themes enabled.

Third try...

Better text, comment, no code change. This does not fix the real bug here but nevertheless it's a bug to be fixed.

Committed #19 with a few more comments since I was killing time waiting for test bot.

So now we've solved yoroy's original bug, which is that tabs are accessible which really ought not to be.

Back to active now for the "real" bug, which is that when you switch your theme you lose your entire page. Fun!

+  // This function needs to fire before the default theme changes, so it's
+  // easiest to fire first.

Why?

+    $count = db_query("SELECT COUNT(*) FROM {block} WHERE theme = 'stark'")->fetchField();

We no longer do SELECT COUNT queries because they are slow on InnoDB. The new pattern is like:

$has_blocks = (bool) db_query_range('SELECT 1 FROM {block} WHERE theme = :theme', array(':theme' => $theme), 0, 1)->fetchField();
 

+class NewDefaultThemeBlocks extends DrupalWebTestCase {
+  function testNewDefaultThemeBlocks() {

PHPDoc plz!

+    $admin_user = $this->drupalCreateUser(array('administer site configuration'));
+    $this->drupalLogin($admin_user);

In another issue, we should really look at moving this to setUp().

Also, are these tests extensive enough to cover the issue? Should we not check for "content" explicitly?

As pointed out in #17 it's also a bug that on a clean install of HEAD no themes are enabled. When visiting admin/build/themes you only see the "default" checkbox lingering with Garland but none of the "Enabled" checkboxes are, well, enabled.

@tstoeckler: That is indeed also a bug, but not a critical one that prevents anything from showing up when switching themes. So unless it's shown that the two are directly related, I'd prefer to fix that relatively minor bug in some other issue.

Much more through test. More comments.

Created: #477800: No themes enabled upon install

Awesome work, chx!! :D

Touched up the comments a bit and committed to HEAD!

Dare I mark this fixed? :)

Yes, it works now on a fresh install. The "bug" in #17 I think it can be ignored now since it's partially fixed. Now, even if no theme it's enabled, the tabs aren't displayed on block page anymore. If the user enables a theme the default one will be marked as enabled too.

Now we need a review on #477018: Reordering blocks doesn't work as it should cause the block ordering doesn't work properly.

ups, changed the status by mistake

should not be the _block_themes_access() fix backported to D6?
also similar, wrong access check is used in the system.module

function _system_themes_access($theme) {
  return user_access('administer site configuration') && ($theme->status || $theme->name == variable_get('admin_theme', 0));
}

this is also wrong then (code from system.admin.inc)

$theme->name == variable_get('admin_theme', 0)

let's fix the problem everywhere..

my concerns are solved in this issue #542828: Do not special case disabled admin theme