Using exported blocks in installation profiles

I came across this situation as well. The block settings are not being written to the database correctly from my custom theme. The solution above is fine if your theme is bartik, but if not the blocks are all disabled. I tried doing a query to get the default theme, but that apparently is not working either. As well, the solution about fe_block_settings_features_enable_feature() was mentioned here: #1623480: missing hook_features_rebuild() implementations..
Since I'm working with an install profile as well, I left the function as is, and also tried commenting out. Either way, the block settings are not being applied correctly.

I even tried calling fe_block_settings_features_revert('bir_features') in a install_task and it doesn't work. For some reason, it's not seeing my custom theme as being the one set even though the profile install sets it right off the bat.

function bir_profile_install() {
  // Enable some bir_profile blocks.
  $default_theme = 'bir_theme';
  $admin_theme = 'seven';
  // disable all themes
  db_update('system')
    ->fields(array('status' => 0))
    ->condition('type', 'theme')
    ->execute();
  // enable $default_theme
  db_update('system')
    ->fields(array('status' => 1))
    ->condition('type', 'theme')
    ->condition('name', $default_theme)
    ->execute();
  // enable $admin_theme
  db_update('system')
    ->fields(array('status' => 1))
    ->condition('type', 'theme')
    ->condition('name', $admin_theme)
    ->execute();
  variable_set('admin_theme', $admin_theme);

.......

Even changing the

$theme_default = variable_get('theme_default', 'bartik');

to the name of my theme didn't work. I looked at the exported data for the blocks, and everything there reflects my set up correctly. Not sure why it's not working. This is using the latest dev version.

Am I going about this all wrong?

Glad I found this issue. My problem is that the feature remains overriden which I am assuming is because the changes are not being written in the database.

i attached screenshots on my closed issue: #1903026: Blocks - Features Export remains overidden

I found the reason my blocks were not written was due to my custom module not installing all the necessary fields during the install process. It was a coding error on my part. Now that the fields are there, the correct theme is also used without any alteration in fe_block code.

However, even though all the blocks are entered in the db, they are not positioned correctly on the blockui page. Reverting the blocks after the install profile is complete fixes it. So it may just be the order in which things are happening. I'm importing other features at the same time: some static content, search api and facets, etc. Running the following code in the hook_install_tasks() of the profile fixes it:

features_revert(array('bir_features' => array('fe_block_settings')));

@kclarkson - I've come to learn the status in features is not always accurate. There are a few issues reported about it. Even after all my blocks are written to the database, and positioned correctly, it still shows Overriden though a side by side comparison shows them being the same. I've seen this with other features I've exported too.

Ever see the movie Apollo 13? I'm approaching Features from that standpoint: "Let's look at this thing from a... um, from a standpoint of status. What do we got on the spacecraft that's good?" Then, working out the rest until modules catch up. Have to remember: a complete solution for exporting all these configurations and content for a Drupal site are still being worked out with many modules.

@rbruhn - hahah that is a pretty good explanation of features. I have been pretty lucky with my features, as I am using the Local, push to Pantheon workflow. All of my features have been able to remain in default. But I then added a new featured title "custom blocks". This feature is fine on my local machine but when I push to the Pantheon Server and try to "revert" the feature it remains overridden.

@steverweber - Darn it. I was hoping my issue was related to yours. There seems to be a few different issues regarding blocks export and them being overridden.

Sorry I didn't mean to highjack the issue. My issue is: #1903026: Blocks - Features Export remains overidden

@steverweber

any chance you could rename the patch :)

Well, turns out running

features_revert(array('bir_features' => array('fe_block_settings')));

in the hook_install_tasks() for the profile does not fix the settings. Strange, since running it directly in script after install works. Also works reverting from within Features UI. I know the function in the hook_install_tasks() is running because I wrote some text to file from within the function. So not sure what is happening. Has nothing to do with fe_blocks I'm sure, but thought I'd post a follow up.

Setting correct issue status. I'd like to look into this, can someone provide an install profile that exposes this bug?

@pfrenssen - I can't really supply a profile yet because the module I'm working on is still private. Eventually, they plan on putting it public, but not yet. Also, I think the bug steverweber is speaking about is not the same as my issue. Calling the function in a script using Drush after the install, as well as simply reverting from the UI, fixes everything on my end. I just can't get the features_revert() to work during the install process. I'm still trying to track down why.

I should also mention, mine is working without all the code changes steverweber made. Once I figured out my fields were not being created, everything worked with current code.

@rbruhn, in your case it could be possible you are being plagued by a static cache that is not being cleared. I have been doing some work on this in #1265168: Rebuild the file list properly when a feature is enabled or disabled, maybe you could try the patch in comment #36 of that issue and see if it solves the problem for you?

@steverweber, thanks for all the work here! I just took a look at your patch but I'm afraid you're not on the right approach.

-files[] = tests/fe_block.test
\ No newline at end of file
+files[] = tests/fe_block.test

Whitespace and coding standards issues are best taken on in a separate issue, to make the patches easier to read. But thanks, have committed it at e15c9fe a few days ago.

@@ -402,6 +402,10 @@ function _fe_block_get_active_themes() {
       $theme_names[] = $machine_name;
     }
   }
+  if (defined('MAINTENANCE_MODE') && empty($theme_names) ) {
+    $theme_names[] = variable_get('theme_default', 'bartik');
+    $theme_names[] = variable_get('admin_theme', 'seven');
+  }
   sort($theme_names);
   return $theme_names;

Hard coding two themes does not seem like the right solution to me. This will not work with all install profiles.

@@ -431,6 +435,15 @@ function fe_block_settings_features_revert($module_name = NULL) {
     // Remove the additional settings from the block array, to process them
     // later. We explicitely set NULL, if no setting was given in the defaults.
     $block_themes = $block['themes'];
+    foreach($block_themes as $key => $value ) {
+      if(!in_array($key,$active_themes) && !isset($block_themes[$theme_default])) {      ¶
+        // if the block has an unknown theme and the block has no theme for the default.
+        $block_themes[$theme_default] = $block_themes[$key];
+        $block_themes[$theme_default]['theme'] = $theme_default;
+        unset($block_themes[$key]);
+      }
+    }

This replaces the default theme with any exported theme if the default theme is missing. This won't work when you have multiple themes exported since block settings are not compatible across themes. For example regions can be different. Also it would be nice if you could follow the coding standards and remove trailing whitespace ;)

@@ -461,7 +474,17 @@ function fe_block_settings_features_revert($module_name = NULL) {
       // Write block settings.
       $write = array_merge($block, $block_themes[$key]);
-      drupal_write_record('block', $write, array('module', 'delta', 'theme'));
+      $result = db_select('block', 'b')->fields('b')
+        ->condition('module', $write['module'],'=')
+        ->condition('delta', $write['delta'],'=')
+        ->condition('theme', $write['theme'],'=')
+        ->execute()->fetchAssoc();
+      if ($result) {
+        drupal_write_record('block', $write, array('module', 'delta', 'theme'));
+      } else {
+      echo ('drupal_write_record');
+        drupal_write_record('block', $write);
+      }

Is this a workaround for an integrity constraint violation? The function _block_rehash() makes sure these tables are up to date, therefor we should never have the need to create any new entries in the block table, only update existing ones.

+### PATCH NOTE: dont use this hook because it prevents fe_block_boxes_features_rebuild during profile install
 /**
  * Implements hook_features_enable_feature().
- */
 function fe_block_boxes_features_enable_feature($module) {
   fe_block_boxes_features_revert($module);
 }
+ */

Removing this hook will break Features Extra. Without this the blocks would not be reverted when the feature is enabled. It's probably because of this change that the tests fail.

Can you perhaps create a minimal install profile that exposes this bug so I can take a look?

I am more than willing to help out with testing patches in this issue! I am running into the same problem of not being able to add an exported block to the same feature as the view that creates the block. I would use a workaround of reverting the feature (from #15), if it would work. I am not having any luck trying to revert it programmatically, as it only seems to actually revert from 'drush features-revert'. None of these are working for me:

function myfeature_update_7001(&$sandbox) {
  module_load_include('inc', 'features', 'features.export');
  fe_block_settings_features_revert('myfeature');
}

function myfeature_update_7001(&$sandbox) {
  features_revert(array('myfeature' => array('views_view')));
  features_revert(array('myfeature' => array('fe_block_settings')));
}

@steverweber: I'm trying this on an already installed feature, FWIW. You can see I'm trying to run in my update hook, not during initial install.

Still no luck. In this case, I have a view inside my feature that creates a block display. Enabling the feature does not stand up the block settings, and it appears overridden. It only gets set correctly by either adding the block configuration to another feature that is enabled after the one containing the view, or by reverting the original feature in code or from drush, after the feature has been enabled.

Well, I think the issue is basically the same: fe_block_settings are not stood up when enabling a feature, and you need to revert the feature. I will keep an eye out here and help test patches and if not solved, will open a new issue.

Tested the patch in #30 and it works in a custom profile: http://drupal.org/sandbox/theohawse/1928548

Still testing more thoroughly.

I have also tested this patch #30 with a custom profile and features, works a treat and I now get blocks correctly placed in regions for the custom theme

to be specific, most of the settings worked previously, it was just the region placement I had issues with [updated issue title to reflect this]

Setting this back to "needs work" since the remarks from #21 are not yet addressed.

For everyone itching to use this, please read #21 and review the patch before deciding to use this in a production environment. The patch does not contain an actual solution, it is a workaround that writes to the block database directly before any themes have been initialized, making some assumptions about which themes might be installed on the system. This is NOT the right way to approach this problem and I would advise caution, please make sure you fully understand the patch and its implications before applying it.

I just had a look at how install profiles work. The source of the problem can be found in install_profile_modules():

  // Although the profile module is marked as required, it needs to go after
  // every dependency, including non-required ones. So clear its required
  // flag for now to allow it to install late.
  $files[$install_state['parameters']['profile']]->info['required'] = FALSE;

This makes sure that the profile will always be installed at the very end, after all other modules. If a feature that contains blocks is listed as a dependency in the profile, it will be installed before the profile is installed. Now, it is the profile's responsibility to enable the themes, so when the feature reverts, the themes are not yet enabled. This is a problem, since the blocks depend on the themes for their positioning. If the themes do not exist the blocks can't be reverted.

You can see how core deals with this by taking a look at the standard install profile: in standard_install() the themes that will be used are decided, and then all blocks are placed:

  // Enable some standard blocks.
  $default_theme = variable_get('theme_default', 'bartik');
  $admin_theme = 'seven';
  $blocks = array(
    ...

A good solution would probably be to use the same approach as is done in the core profiles: enable the blocks in the install profile. So basically enabling the block feature after enabling the themes. This leaves the problem of list_themes() not returning the theme list during install. This can be solved with some drupal_static() juggling.

So at the end of your hook_install() in your profile.install file you would have something like this:

/**
 * Implements hook_install().
 *
 * Perform actions to set up the site for this profile.
 *
 * @see system_install()
 */
function MYPROFILE_install() {
  // First set up everything needed.
  ...

  // Revert our feature containing blocks. Reverting blocks depends on
  // list_themes() which refuses to return a list of themes during install.
  // We can circumvent this by placing our themes in its static cache.
  $list = &drupal_static('list_themes', array());

  $themes = _system_rebuild_theme_data();
  $list = array(
    'bartik' => $themes['bartik'],
    'seven' => $themes['seven'],
  );

  module_enable(array('my_block_feature'));

  // Restore the static cache of list_themes();
  drupal_static_reset('list_themes');
}

I have not tested this, can somebody give it a try? Make sure the feature is not added as a dependency in the profile.info file.

I just stopped theorizing and actually made an install profile and tested it :) I have found a nice solution. Apply the patch and add something like the following to the end of your install profile's hook_install():

/**
 * Implements hook_install().
 */
function MYPROFILE_install() {
  // ... set up content types, user profiles etc ...
  ...

  // Enable themes.
  theme_enable(array('garland'));

  // Enable features that contain exported blocks. These can't be placed as
  // dependencies in the .info file as they depend on the themes enabled above.
  module_enable(array('my_block_feature'));
}

I tested this by taking the minimal install profile, adding CTools, Features, Features Extra and a test feature to it, and adding the above lines to minimal_install(). My test feature was using Garland.

Sure you can do whatever it takes to create your blocks in your profile hook_install(), the core profiles also just write their settings to the database.

It would maybe be better though to not rely on the latest dev version of a theme in your profile if it often changes its region list. If the regions change this will cause problems for your unsuspecting users. A better method is to "pin" the latest git commit revision in your makefile, and then update this revision number regularly when you see that new commits have been made in the theme. This allows you to follow the latest dev version of the theme closely, and keep using FE Block without having to create custom workarounds. If the regions change, just check the changes, update the feature and put the new commit revision number in the makefile.

There is an example of this in the documentation: Full example drupal-org.make file, look for "draggableviews".

I'd love to get some more feedback on the patch and approach described in #37 before I commit it, so if someone would like to try it out, please go ahead :)

If this gets in, I'll document the process here so people that need it can easily find this information.

I have committed the patch in #37: commit 52a766d.

To help other people with the same problem, I'll turn this issue in a support ticket with a more descriptive title, and document what needs to be done in the first post.