Updating the block region/pages settings for a NEW views block during an implementation of hook_update_N

Question

I have a feature module which provides a view which has a block component.

To keep things simple, the module I'm writing a hook_update for is 'mymodule' the feature which implements the view is 'myfeature', the view which contains the block is 'myview' and the block is just block_1 of that view.

The block needs to be visible in the region sidebar_second The block needs to be visible only on pages which match users/* The following is my hook_update simplified:

function mymodule_update_7001(){
 features_install_modules(array('myfeature'));
 drupal_flush_all_caches();
  //Change block settings
  db_update('block')
  ->fields(array(
      'pages' => "users/*",
      'visibility' => 1,
  ))
  ->condition('module', 'views')
  ->condition('delta', 'myview-block_1')
  ->execute();

  db_update('block')
  ->fields(array(
      'region' => 'sidebar_second',
      'status' => 1,
  ))
  ->condition('module', 'views')
  ->condition('delta', 'myview-block_1')
  ->condition('theme', 'mytheme')
  ->execute();
}

Unfortunately it doesn't work, and this is largely because at the point after running drupal_flush_all_caches(); the block doesn't exist in the table yet.

drupal_flush_all_caches() should run block_flush_caches() which should run _block_rehash() against each theme, expected behaviour is that this would cause the writerecord to occur putting the new views block in the 'blocks' table. (if i ran 9 flush all caches followed by a block flush cache and a rehash this would still not work)

I have experimented with varying combinations of these cache flushes to no avail, i have also tried giving 'mymodule' a higher weight.

Bizaarely using the following drush command directly after the update:

drush php-eval "_block_rehash('mytheme');"

causes the block to exist in the database. I have tried using this exact command in the hook_update_n and that did not work.

any advice would be appreciated.

Answer 1

This can be resolved by using db_merge instead of db_update, which effectively updates if it exists else creates the entry.

An alternative line of enquiry would be to look at using one of the new hooks available in the features module. In theory 'hook_post_features_rebuild()' would reactively move the block after the features been rebuilt, and therefore the blocks been created.

http://drupal.org/node/1782492