From hook_save(), I've updated the "pages" attribute of a block, adding a path to the list.

    ->fields(array('pages' => $pages))
    ->condition('delta', $delta)

I've used the database API, (maybe that's the problem?) instead of the block API, because I'm under the impression there is no support in Drupal 7 for this. (hook_block_configure() I think is just for changes to default block configuration.)

The problem I'm having is that the update to the block pages attribute is not reflected, even after clearing caches, until I go to block edit form and click on Save.

There's actually one thing in core's block module function block_admin_configure_submit, and that is to pass the event along: module_invoke($form_state['values']['module'], 'block_save', $form_state['values']['delta'], $form_state['values']);

I'm not sure how go about structure $form_state['values']. Is there a way to do this with the block API?

With regard to Context, we're already using it; we could accomplish the same thing by writing to path to exclude to the context['condition']['path'] attribute, (prefixing the path ~ to indicated "exclude"). This might be a better approach for us, but still would like to see the block code working.

  • In Drupal 7, blocks have "Bases" and "Instances" so to speak. hook_block_info, hook_block_save, hook_block_configure etc only provide the "base" to Drupal. These blocks you create won't get placed anywhere on the theme, until you configure the "instance". So through "Structure > Blocks" (or via different contrib module interfaces) you manage the "Instances" if you know what I mean. There's currently no easy way (a.k.a API) to manage the "instances" through code afaik
    – Beebee
    Jun 29, 2016 at 18:11

2 Answers 2


The solution is to call drupal_form_submit. For example:

module_load_include('inc', 'block', 'block.admin');
$form_state = array();
$form_state['values']['module'] = 'block';
$form_state['values']['op'] = 'Save block';
drupal_form_submit('block_admin_configure', $form_state, 'block', $delta);

You can apply this solution to other forms: from the browser, inspect the submit button, and get the 'op' value and the form's machine name. In source, find the admin.inc that implements the form, and include that, and get the submit functions parameter signature; in this case, the 4th parameter is the form's delta value.


Although there's no really easy way to do this via code, there's a module for this specific need: Context. This module will allow you to create "Contexts" that have a certain condition (e.g. Path = /node/123) and a reaction to that condition (e.g. Place block X in region Y). These contexts are then exportable by Features. Features basically takes the configuration sitting in your database, and exports it into a "module". If you then enable this module anywhere else (e.g. on live server), then those contexts will activate on that server and the configuration gets carried over essentially.

To do this:

  1. Download Context and Features modules
  2. Enable context, features and context_ui modules
  3. Go to Structure -> Contexts and "Add Context"
  4. Give it a name, and choose the conditions, then the reactions and save.
  5. Go to Structure -> Features and "Create Feature" on top right (on Seven)
  6. Give it a name (e.g. myfeaturename), and then "check" the box next to your context from right hand side, then click "Download".
  7. This will give you a tar.gz of your whole module code, you need to extract it to your sites/all/modules folder
  8. Enable your feature either through "drush en myfeaturename", or through Structure -> Features.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.