fe_block lets you choose which blocks to export, but doesn't let you choose which themes you want it to keep track of. In a development situation the functionality developers will probably have different themes enabled than theme developers will. when this happens features using fe_block will show as overridden and not revert properly. Thus it would be nice if we could choose which themes we care about for the fe_block exports.

The patch below solves this problem, but is most likely not the *ideal* approach. it provides an administrative screen (accessible through admin->settings->features extra - blocks) that lets you choose which themes to care about. if none are selected, then all are used.

I'd like to get a discussion going about the best way to handle this problem and see this patch revised to be a completely features related fix.

for now, this is a start!

CommentFileSizeAuthor
fe_block-track_specific_themes.patch2.57 KBnetw3rker
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

bzbzh’s picture

bzbzh CreditAttribution: bzbzh commented

subscribe.

pearcec’s picture

pearcec CreditAttribution: pearcec commented

This patch didn't work for me. I original just added seven to have devel menu on by default. But my xforty_devel.features.fe_block_settings.inc was essentially empty. Then I added garland and got the garland theme but not the seven theme. I am wondering if it makes more sense to push this feature to the uuid_features as suggested here.

#921872

Otherwise, I think we should present the user with all the blocks that are enabled with a particular theme versus calling _block_rehash(); So it would be

[theme-name-block-name] as the machine name or something.

Thoughts?

For now, I am going to try and just edit the theme name in the code.

pearcec’s picture

pearcec CreditAttribution: pearcec commented
Status: Active » Needs review

I spend a lot of time. What I found is that what ever themes are enabled it will export it, if block is enabled. So I don't think this is necessary.

There is a larger issue that it doesn't actually work to enabled some of the configurations. I am trying to figure out why.

netw3rker’s picture

netw3rker CreditAttribution: netw3rker commented

@pearcec

That sounds pretty good actually. The really important aspect of this will be to provide the blocks that can be exported along with a choice of theme settings that can be chosen. The options when choosing which items in features to export should look something like this:

block: hello_world (garland)
block: hello_world (bluemarine)
block: hello_world (seven)

That would allow users to select hello_world's block settings for garland and bluemarine, but exclude the settings for seven.

pearcec’s picture

pearcec CreditAttribution: pearcec commented

We rolled something similar into this patch

http://drupal.org/node/727266#comment-3712048

I am still convinced that fe_block doesn't work. It is missing _revert and _rebuild functions. I don't see how people are using it. Sure the boxes part works but not blocks provided by a module.

netw3rker’s picture

netw3rker CreditAttribution: netw3rker commented

fe block has a revert function @ line 158:

function fe_block_settings_features_revert($module_name = NULL) {
  global $custom_theme, $theme_key;
  $component = 'fe_block_settings';
  $defaults = features_get_default($component, $module_name);

  // Revert.
  foreach ($defaults as $_theme_key => $theme) {
    $custom_theme = $theme_key = $_theme_key;
    _block_rehash();

    foreach ($theme as $block) {
      // Convert machine name back to bid.
      if ($block['module'] == 'block') {
        $block['delta'] = _fe_block_get_bid($block['machine_name']);
      }

      drupal_write_record('blocks', $block, array('module', 'delta', 'theme'));
    }
  }

  return TRUE;
}

I'm pretty sure it doesn't need _rebuild because its only using the _revert to bring things back.

wizonesolutions’s picture

wizonesolutions
he/him
Primary language English
Location Norway
CreditAttribution: wizonesolutions commented
Status: Needs review » Closed (won't fix)

Someone reopen this if help or a feature is still needed. I can't tell from what's gone on so far if there's actually an issue here :)

netw3rker’s picture

netw3rker CreditAttribution: netw3rker commented
Status: Closed (won't fix) » Active

@wizonesolutions,

The fundamental issue here is that if you export block settings, you cant chose which themes you are exporting the settings for. there needs to be a way to specify in the feature that this one only has settings for themes 1 & 2. otherwise when a feature with block settings is enabled on an environment with additional themes enabled, it will be marked as permanently overridden.

The initial patch provides an administrative area to specify which themes you want to track, but thats not really the right approach, just an idea for one.

-Chris

wizonesolutions’s picture

wizonesolutions
he/him
Primary language English
Location Norway
CreditAttribution: wizonesolutions commented
Assigned: netw3rker » Unassigned

I see. The issue is that block settings are exported for all enabled themes, and those only, without any control.

I don't see an issue with that though because why would anyone be exporting settings for themes that are disabled? They'd have to be enabled to have those settings in the first place.

To that end, though, perhaps only the configuration for the enabled themes on the destination should be verified?

We should require that the themes themselves exist on both sites; if they are in different states of enabling, then Features Extra should show Overridden because I don't think theme_exists() detects disabled themes - or does it? If it does, then one approach could be to revert the settings regardless of the state of the theme.

Patches welcome to get per-theme settings, at least, into the Features form instead of a separate interface.

brad.bulger’s picture

brad.bulger CreditAttribution: brad.bulger commented

why would anyone be exporting settings for themes that are disabled?

just a comment - i've seen two different sites in the last month that didn't have any themes enabled. (i was just consulting, i didn't set them up.) this seems to work, in that you can set default and admin themes without enabling them. the block settings include info that's global to all themes. if you're only using Context, that's the only info that matters, so you don't need the theme-specific values.

i'm not saying i think this is a good idea, only that it does happen. i can see the value of being able to only export settings for particular themes, if there could also be some kind of wildcard setting to mean "export everything".

Johnny vd Laar’s picture

Johnny vd Laar CreditAttribution: Johnny vd Laar commented

The situation that I'm in is (drupal 7.x) that I have blocks for the dashboard enabled in a feature. I'm installing this on multiple websites all of course with different front end themes. But they will always show as overridden. So this patch would be great for my situation.

derhasi’s picture

derhasi CreditAttribution: derhasi commented

Some time ago I wrote the "FE Block2" sandbox: http://drupal.org/sandbox/derhasi/1321200 . That's a rewrite for the fe_block export, with some more features and a more usable array structure. (e.g. in git diffs).

wizonesolutions’s picture

wizonesolutions
he/him
Primary language English
Location Norway
CreditAttribution: wizonesolutions commented

derhashi: Any idea how it compares to pfrenssen's latest stuff? #1741370: Request for co-maintainership

Yours seems to be for 6.x-1.x and his is for 7.x-1.x.

derhasi’s picture

derhasi CreditAttribution: derhasi commented

@wizonesolutions, as it is a long time, since I last had a look in the code, It's hard to compare it with the steps I did. On my first overfly at least the export seems to get similar to mine.

I can show you, how the hook_default_fe_block2_settings() export looks in fe_block2.

//...
$export['menu-menu-application'] = array(
    'module' => 'menu',
    'delta' => 'menu-application',
    'custom' => '0',
    'visibility' => '0',
    'pages' => '',
    'title' => '',
    'cache' => '-1',
    'themes' => array(
      'mycustom' => array(
        'theme' => 'mycustom',
        'status' => 0,
        'weight' => '-49',
        'region' => '',
      ),
      'rubik' => array(
        'theme' => 'rubik',
        'status' => 0,
        'weight' => '-54',
        'region' => '',
      ),
    ),
    'roles' => array(
      'admin' => '4',
      'authenticated user' => '2',
    ),
  );
//...
pfrenssen’s picture

pfrenssen
Location Sofia
CreditAttribution: pfrenssen commented

@derhasi, I had not yet seen the work you did, the issue where you announced your sandbox has unfortunately been closed as a duplicate. I have quickly reviewed your work and your approach is indeed similar to mine. The cool thing is that you have focused on exporting of user roles and menu blocks while I have done node types, so there is little overlap in the work done.

It looks like I will have to do some more work on Features Extra this week, if I have some time left I will try to port your changes to my sandbox.

pfrenssen’s picture

pfrenssen
Location Sofia
CreditAttribution: pfrenssen at Randstad Digital for European Commission and European Union Institutions, Agencies and Bodies commented
Issue summary: View changes
Status: Active » Closed (outdated)

Drupal 6 is no longer supported. Closing.