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.

Comments

danielb’s picture

I will add a new setting like this

<?php



  $themes = list_themes();
  $current_theme = $themes[variable_get('theme_default', 'bartik')]->info['name'];
  $admin_theme = $themes[variable_get('admin_theme', 'seven')]->info['name'];
  $form['referenceable_theme'] = array(
    '#type'          => 'radios',
    '#title'         => t('Themes that can provide blocks for selection.'),
    '#default_value' => isset($settings['referenceable_theme'])
      ? $settings['referenceable_theme']
      : 'not_admin',
    '#options'       => array(
       'default' => t('Default theme (%theme) only.', array('%theme' => $current_theme)),
       'all'  => t('All themes.'),
       'not_admin'  => t('All themes except admin theme (%theme).', array('%theme' => $admin_theme)),
    ),
    '#description' => t('If switching themes on your site, <em>Default theme only</em> will cause problems when editing existing Block reference data.'),
  );


?>

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.

iamEAP’s picture

That 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...

  • On an entity edit form, if there's already a BID set...
  • But the BID doesn't match anything returned by _blockreference_potential_references()
  • Try and find a block whose module and delta are the same as those of the BID and contained with the BIDs returned by potential references, but with a different theme.
  • If one is found, set that as the default, otherwise, do nothing.
danielb’s picture

I guess so, but it's high time we allowed referencing blocks from other themes too.

danielb’s picture

StatusFileSize
new6.01 KB

This is what I have so far, consider it a work in progress. I haven't done anything about your self-repair suggestion yet.

danielb’s picture

Gees, this self repair thing isn't going to be easy.

danielb’s picture

I 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.

danielb’s picture

I suppose I could get all the values for the node/field, that could work.

danielb’s picture

StatusFileSize
new15.38 KB

Here'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.

danielb’s picture

Don't think the errors i'm getting are caused by blockreference at all :/

danielb’s picture

Status: Active » Needs review
StatusFileSize
new0 bytes

OK 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.

danielb’s picture

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.