form.inc generates string offset as array error

I'm using exactly the same php and zend engine version on a Mac, cvs-head from 20th/oct., same line in includes/form.inc but I don't have any problems getting any admin page. Could this be a php.ini issue?

you are right. Cannot access admin/settings/event page. This is the error message:

Fatal error: Cannot use string offset as an array in /Library/WebServer/Documents/drupal-head/drupal/includes/form.inc on line 191
Call Stack
#	Function	Location
1	{main}()	/Library/WebServer/Documents/drupal-head/drupal/index.php:0
2	menu_execute_active_handler()	/Library/WebServer/Documents/drupal-head/drupal/index.php:15
3	call_user_func_array ()	/Library/WebServer/Documents/drupal-head/drupal/includes/menu.inc:359
4	system_site_settings()	/Library/WebServer/Documents/drupal-head/drupal/includes/menu.inc:359
5	module_invoke()	/Library/WebServer/Documents/drupal-head/drupal/modules/system.module:925
6	call_user_func_array ()	/Library/WebServer/Documents/drupal-head/drupal/includes/module.inc:166
7	event_settings()	/Library/WebServer/Documents/drupal-head/drupal/includes/module.inc:166
8	form_radios()	/Library/WebServer/Documents/drupal-head/drupal/modules/event/event.module:149
9	form_get_error()	/Library/WebServer/Documents/drupal-head/drupal/includes/legacy.inc:187

Event 4.6.0 does the same. Looking at it.

This is not a php problem. This is a problem related to the new forms API included with HEAD (next 4.7). Just look at the, for instance, aggregator.module (cvs), within the aggregator_settings function, to see how a form radios element would need to be declared in 4.7

$form['aggregator_category_selector'] = array(
    '#type' => 'radios', '#title' => t('Category selection type'), '#default_value' => variable_get('aggregator_category_selector', 'check'),
    '#options' => array('check' => t('checkboxes'), 'select' => t('multiple selector')),
    '#description' => t('The type of category selection widget which is shown on categorization pages. Checkboxes are easier to use; a multiple selector is good for working with large numbers of categories.')
  );

Where event.module uses the old method:

form_radios(t('Event time zone input'), 'event_timezone_input', variable_get('event_timezone_input', 'site'), array('site' => t('Use the sitewide time zone'), 'user' => t('Use the time zone of the user editing or creating the event'), 'input' => t('Allow users to set event time zones')), t('Events are saved with a time zone value. This setting allows you to determine how the time zone is determined when creating or editing an event.'));

Just a couple of days, in Amsterdam, at the DrupalCon, core developers where talking about the need to update 4.6.x, and less, modules to work with 4.7 because of this new forms API. I guess discussions will continue during the week until the end of the DrupalCon. This is not yet documented at the drupaldocs.org.

It looks like it was a bug in the form definition. There were two things that looked wanky.

First, $form['event_timezone_input']['tz_display'] was being assigned using .= rather than =.

The other seemed more like a typo. One of the options for $form['event_timezone_display']['tz_settings'] was 'user" disabled' => t('Use the time zone of the user editing or creating the event'), which I assume should have been 'user' => t('Use the time zone of the user editing or creating the event'),.

In the patch, I reformated the form definition to make it more readable (as per the recent thread on drupal-devel).

changing the formatting was a bad idea as it complicated the readability of the patch. I also do not really like that formatting and it has not been agreed upon.

Can you please provide a patch without reformatting?

I tried to apply it manually.

Similar error, different line number, listed in http://drupal.org/node/35998.

Thomas, the relation is that modules haven't been fully updated for the new Forms API. The form setup happens in the module and then form.inc tries to parse it and finds that it isn't correct.

killes, I'll acknowledge that changing the formatting in the patch wasn't a good idea. Perhaps I'd misunderstood what I thought to be the conclusion to that thread. That said I disagree, the multi-line format is far more readable. I think the other advantage is that patches to that format are also more readable.