* What are the steps required to reproduce the bug?
1. place navigation block on left side bar in your current default theme (probably garland)
2. create a theme info file that contains the "regions[left]" directive
3. enable and select the theme you created.
4. look at the navigation block in the left region of the theme
5. remove the "regions[left]" directive from the info file and reload the page
6. Notice the left region no longer shows up (as expected)
7. Go to the blocks page
* What behavior were you expecting?
I was expecting to go to the blocks page and find the navigation block simply disabled.
* What happened instead?
The navigation block was not in the list of blocks available. Not after a "clear cache", running update.php, or running cron.
Please include as much information as you can:
- Windows Vista
- Apache/2.0.61 (Unix) PHP/4.4.7 mod_ssl/2.0.61 OpenSSL/0.9.7e mod_fastcgi/2.4.2 DAV/2 SVN/1.4.2
- admin/build/block
I classified this as critical because using phptemplate_regions() in D5 would result in the expected behavior. The only way to get those missing regions back is to recreate the left region in the info file, clear the cache, and the blocks that were in that region will show up, then move them accordingly. I figured the old behavior would be preferable to theme developers.
It may not be critical because you can always get the block back using the above method, but I'm not experienced enough to make that decision.
| Comment | File | Size | Author |
|---|---|---|---|
| #18 | block_region_check_e1.patch | 1.94 KB | theborg |
| #18 | block_region_check_e2.patch | 1.94 KB | theborg |
| #14 | block_region_check.patch | 1.72 KB | chx |
| #13 | block_region_check_d.patch | 1.94 KB | theborg |
| #10 | block_region_check_c.patch | 1.95 KB | catch |
Comments
Comment #1
vm commentedthis should probably be tested on a -dev tarball of D6 to see if it can be reproduced. http://drupal.org/node/97368
Comment #2
theborg commentedSee http://drupal.org/node/201165, I have to check if the patch still applies.
Comment #3
jswaby commentedI like the patch. It is a bit slow compared to the old way. The old way simply had the blocks disabled, but it happened right away. This new way does require the cache to be cleared twice, and there are error messages (which I also like).
I think it's good enough unless someone else has a more elegant way of handling this. Maybe there isn't a more elegant way because of the new region definition system.
More experienced eyes should check this to see if it's RTBC.
Comment #4
dvessel commentedThe structure isn't right.
$old_blocks[$module][$delta]['region']will always have a value so that first condition will only check on the array_key_exists().How about moving
$old_blocks[$module][$delta]['status']in its place and remove the ternary conditional.Comment #5
theborg commented@dvessel:
$old_blocks[$module][$delta]['region']on my tests this is empty where region is<none>Comment #6
catchComment #7
dvessel commentedYour right. I really shouldn't be reviewing anything late a night.
I like the new behavior. In 5, the disabled regions would be pushed into the default region with system_default_region() but the way it's cached doesn't allow that in 6. This is reasonable so marking it ready.
Comment #8
Rowanw commentedWorks for me.
Comment #9
gábor hojtsy- Erm, why is this an 'error' level message to the user? Does this bug cover the case when a region disappears and the user visits the blocks admin page?
- The English in the code comments could use some polish: "if region name not exists" does not sounds right to me.
Comment #10
catchChanged the dsm() to 'warning', and tidied up comment English, don't credit me if this gets committed. Not tested this yet.
Comment #11
theborg commented@catch: Thanks for your corrections.
@Gábor: This bug covers the case you mentioned on #9: 'blocks admin page'.
There was also another issue opened by hampshire: http://drupal.org/node/201165
Comment #12
chx commented$old_blocks[$module][$delta]['region']on my tests this is empty <= empty or not set? Also, why array_key_exists instead of isset can the value of$regions[$old_blocks[$module][$delta]['region']]be NULL? that'd be the only reason to use the very slow array_key_exists instead of isset.Comment #13
theborg commented@chx: $old_blocks[$module][$delta]['region'] on my tests this is empty,
issetreturns TRUE.I've changed the slow array_keys_exists for an isset on the regions list.
Comment #14
chx commentedWell if it is set then why do we need to check for emptiness? Surely
$regions['']is not set. I have asked that so that we are not putting a notice in here.Comment #15
theborg commentedIt's not working for me because every already disabled module it has a
' 'value for its region name.Comment #16
chx commentedOK then #13 is the current to be reviewed.
Comment #17
keith.smith commentedBTW, in this message in #13, "its" should be "it is" (or at the very least, "it's").
Or, how about:
Comment #18
theborg commentedThanks Keith.
I'm attaching two files with two versions of #13 based on #17.
Comment #19
catchOK I'd go for the wording in block_region_check_e1.patch
Tested this with a contrib theme, works fine, so marking RTBC.
Comment #20
gábor hojtsyCommitted that one, thanks.
Comment #21
jswaby commentedAwesome!
Comment #22
Anonymous (not verified) commentedAutomatically closed -- issue fixed for two weeks with no activity.