When you switch themes (for instance, during a major site redesign, or during a major version Drupal upgrade)...
Once you flip the switch and the site's in new theme, you have block references in content that are pointing to blocks that exist in the old theme. Those will still be referenced just fine. The problem comes when you try and save the content that contains the block reference. The first time you do so, no default value is set because _blockreference_potential_references() only returns blocks for the default theme (which is now different). If the content editor is unaware, they'll wipe the block reference as they save the content, resulting in missing content.
Not sure what the best way to handle this would be. Just a report from the field.
| Comment | File | Size | Author |
|---|---|---|---|
| #10 | block-from-other-themes-1593646-2.patch | 0 bytes | danielb |
| #8 | block-from-other-themes-1593646-1.patch | 15.38 KB | danielb |
| #4 | block-from-other-themes-1593646-0.patch | 6.01 KB | danielb |
Comments
Comment #1
danielb commentedI will add a new setting like this
however there are a lot of things to think about, the field info hook, the implementation of the settings, and a couple other things that rely on the default theme.
It's just that i've run out of time atm.
Comment #2
iamEAP commentedThat could be good.
I wonder if it would be simpler (or at least conceptually cleaner) to try and implement a sort of self-repair functionality where...
Comment #3
danielb commentedI guess so, but it's high time we allowed referencing blocks from other themes too.
Comment #4
danielb commentedThis is what I have so far, consider it a work in progress. I haven't done anything about your self-repair suggestion yet.
Comment #5
danielb commentedGees, this self repair thing isn't going to be easy.
Comment #6
danielb commentedI don't think there is a complete way to do it. hook_options_list doesn't provide enough information to determine which bid is the current one. We get the node and the field information, but there isn't enough to determine which language and delta we're fetching data for.
In other words when generating the list of options, there is no knowledge of the current value.
Comment #7
danielb commentedI suppose I could get all the values for the node/field, that could work.
Comment #8
danielb commentedHere's a new patch where I've attempted the self-repair thing. Spoiler: It doesn't work and you can't save nodes at all.
I'm buggered now, will sort this out some other time.
Comment #9
danielb commentedDon't think the errors i'm getting are caused by blockreference at all :/
Comment #10
danielb commentedOK I've fixed all the errors and committed working code. I don't know if it does everything needed, but it will be in the next dev snapshot. Check it out and see if it satisfies your requirements.
Comment #11
danielb commentedhttp://drupalcode.org/project/blockreference.git/commitdiff/d16b8b9a83d0...