The block X was assigned to the invalid region Y and has been disabled.

I am seeing the same thing. Also getting 'Can not write to file-system' in Status Report.

Is this just the wrong place to post this issue? I am having the same problem. Is it a Boost issue? Theme issue? It only started to effect my site when we upgraded to 6.22

subscribing

I am having the same problem for more than two weeks now. Should I disable the boost module?

I am experiencing this issue also and tracked it back to the 6.22 upgrade. I'm also getting the same message for a module generated block for the station module, so it doesn't appear to be solely the boost module that is throwing this error message.

Subscribing, seeing the same thing as redraven with other modules and 6.22 as well.

subscribing, same error message on cache clear with drupal-update to 6.22:

The block Boost: Pages cache status was assigned to the invalid region right and has been disabled.
The block Boost: Pages cache configuration was assigned to the invalid region right and has been disabled.
The block Boost: AJAX core statistics was assigned to the invalid region right and has been disabled.

is there any way yet to get rid of this warning?

i figured out that the new method function block_flush_caches() in block.module in drupal 6.22 iterates through all active themes with _block_rehash($theme). It seems to me that the error "The block XXX was assigned to the invalid region YYY and has been disabled." is thrown when an activated theme is not implementing the region YYY.

a var_export in _block_rehash of the $regions gives me

array ( 
   'sidebar_first' => 'First Seitenleiste', 
   'sidebar_second' => 'Second Seitenleiste', 
   'navigation' => 'Navigationsleiste', 
   'highlight' => 'Highlighted content', 
   'content_top' => 'Inhalt oben', 
   'content_bottom' => 'Inhalt unten', 
   'header' => 'Kopfbereich', 'footer' => 'Fußbereich', 
   'page_closure' => 'Page closure',
   'right' => 'dummy region due to drupal bug 622', 
)

array ( 
   'sidebar_first' => 'First Seitenleiste', 
   'sidebar_second' => 'Second Seitenleiste', 
   'navigation' => 'Navigationsleiste', 
   'highlight' => 'Highlighted content', 
   'content_top' => 'Inhalt oben', 
   'content_bottom' => 'Inhalt unten', 
   'header' => 'Kopfbereich', 
   'footer' => 'Fußbereich', 
   'page_closure' => 'Page closure', 
)

array ( 
   'left' => 'Left sidebar', 
   'right' => 'Right sidebar', 
   'content' => 'Inhalt', 
   'header' => 'Kopfbereich',
   'footer' => 'Fußbereich', 
)

array ( 
   'left' => 'Left sidebar', 
   'right' => 'Right sidebar', 
)

array ( 
   'left' => 'Left sidebar', 
   'right' => 'Right sidebar', 
   'content' => 'Inhalt', 
   'header' => 'Kopfbereich', 
   'footer' => 'Fußbereich', 
)

As you can see,
the second theme doesnt have the region right (which was the Region with errors for me), the first one has, i already fixed this.

After that, i gave the second theme (in my case it was the zen original theme) the region "right" and the warning was gone.

Just a Wordaround but it works:

Give all your active Themes the Regions that produce the error by manipulation their theme.info-File and add the Region to the regions[]-Array.

+1

subscribing

I do not currently use the Boost module, but this happened for other module blocks after upgrading to 6.22. I believe it occurred because the upgrade process requires you to switch to a default core theme while your site is offline, which may have caused the assigned regions to change.

The somewhat ugly but effective workaround I used was to manually edit the database "blocks" table to remove the offending invalid regions from the blocks in the default theme used during upgrade, which was no longer in use after the 6.22 upgrade. After removing the invalid region from the blocks, I no longer received the "assigned to the invalid region right and has been disabled" messages.

It's worth noting that I also had numerous blocks still assigned to previously deleted contributed themes. I used the sitedoc module to clean these out, though likely could have done this manually as well.

I'm not using the Boost module either, but I have been having this same issue and was searching like crazy. Thank you for your post ZenLax. I went into the database and cleaned it up and it went away.
Is there some other place that we need to post this information?

Dan

+1

Subscribing

Please create all the regions in theme.info file,then it will be work.
thnks,

This is a core bug in 6.22, isn't it?
I have the same problem with the File Framework module

May be this needs to be directed to the Drupal 6 project?

I've been having the same problem and cleaning the blocks table only fixes the problem until the next time I either clear the block cache or go to /admin/build/block/instances. Then the same offending entries are written back to the block table. Tried adding the offending regions the the theme.info file and that did not fix it either. This makes 6.22 an upgrade that is not very usable so I'll have to stay with an older "unsecure version". Has any one come up with a solution that works????

I defined the "offending" region (which was "right" in my case) to my theme, and finally got quiet.
I simply duplicate a theme region, without side effect until now.
Nevertheless, 6.22 is buggy and must be fixed.

Nothing to do with Boost
Changing for a "Bug" category in "Drupal core" issue list, "Major" as it is really annoying

To add to #comment-4660666 (#8 above by jaykaycgn) and other posts, if there are any themes that are enabled (checked) in the Themes list, whether it's your selected theme or not, and you have blocks or other elements in a region that is not defined in ALL of the enabled themes, this error will pop up.

My selected/primary theme is a subtheme of Zen, and the subtheme has a region left that's not in Zen and I was getting the error. I had to disable/uncheck Zen to get the errors to stop. (I didn't want to edit Zen and add the offending regions to stop the errors as others have suggested because I don't maintain Zen and didn't want to have to re-apply the changes anytime I update it.)

This is definitely a bug that should be fixed because you'd expect this kind of region checking behavior for only the selected theme and no others, including parent themes like Zen.

Even with only one theme enabled and the block database cleared up, the error fired.
I could only solve it by creating a fake "right" region that I hope will not break something in my theme 'I just copied the "sidebar last" code in my Acquia slate theme

Has this been solved?

If not, in the meantime, is there a way to stop the notifications from being shown to anyone other than the administrator?

Thanks.

I use this when deploying from a staging environment to sandboxes and production:

THEME=$(drush @$SITE vget theme_default|awk '{print $2}')
drush @$SITE sqlq "UPDATE blocks SET region = '' WHERE (region = '-1' AND theme = $THEME);"

Not pretty, but it works for any $SITE with a drush alias.

subscribing

sub this is a major hold up for me... this is months old now and a major issue, is anyone working on it?

Hello guys,

I am also having the same issue and here is where I think the issue comes from. If you look at the boost.module file here is the code:

function boost_block($op = 'list', $delta = 0, $edit = array()) {
  global $user;

  switch ($op) {
    case 'list':
      return array(
        'status' => array(
          'info'   => t('Boost: Pages cache status'),
          'region' => 'right',
          'weight' => 10,
          'cache'  => BLOCK_NO_CACHE,
        ),
        'config' => array(
          'info'   => t('Boost: Pages cache configuration'),
          'region' => 'right',
          'weight' => 10,
          'cache'  => BLOCK_NO_CACHE,
        ),
        'stats' => array(
          'info'   => t('Boost: AJAX core statistics'),
          'region' => 'right',
          'weight' => 10,
          'cache'  => BLOCK_NO_CACHE,
        ),
      );

The region is calling its "right".

I am currently using Acquia Propser and the region doesn't exist.

So I know where the code is coming from, but what can we do to change this issue on every empty cache we do.

Help is needed!

David

I've hit this with D7.8. I strongly suspect this in 8.x as well.
This basically makes the feature, where blocks can define default regions, completely useless. As soon as you have an admin theme with less regions than your front-end theme (*cough* Seven
*cough*) you get notices on every _block_rehash() i.e. every cache clear.
I'm not sure this is major, though. I personally like the feature very much, but it is not really widely used.

So it is a Boost bug?

No it's not. It is valid for any module that provides blocks which set a default region in hook_block_info. Those aren't very many, but it's a core bug nonetheless.

Hi guys!

So I figure this out. I am no longer having this issues. So the problem is with the boost module problem. So if you have it installed, uninstall it first. You have to disable it first, then uninstall it. Then remove it from your files over the FTP. Then, make the change to the block region according to your theme. Mine was Acquia Prosper, so I made it like this:

/**
 * Implementation of hook_block().
 */
function boost_block($op = 'list', $delta = 0, $edit = array()) {
  global $user;

  switch ($op) {
    case 'list':
      return array(
        'status' => array(
          'info'   => t('Boost: Pages cache status'),
          'region' => 'sidebar_first',
          'weight' => 10,
          'cache'  => BLOCK_NO_CACHE,
        ),
        'config' => array(
          'info'   => t('Boost: Pages cache configuration'),
          'region' => 'sidebar_first',
          'weight' => 10,
          'cache'  => BLOCK_NO_CACHE,
        ),
        'stats' => array(
          'info'   => t('Boost: AJAX core statistics'),
          'region' => 'sidebar_first',
          'weight' => 10,
          'cache'  => BLOCK_NO_CACHE,
        ),
      );

Then reuploaded the files and installed the module again. Then it was not displaying that error any longer!

The issue is with some database settings that even if you update the file boost.module and clear cache it will still have the issue. The settings are already stored in the database and that is why is still showing those issues.

I know there is an easier way to do this on the PHPADMIN side with an SQL query, but I am not much of an expert to do this. So I guess I did it the long way. Perhaps someone can make a command to charge the "right" region in to "whatever region needs to be made. Like a template for others to use with their own theme.

Hope this helps you guys as this helped me.

David

@dmendo11: as reported before (#8 + #28), this is not contrib module problem, but core (block module) issue.

It would be really nice to fix this in D8 and backport to D7..although problem first emerged in D6..

Will try to write issue summary..

Added more info into issue summary..

First D6, then D7, and finally D8 looks more appropriate.
Not many can actually use D7, with only very few stable contribs available, and D8 is not in sight for anyone at this point....

@jvieille: Please read Backport policy.

After this will be fixed in D8, you can add tags: Needs backport to 7.x + Needs backport to 6.x.

Fixed dead link.

Added info how to reproduce problem + proposed solution..

I found that _block_rehash() is called in 4 places in both D7 and D8; block.admin.inc, block.module, block.test, and dashboard.module. What should be the correct behavior? Seems like 4 choices:
1) Flag as error, as is done now.
2) Set drupal_set_message( ..., FALSE) so message only sent once.
3) Skip adding the block to the theme being processed.
4) Stick the block in a convenient hole, such as the theme's default region, for the theme being processed.

On 3 and 4, what should be done with the block's enabled/disabled status? Because according to documentation, the error should be raised if the theme is the current default theme.

I think we just remove the drupal_set_message() with a comment explaining that it's a perfectly valid thing to do, to assign blocks to a non-existing region. The blocks get disabled anyway, and that's expected behaviour if the region they were meant to be in, doesn't exist.

So does anyone have anything to reproduce the error for a test?

In a custom module (block_test.module) make a new block and assign it to the 'invalid_region' region.

Nice to see some potential action on this! Thanks.

Attached a patch that check the block status is set to 1, instead of removing the message completly. While assigning a block to a non-existing region is valid, having an active block assigned to an non-existing region is not, so we shall imho still issue a message in this case.

That's not correct.
It's the very same use-case that was discussed above. When providing defaults in hook_block_info(), you can also set its default status as 1, so that's a valid code path. Just removing the drupal_set_message() and maybe a comment should be fine.

While yes, it is valid code to define a block in a specific region with a status of 1, seems to me it is not a valid assumption to make. It has use cases, and can be pretty convenient in a custom module geared toward a specific site, eg for zero touch deployment.
For anything contributed, I find it an invalid behavior still, in the way that it relies on assumptions on what themes (and regions) will be available or not. So think we should still warn about it, maybe in an "info" message instead of a "warning".
Checking the status node simply ensure this message will only be displayed once, whereas in current config, (under certain circumstances) you can have it displayed everytime _block_rehash() is called.

Checking the status node simply ensure this message will only be displayed once, whereas in current config, (under certain circumstances) you can have it displayed everytime _block_rehash() is called.

If that is the case, then I redact my objection. I still think showing a notice for something that is really a core feature (however useful it may be) is kind of weird, but I can live with a one-time message, and I'd like others to chime in.

Minor change..

and I'd like others to chime in

Sure, can't tell I have a very firm opinion on this anyway ;)

What was used to test this patch?

FYI I have this problem on 2 D6 sites - Boost module NEVER installed.

That's nice to have a patch for D8, however, it has little chance to be reviewed by the community as D8 does't even exist for most Drupalers and D7 at its very beginning.
It definitely does not help to solve the issue which appeared in Drupal 6.22 in the fist place.

I understand the policy that was referred to in #34, but it seems quite at odd with the actual situation.

I can live with #40, but also agree with #43.

Adding backport tags..

@jvieille: Chances are, if you change Version for this issue to anything than D8, nobody from the core developers team will notice this issue. Or: they will have more trouble noticing it. Beside that, anybody is free to attach patch for D6 and D7, but, D8 must be resolved first according to policy.

Any progress to report, on any version? Thanks.

If I understand correctly, modules may assign default regions that may not exist in some themes. Unless there is agreement between module developers and theme developers on what regions will always be available, there is a potential for this sort of problem. A particular issue is the assumption that the regions "right" and "left" will be defined, when themes such as fusion and its sub themes use sidebars.

I have no idea if this is feasible, but could a module allow site admins to map regions that are being called to regions that are actually defined in a theme, so that an admin could map "right" to "sidebar last"? Alternatively, or in addition, could admins specify through a module what should happen when a specific non existing region is called, such as "ignore, and don't write anything"?

If such a module were possible and easy to write, it might be faster than waiting for a core solution to be back ported, no?

#40: warn_for_invalid_regions_only_for_active_blocks-1172560-40.patch queued for re-testing.

The code has changed significantly and I do not think this applies for D8 (correct me if I'm wrong).

Patch for D7.

Thanks for the re-roll, but this needs to be committed to D8 first. Until then please leave the version parameter at 8.x. If you want to post D7 patches, call them [whatever]-do-not-test.patch.

Also see the note at the bottom of http://drupal.org/node/1319154.

Tagging novice to create a D8 version of this patch as per the backport policy. We should also create an automated test that fails when the bug is present and passes with the fix applied.

Not sure if this is the right place for this, but perhaps one way to deal with blocks assigned to non-existent regions would be to flag the issue in the site status report and to create a new report listing blocks assigned to blocks that don't exist, while ignoring these blocks when displaying the website?

Marking major now that #1373312: Assign system_main block to 'content' region and help block to 'help' region by default (followup) is in D8.
The justification is that we now have core using the 'region' key in hook_block_info(), so with every theme that does not declare a 'help' region, you will see notices on every cache clear, block admin page, etc. I realize this is arguable, because core themes all define this region, but there really is no way to make this go away, so... I won't fight someone downgrading this again, though

Patch for D8

I'm marking this RTBC.
If we at some point decide to show no notice at all, we can always do that later. For now this is an improvement over the status quo, in that it shows them only once (on theme enable or install) and then never again. So let's get this in for now.

Oops.

I wonder whether the proper behavior can be verified in a test. It appears to me that we could add two block definitions to block_test.module, one only pre-defining a non-existing 'region', the other additionally setting 'status' to 1, and assert the expected behavior on the block admin UI?

Actually, I am pretty sure bas_hr is currently working on a test for this. We looked at this issue during core mentoring yesterday.

Yes, as xjm said, I'm working on a test. I'm new in writing tests so it takes a while :)

@sun: I followed example from BlockHiddenRegionTestCase (block.test) and used block provided by the search modul to move it to the invalid region. Here is the test:

/**
 * Tests that an active block assigned to an non-existing region will issue a warning message
 */
class BlockInvalidRegionTestCase extends DrupalWebTestCase {
  public static function getInfo() {
    return array(
      'name' => 'Blocks in invalid region',
      'description' => 'Checks that an active block assigned to an non-existing region will issue a warning message and be disabled.',
      'group' => 'Block',
    );
  }

  function setUp() {
    parent::setUp(array('block', 'block_test', 'search'));
  }

  /**
   * Tests that hidden regions do not inherit blocks when a theme is enabled.
   */
  function testBlockInNotDisabledRegion() {

    // Create administrative user.
    $admin_user = $this->drupalCreateUser(array('administer blocks', 'administer site configuration', 'access administration pages'));
    $this->drupalLogin($admin_user);

    theme_enable(array('stark'));

    // Enable Search block in default theme.
    db_merge('block')
      ->key(array(
        'module' => 'search',
        'delta' => 'form',
        'theme' => variable_get('theme_default', 'stark'),
      ))
      ->fields(array(
        'status' => 1,
        'weight' => -1,
        'region' => 'invalid_region',
        'pages' => '',
        'cache' => -1,
      ))
      ->execute();

    $status = db_query("SELECT status FROM {block} WHERE module = :module AND delta = :delta", array(':module' => 'search', 'delta' => 'form'))->fetchField();
	debug('Status is ' . $status);

    drupal_flush_all_caches();

    $status = db_query("SELECT status FROM {block} WHERE module = :module AND delta = :delta", array(':module' => 'search', 'delta' => 'form'))->fetchField();
	debug('Status is ' . $status);

    $this->drupalGet('');
    $this->assertText(t('The block %info was assigned to the invalid region %region and has been disabled.', array('%info' => t('Search form'), '%region' => 'invalid_region')), t('Block is in the invalid region and was disabled.'));
  }

}

but I'm having trouble catching that drupal_set_message. Debug showed that block was disabled after drupal_flush_all_caches(). Any tips would be helpful. Tnx.

Here is the proposed test case, I reused block from block_test.module

Merged patch and test case

Sorry for being stupid, here it is one more time, merged patch and test case

Actually the test should work without manually disabling the block. _block_rehash() (or similar) should do that for us. Otherwise the message still appears (potentially) at every cache clear, while the point of this issue is to prevent that.

That was a different test case, I've modified it a little bit to be more clear what is being tested.

The test looks good.
I think this is almost ready to go.
The below looks like a lot, but it's really just nitpicks basically.

+++ b/core/modules/block/block.test
@@ -844,3 +844,68 @@ class BlockHiddenRegionTestCase extends DrupalWebTestCase {
+ * Tests that active block assigned to invalid (non-existing) region will issue the warning message.

This is longer than 80 chars, but more importantly it is missing a couple articles (a/an) to be proper English. I would suggest something like:
"Tests that a block assigned to an invalid region triggers a warning."
(I think we can lose the "active", but that's debatable I guess.)

+++ b/core/modules/block/block.test
@@ -844,3 +844,68 @@ class BlockHiddenRegionTestCase extends DrupalWebTestCase {
+      'name' => 'Blocks in invalid region',

Should be "Blocks in invalid regions" (or alternatively, less preferred, though, I think: "Blocks in an invalid region"

+++ b/core/modules/block/block.test
@@ -844,3 +844,68 @@ class BlockHiddenRegionTestCase extends DrupalWebTestCase {
+      'description' => 'Checks that an active block assigned to an non-existing region will issue a warning message and be disabled.',

"an non-existing" should be "a non-existing" (also if we go with "trigger" instaed of "issue" above, we should here, as well)

+++ b/core/modules/block/block.test
@@ -844,3 +844,68 @@ class BlockHiddenRegionTestCase extends DrupalWebTestCase {
+   * Tests that a warning message was issued for an active block in invalid region after cache is cleared.

See above, more or less. :)

+++ b/core/modules/block/block.test
@@ -844,3 +844,68 @@ class BlockHiddenRegionTestCase extends DrupalWebTestCase {
+    // Enable test block in default theme and place it in invalid region.
...
+    // Clearing the cache should disable active block in invalid_region.
...
+    $this->drupalPost('/admin/config/development/performance', array(), 'Clear all caches');
...
+    // Disable test block in default theme and place it in invalid region.
...
+    $this->drupalPost('/admin/config/development/performance', array(), 'Clear all caches');

A/THE invalid region
More importantly: The last comment is followed by a code block which disables the block, even though we know it is already disabled. That looks strange to me.

+++ b/core/modules/block/block.test
@@ -844,3 +844,68 @@ class BlockHiddenRegionTestCase extends DrupalWebTestCase {
+        'theme' => variable_get('theme_default', 'bartik'),
...
+        'theme' => variable_get('theme_default', 'bartik'),

This should be 'stark' not 'bartik'. (Yay!)

+++ b/core/modules/block/block.test
@@ -844,3 +844,68 @@ class BlockHiddenRegionTestCase extends DrupalWebTestCase {
+    $this->drupalPost('/admin/config/development/performance', array(), 'Clear all caches');

Minor, but the leading slash looks weird there IMO.

+++ b/core/modules/block/block.test
@@ -844,3 +844,68 @@ class BlockHiddenRegionTestCase extends DrupalWebTestCase {
+    $this->assertRaw(t('The block %info was assigned to the invalid region %region and has been disabled.', array('%info' => t('Test block html id'), '%region' => 'invalid_region')), t('Enabled block was in the invalid region and has been disabled.'));
...
+    $this->assertNoRaw(t('The block %info was assigned to the invalid region %region and has been disabled.', array('%info' => t('Test block html id'), '%region' => 'invalid_region')), t('Disabled block in the invalid region will not produce the warning.'));

t() should not be used for the assertion message.

+++ b/core/modules/block/block.test
@@ -844,3 +844,68 @@ class BlockHiddenRegionTestCase extends DrupalWebTestCase {
+      ->execute();	

Trailing whitespace.

+++ b/core/modules/block/block.test
@@ -844,3 +844,68 @@ class BlockHiddenRegionTestCase extends DrupalWebTestCase {
+    // Clear the cache to check if warning message is not issued for disabled block.

Also missing some articles.

When you update this can you also upload the test only patch and the merged patch again so we can see the failure before and then pass after.

tstoeckler thanks for the feedback, I'm attaching an updated patch. I hope now its OK :)

btw I saw all the assertion messages in the block.test are passed through the t(), should I open separate task for fixing that?

Here is the test only patch

Re-roll patch to apply cleanly to the latest 8.x as #135464: Add language options to block visibility has been committed.

+++ b/core/modules/block/block.moduleundefined
@@ -468,10 +468,10 @@ function _block_rehash($theme = NULL) {
+      if (!empty($block['region']) && $block['region'] != BLOCK_REGION_NONE && !isset($regions[$block['region']]) && $block['status'] == 1) {

Part of me wishes this was == TRUE instead, but the status field is stored in the DB as a tinyint, 1 or 0. So that's fine.

This looks good to me!

Me too. Committed/pushed to 8.x.

Sorry for stealing novice patches.

Funny; before I clicked on this, I thought, "If that's Tim backporting ANOTHER one of the novice issues..." :)

Wow, great job on that test, bas.hr! Awesome work.

Committed and pushed to 7.x.

Thanks ;)

I think this needs backport to 6.x too.

I'm not sure if it is necessary to check and see if $old_blocks[$module][$delta]['region'] != BLOCK_REGION_NONE or not but I didn't add that to this patch. If anyone thinks it should be just let me know.

The patch from #81 changed the block configuration but it didn't save the changes.

I'm still getting the message after hitting clear caches; it's not actually saving.

@timplunkett and I looked and saw that _block_rehash in D8 saves the block; in D6 this isn't happening.

Marking NW based on #82.

I'm not a big fan of hacking core, but #8 worked for me as a temporary fix. I added something like this on line 285 of modules/block/block.module, just before the line that begins with "if (!empty($old_blocks)":

$regions['my_region'] = 'my_region';
$regions['my_other_region'] = 'my_other_region';

#40: warn_for_invalid_regions_only_for_active_blocks-1172560-40.patch queued for re-testing.

#71: warn_for_invalid_regions_only_for_active_blocks-1172560-70.patch queued for re-testing.

Work is still needed as stated in #83, also, this is not a major issue.

This warning will happen when a theme changed its region naming.
Eg, from sidebar_left to sidebar_first.
What's the advised way to deal smoothly with such a change ?

#8 worked for me, and seems like the easiest soloution for anybody working with custom themes.

Something I found really easy was to add the name of the theme to the message then edit the list of blocks for the theme.

I updated 6.22 to 6.28 and still had this problem. I tried creating a sidebar_left region in my .info file and still had the message showing. Since i'm working with a Zen subtheme, i tried adding the sidebar_left to the main zen.info file and it fixed my problem. So maybe it can help someone working with base themes and subthemes.

Added info about patch in #40 and explanation in #42.

So the default status of a block can only ever be 1 if you want you block in the 'content' region?