Regression: Fatal error - Cannot unset string offsets in includes\form.inc on line 385

Appears to be related to managing blocks and switching between themes with different regions. At least, that's how I triggered it. Didn't have a chance to dig deeper.

Confirmed with Beta 2. I did in fact set different admin themes from the main theme. If I revert back to the same theme for both admin and the enduser side, the problem persists.

The code block here in form.inc is:

// Add a token, based on either #token or form_id, to any form displayed to
// authenticated users. This ensures that any submitted form was actually // requested previously by the user and protects against cross site request
// forgeries.
if (isset($form['#token'])) {
if ($form['#token'] === FALSE || $user->uid == 0 || $form['#programmed']) {
unset($form['#token']);
}
else {
$form['form_token'] = array('#type' => 'token', '#default_value' => drupal_get_token($form['#token']));
}
}

I did a var_dump of $form after getting the error and $form was not an array but rather a string with the HTML to draw the block admin form. So $form['#token'] is not relevant since $form is not an array and thus has no keys such as #token. In fact dumping $form['#token'] in this case returns 'A' which was the 1st character of the string that is visible when I var_dumped $form. So this is likely a problem in the calling code which as mentioned before may be due to admin themes...

anyhow no solution yet but confirmed to exist in beta 2.

I have set my admin theme to Minelli and visited the admin/build/block page and then the pages for every block. I can't reproduce this. Unless someone else can and gives me access to the faulty server there is nothing to fix.

chx, this is happening on my install and I'll happily give you access.

Email beau@beaugunderson.com.

I also noticed that my $form started with 'A'. It looks like '<' has been replaced with 'A' for some reason in that string.

I noticed when printing out some menu items that their first character had been replaced with '1'. Possibly the same root cause, maybe a red herring.

Attaching a var_dump of $form taken just after drupal_prepare_form occurs.

I don't quite understand why var_dump gives the array representation and then a string representation. Is there something broken with pass-by-reference? I will keep digging...

This is slightly bizarre.

var_dump($form) before this line:

  if (isset($form['#token'])) {

returns an array (with the weird string on the end that you can see in the attached block.txt)...

and after that line returns a string!

Wow, it must be late; I was way off. :)

drupal_prepare_form is actually called twice for the blocks form, so that's why I saw an array representation followed by a wacky string representation.

Well, now we know that the weirdness happens after the first call to drupal_prepare form and before the second call.

More digging...

After mucking around with notepad++ and xdebug the picture is slightly clearer; a recent change to modules/block/block.admin.inc has it so that block_admin_display
now calls block_admin_display_form.

It seems that for some reason block_admin_display_form is returning a string which is not what drupal_prepare_form wants to see.

Beau supplied me with access and I think I saw one very confused menu_router table a menu_rebuild solved apparently the problem, I have not saved that table but Beau said in email he has backup, so now I am waiting for that.

Ok, attaching the menu_router table now. (This is 'grep menu_router dump.txt' for my database dump, so it also includes a line from the cache table).

Here's the same table after chx did a menu_rebuild.

You installed beta1 and then beta2 on top of it without zapping the database. Your old database has drupal_get_form('block_admin_display') for page callback, the new one has just 'block_admin_display' -- the change was in in this issue. HEAD->HEAD database updates are not supported. If you do that, try zapping your caches and issuing a menu_rebuild -- it either works or not. Without those, you have not chance.

Anyone, if you can replicate this with a clean D5->D6 upgrade (ie. taking a D5 database and running D6 HEAD on it) or a clean install then reopen.

I also noticed that my $form started with 'A'. It looks like '<' has been replaced with 'A' for some reason in that string.

I don't quite understand why var_dump gives the array representation and then a string representation. Is there something broken with pass-by-reference? I will keep digging...

I have the same error using D6.17

Fatal error: Cannot unset string offsets in E:\www\drupal\includes\form.inc on line 492

Im trying to include another's module form into my module.

function mymodule_download_form(&$form_state, $node)
{
module_load_include('inc', 'othermodule', 'includes/othermodule.download');
return drupal_get_form('othermodule_download_form', $node);
}

Anyone has an explanation?

Re-setting the status.

I think the answer to #18 is something like "don't do a drupal_get_form from inside of a form definition function."