Illegal string offset 'region' and 'status' when saving block admin

I have the same issue on Drupal 6.28 !
I'll test your fix, just now ...

Why does the issue exists when there is a patch ?

The problem re-apears on Drupal 6.29
I've updated a test site from D6.28 to D6.29 two days ago. So replaced the block module.
I remember this issue, went to bloks list and moved 1. Surprice...
warning: Illegal string offset 'region' in /home/user/lampstack-5.4.11-0/apache2/htdocs/herramientasd6/modules/block/block.admin.inc on line 101.
warning: Illegal string offset 'status' in /home/user/lampstack-5.4.11-0/apache2/htdocs/herramientasd6/modules/block/block.admin.inc on line 101.
warning: Illegal string offset 'status' in /home/user/lampstack-5.4.11-0/apache2/htdocs/herramientasd6/modules/block/block.admin.inc on line 102. at least 30 warning rows. I'll retest the patch idea over 6.29

As I was almost sure the propoused patch is misdirected. I perform a test to read the $form_state['values'] content because NOT ALL of it's elements are block definitions. It means there are several cases where $block[$key] is undefined so raises errors.

// HERE IS THE $form_state['values'] content
<?php
$form_state['values'] = array(
  "user_0" => array(
    "module" => "user",
    "delta" => "0",
    "theme" => "garland",
    "weight" => "0",
    "region" => "left",
  ),
  "user_1" => array(
    "module" => "user",
    "delta" => "1",
    "theme" => "garland",
    "weight" => "0",
    "region" => "left",
  ),
  "system_0" => array(
    "module" => "system",
    "delta" => "0",
    "theme" => "garland",
    "weight" => "-6",
    "region" => "footer",
   ),
   "locale_0" => array(
     "module" => "locale",
     "delta" => "0",
     "theme" => "garland",
     "weight" => "-6",
     "region" => "footer",
  ),
  "comment_0" => array(
    "module" => "comment",
    "delta" => "0",
    "theme" => "garland",
    "weight" => "-6",
    "region" => "-1",
  ),
  "user_3" => array(
    "module" => "user",
    "delta" => "3",
    "theme" => "garland",
    "weight" => "-5",
    "region" => "-1",
  ),
  "menu_secondary-links" => array(
    "module" => "menu",
    "delta" => "secondary-links",
    "theme" => "garland",
    "weight" => "-4",
    "region" => "-1",
  ),
  "node_0" => array(
    "module" => "node",
    "delta" => "0",
    "theme" => "garland",
    "weight" => "-3",
    "region" => "-1",
  ),
  "book_0" => array(
    "module" => "book",
    "delta" => "0",
    "theme" => "garland",
    "weight" => "-2",
    "region" => "-1",
  ),
  "menu_primary-links" => array(
    "module" => "menu",
    "delta" => "primary-links",
    "theme" => "garland",
    "weight" => "-1",
    "region" => "-1",
  ),
  "user_2" => array(
    "module" => "user",
    "delta" => "2",
    "theme" => "garland",
    "weight" => "0",
    "region" => "-1",
  ),
  "op" => "Guardar bloques",
  "submit" => "Guardar bloques",
  "form_build_id" => "form-MDp7A-q38KEPNA9sdRAeMCaCbWAssDZmk7qGlYDJ7t8",
  "form_token" => "7c3d2c352dc01087b7f1723b9a10b5dc",
  "form_id" => "block_admin_display_form",
);
?>

And as you can see: the last 5 elements aren't arrays so aren't block definitions. Thus you got error when iterate over them.

I conclude:
The patch must test if gets or not an array So, pls return to first option at comment #6

@NaX
As i can see, the loop over $form_state['values'] is the main why to retrive submited values. So $blocks = _block_rehash(); is an unnecesary extra proccess. We only need to exclude 5 keys. Other are blocks. So adding a conditional to exclude is safe.

<?php
/**
 * The patch I'm currently using on my production sites
 * Process main blocks administration form submission.
 */
function block_admin_display_form_submit($form, &$form_state) {
  foreach ($form_state['values'] as $block) {
    if(is_array($block)){
      $block['status'] = $block['region'] != BLOCK_REGION_NONE;
      $block['region'] = $block['status'] ? $block['region'] : '';
      db_query("UPDATE {blocks} SET status = %d, weight = %d, region = '%s', throttle = %d WHERE module = '%s' AND delta = '%s' AND theme = '%s'", $block['status'], $block['weight'], $block['region'], isset($block['throttle']) ? $block['throttle'] : 0, $block['module'], $block['delta'], $block['theme']);
    }
  }
  drupal_set_message(t('The block settings have been updated.'));
  cache_clear_all();
}
?>

A second way is to exclude using explicit keys:

<?php  
/**
 * Process main blocks administration form submission.
 */
function block_admin_display_form_submit($form, &$form_state) {
  $to_exclude = array("op",  "submit", "form_build_id", "form_token", "form_id");
  foreach ($form_state['values'] as $key => $block) {
    if(!in_array($key, $to_exclude)){
      $block['status'] = $block['region'] != BLOCK_REGION_NONE;
      $block['region'] = $block['status'] ? $block['region'] : '';
      db_query("UPDATE {blocks} SET status = %d, weight = %d, region = '%s', throttle = %d WHERE module = '%s' AND delta = '%s' AND theme = '%s'", $block['status'], $block['weight'], $block['region'], isset($block['throttle']) ? $block['throttle'] : 0, $block['module'], $block['delta'], $block['theme']);
    }
  }
  drupal_set_message(t('The block settings have been updated.'));
  cache_clear_all();
}
?>

Completely on agree.

Then wath about if 1 admin deletes a block while the 2nd updates it?
It's the same scenario 2 admins working, each one his own row ... a extrange site but possible

I think the patch on #22 is good enough. It's clean and does not run expensive reloads.

I'd changed the status to be reported. I think It is good enough!

Oh! sorry i'll return to previous stage!