I temporarily switched to the bluemarine theme, and one of my blocks disappeared and was replaced with "n/a"

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

greggles’s picture

This is definitely going to require more information:

1. Was this a standard block? If so, which one, and was there any configuration that you had?
2. Was this a custom block? If so, what was the name, content, and all the settings?
3. What was your original theme where the block worked normally?
4. Where was the block replaced with "n/a"? Was that in the place on the page where you expected to see the block or was it replaced with "n/a" on the admin/block listing?
5. Were you able to retrieve the block by switching the theme back?

Thanks.

Wesley Tanaka’s picture

Thanks for reminding me about this. I was going to do more investigation, but got caught up in other things. From memory:

1. Not a standard block, but a custom block defined (no settings) in a module of mine. Another custom block defined in the same moduie file had no problems.
3. The original theme is also a custom phptemplate theme.
4. The block didn't show up on the page. Instead, the string "n/a" appeared. You can see where that string was generated by searching for "n/a" in common.inc
5. Yes, switching the theme back gave me the block back. Seems like it was just a display problem.

I'm going to see if the problem still exists in my more up to date cvs copy

Wesley Tanaka’s picture

I can still reproduce the problem. I tried with pushbutton, which also displayed "n/a" instead of the block contents.

Wesley Tanaka’s picture

my hook_block looks like this:

function modulename_block($op = 'list', $delta = 0)
{
   if ($op == 'list')
   {
      $blocks[0]['info'] = t('Browse');
      $blocks[1]['info'] = t('Search');
      return $blocks;
   }
   else if ($op == 'view')
   {
      $block = array();
      switch ($delta)
      {
         case 0:
            include_once 'somefile';
            $block = get_browse_block();
            break;
         case 1:
            include_once 'someotherfile';
            $block = get_search_block();
            break;
      }
      return $block;
   }
}

The browse block shows up just fine.

The search block function isn't getting called. I tried adding a die() in there and it didn't get called. Is it possible that $delta is getting set incorrectly?

Wesley Tanaka’s picture

No, it turns out that the hook_block function is only getting called once, with $delta == 0

Wesley Tanaka’s picture

block_list() isn't iterating over my module twice like it presumably should be.

I looked at my block configuration (whoa, it's by theme now), and the block is enabled in my custom theme, but not in bluemarine.

Once I visited the block configuration page for bluemarine, the n/a disappeared, from that page view, and apparently all future page views.

Wesley Tanaka’s picture

Priority: Normal » Minor

This appears to be a confluence of various things, and appears to have nothing to do with my custom module. I'm guessing the repro case might go something like this:

1. create a custom block (block module block)
2. set it as active on all themes
3. switch off all themes except one
4. delete the custom block
5. switch back to another theme

Wesley Tanaka’s picture

Priority set to minor because there appears to be a workaround, namely visit the blocks configuration page for the affected theme.

Wesley Tanaka’s picture

there may be a shorter repro case, but here's one:

start with 1 theme enabled
0. delete from {blocks} where module='block';
1. create a block using admin/block/add
2. enable it using admin/block
3. go to admin/themes. click "default" on one of the other themes (which will also enable it) and save
4. go back to admin/block and enable the block for the new current theme
5. go back to admin/themes. uncheck the "Enabled" on the theme that you picked in #3. Pick default for your original theme. Save.
6. back to admin/block. Delete the block you created in #1
7. back to admin/themes. repeat step #3.

Expected behavior: block has been deleted from the theme picked in step #3 and #7

Actual behavior: {blocks} table still has an entry for the block, and n/a shows up where the block should have been.

Suggested fix: delete all corresponding rows from {blocks} table when deleting a custom block, instead of only the row corresponding to the current theme.

Wesley Tanaka’s picture

Status: Active » Needs review
FileSize
616 bytes
Wesley Tanaka’s picture

FileSize
616 bytes
dopry’s picture

FileSize
745 bytes

I cannot get the n/a, probably because message_na was deprecated. However I can see hanging database entries as wtanaka points out. There is another bug with the ui which makes this specific one a little difficult to troubleshoot. (Enabling blocks only affects the current default theme, changes made to block layouts on other themes will not have an effect, so you have to switch you default theme to test.)

I re-rolled's wtanaka's patch. If we're deleting the custom box itself we should remove all references to it. Maybe a sterner warning on the confirm box is appropriate, so users will know that this affects all themes.

I'm setting it rtbc.

dopry’s picture

Status: Needs review » Reviewed & tested by the community
FileSize
745 bytes

I cannot get the n/a, probably because message_na was deprecated. However I can see hanging database entries as wtanaka points out. There is another bug with the ui which makes this specific one a little difficult to troubleshoot. (Enabling blocks only affects the current default theme, changes made to block layouts on other themes will not have an effect, so you have to switch you default theme to test.)

I re-rolled's wtanaka's patch. If we're deleting the custom box itself we should remove all references to it. Maybe a sterner warning on the confirm box is appropriate, so users will know that this affects all themes.

I'm setting it rtbc.

drumm’s picture

Status: Reviewed & tested by the community » Fixed

Committed to HEAD.

Anonymous’s picture

Status: Fixed » Closed (fixed)
Zen’s picture

Version: x.y.z » 4.7.4
Status: Closed (fixed) » Reviewed & tested by the community
FileSize
777 bytes

Backport for 4.7.

-K

killes@www.drop.org’s picture

Status: Reviewed & tested by the community » Fixed

applied

Anonymous’s picture

Status: Fixed » Closed (fixed)