Some blocks disappear after fresh install. I'm not sure how to if this is repeatable, but I'm sure block_assign_show function has one major error (second line) and two minor issues (result for empty condition list). Below a better version of code. I'm sorry I don't know diff and have no time to learn CVS connection to this site.

function block_assign_show($module, $delta) {
  $conditions = array();
  if (!array_key_exists('block_assign_conditions', $_SESSION)) {
    $result = db_query('select b.module, ba.condition_type, ba.condition_value, b.delta AS bid from {block_assign} ba, {blocks} b WHERE ba.module = b.module AND ba.box_id = b.delta AND ba.module = "%s" AND ba.box_id = "%s"', $module, $delta);
    while ($item = db_fetch_object($result)) {
      $conditions[] = $item;
    }
    $_SESSION['block_assign_conditions'] = $conditions;
  }
  else{
    $conditions = $_SESSION['block_assign_conditions'];
  }

  $res = empty($conditions);
  foreach ($conditions as $condition) {
    switch ($condition->condition_type) {
      case 'node':
        preg_match('/^node\/(\d*)$/', $_GET['q'], $matches);
        if ($matches[1] && $condition->condition_value == $matches[1]) {
          error_log('node matches '. $matches[1]);
          print('<pre>'. print_r($types, 1) .'</pre>');
          return true;
        }
        break;
      case 'type':
        if (isset($GLOBALS['globalnode']) && isset($GLOBALS['globalnode']->type) && $GLOBALS['globalnode']->type == $condition->condition_value) {
          error_log('type matches '. $condition->condition_value);
          print('<pre>'. print_r($GLOBALS['globalnode'], 1) .'</pre>');
          return true;
        }
        break;
      case 'uri':
        if (preg_match('/'. $condition->condition_value .'/', request_uri())) {
          return true;
        }
        break;
    }
  }

  return $res;
}

Comments

hawkdrupal’s picture

hawkdrupal commented
Title: Blocks disappearing after fresh install » Blocks disappearing after fresh install - PATCH FIXES
Priority: Normal » Critical

After installing 5.x-1.1 almost all my blocks disappeared, but vpiotr's patch brought them back.

But, instead of being controlled by Block Assign, the blocks appeared EVERYWHERE -- no matter what block assign was set to show. See my next post.

hawkdrupal’s picture

hawkdrupal commented
Title: Blocks disappearing after fresh install - PATCH FIXES » Blocks disappearing after fresh install, patch breaks module

Back to the drawing board. Did I misunderstand how Block Assign 1.1 works, after using 1.0 with good results? Maybe. The 1.1 docs say this:

Warning: Saving this block will update all of your blocks to cause them to use the block_assign feature; this will overwrite any PHP code you have set to be evaluated to determine block visibility.

I read this as affecting existing "PHP code", in my case a few blocks already set to use Block Assign. But the key word in the statement actually is "all" not "PHP code" -- Block Assign 1.1 altered EVERY BLOCK, including those using the simpler page show/hide method or simply showing on every page of the site (such as the footer stuff).

Block Assign 1.1 overwrote the list of page/path names OF EVERY BLOCK with its own PHP code. So almost every block disappeared. This was a big problem because I was using Block Assign 1.0 only on a few blocks and pages, and now 1.1 grabbed everything, but it didn't convert the simple show/hide paths to Block Assign settings, it just nuked the existing settings and the blocks vanished from view.

OK, if only I could reshow them using Block Assign 1.1, but for unknown reasons some would simply not reappear. Also, using Block Assign for some pages it much more complicated than simply listing paths to show/hide, therefore it's not a 1:1 alternative method. Unlike 1.0 which could be used where desired, Block Assign 1.1 seems to be an all-or-nothing proposition.

And, even if I could reshow by adding Block Assign regular expressions to blocks that previously had used the simple show/hide method, which blocks were they and how were they previously set? Block Assign 1.1 left me with nothing but faded memory of settings made months ago.

Needing a functioning site more than I needed to document every block vs. every page then write dozens of Block Assign regular expressions, I reverted to Block Assign 5.x-1.0 -- and found no blocks showing anywhere, because 1.1 had wiped out the prior page show/hide settings, of course. Rather then have the fun of restoring data from a backup, so ended up editing every block "from memory" after all. This got me back to stable environment, since Block Assign 1.0 works as expected.

Not a fun two days.

At this point I don't know if Block Assign 1.1 suffers from bugs or poor docs, or I'm supposed to read more into the Warning than I did. But I suggest the docs be much stronger and clearer in how different 1.1 is from 1.0. In fact, a module that is this changed in how it behaves and what it does isn't a ".1" increment -- more like 2.0, or maybe beta-2.

And the module could be better-behaved. Destroying data by simply activating a module updated from 1.0 to 1.1 is NOT good. For instance, shouldn't it grab control ONLY of blocks that are already set to use PHP code, as the docs imply? Is it necessary to wipe out non-PHP block visibility settings and functionality? Is it necessary to shut off the simpler show/hide mode?

Of course, I'm writing of this unfortunate experience because Block Assign is a terrific tool. Corrections to it -- or me -- are welcome.

fuquam’s picture

fuquam commented

After installing Block Assign ALL my blocks disappeared. I got rid of block assign but all my blocks, sidebars, and regions are either gone or empty now. How do I get them back?

giucas’s picture

giucas commented

I have the same problem!

yurtboy’s picture

yurtboy commented

I ran this to empy out all the blocks of this code.
UPDATE blocks SET pages = '' WHERE pages LIKE '%block_assign_show%'