Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
I temporarily switched to the bluemarine theme, and one of my blocks disappeared and was replaced with "n/a"
Comment | File | Size | Author |
---|---|---|---|
#16 | block_custom_delete.patch | 777 bytes | Zen |
#13 | 42514.patch_0.txt | 745 bytes | dopry |
#12 | 42514.patch.txt | 745 bytes | dopry |
#11 | 42514_0.patch | 616 bytes | Wesley Tanaka |
#10 | 42514.patch | 616 bytes | Wesley Tanaka |
Comments
Comment #1
gregglesThis 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.
Comment #2
Wesley Tanaka CreditAttribution: Wesley Tanaka commentedThanks 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
Comment #3
Wesley Tanaka CreditAttribution: Wesley Tanaka commentedI can still reproduce the problem. I tried with pushbutton, which also displayed "n/a" instead of the block contents.
Comment #4
Wesley Tanaka CreditAttribution: Wesley Tanaka commentedmy hook_block looks like this:
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?
Comment #5
Wesley Tanaka CreditAttribution: Wesley Tanaka commentedNo, it turns out that the hook_block function is only getting called once, with $delta == 0
Comment #6
Wesley Tanaka CreditAttribution: Wesley Tanaka commentedblock_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.
Comment #7
Wesley Tanaka CreditAttribution: Wesley Tanaka commentedThis 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
Comment #8
Wesley Tanaka CreditAttribution: Wesley Tanaka commentedPriority set to minor because there appears to be a workaround, namely visit the blocks configuration page for the affected theme.
Comment #9
Wesley Tanaka CreditAttribution: Wesley Tanaka commentedthere 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.
Comment #10
Wesley Tanaka CreditAttribution: Wesley Tanaka commentedComment #11
Wesley Tanaka CreditAttribution: Wesley Tanaka commentedComment #12
dopry CreditAttribution: dopry commentedI 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.
Comment #13
dopry CreditAttribution: dopry commentedI 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.
Comment #14
drummCommitted to HEAD.
Comment #15
(not verified) CreditAttribution: commentedComment #16
Zen CreditAttribution: Zen commentedBackport for 4.7.
-K
Comment #17
killes@www.drop.org CreditAttribution: killes@www.drop.org commentedapplied
Comment #18
(not verified) CreditAttribution: commented