When trying to create a poll got the following fatal php error.
Unsupported operand types in C:\WWWRoot\drupal\modules\poll\poll.module on line 347

Running on Apache/2.2.4 (Win32) DAV/2 mod_ssl/2.2.4 OpenSSL/0.9.8e mod_autoindex_color SVN/1.4.5 PHP/5.2.3

CommentFileSizeAuthor
#8 poll_is_horrible.png54.27 KBcatch
#7 poll_is_ugly_as_usual.patch1.5 KBchx
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Gábor Hojtsy’s picture

Title: Poll gets fatal php error » Poll AHAH results in fatal PHP error

Hm, this is the AHAH form cache code. Line 347 is the $form += line. Seems like $cache->data is not an array(?)

  $cache = cache_get('form_'. $_POST['form_build_id'], 'cache_form');                                  
  $cache->data['choice_wrapper']['choice'][$delta] = $form_element;                                    
  cache_set('form_'. $_POST['form_build_id'], $cache->data, 'cache_form', $cache->expire);             
                                                                                                       
  // Build the new form.                                                                               
  $form_state = array('submitted' => FALSE);                                                           
  $form = $cache->data;                                                                                
  $form += array(                                                                                      
    '#post' => $_POST,                                                                                 
    '#programmed' => FALSE,                                                                            
  );                                                                                                   
  $form = form_builder('poll_node_form', $form, $form_state);
Gábor Hojtsy’s picture

What did you do exactly when testing? When did this error show up? As you tried to submit the form? As you pressed the button to ask for more choices? How can we reproduce?

kwikone’s picture

Status: Active » Postponed

I was trying to set up my test system configuration and was just entering a poll playing around with the various options such as putting in a different author, etc. When I hit submit all I got was a blank screen (I then hit back and submit again). It was not until sometime later I discovered the error in my php_error log.
I just tried to see if I could reproduce but I was not able to ( was able to do what I couldn't before though I am not sure if I set/reset all the same options ).
I am going to change the status to postponed until I have a more of a chance to see if I can recreate it.

kwikone’s picture

Status: Postponed » Active

I have managed to recreate this problem. In doing so I discovered what may be another problem..
To recreate. Start to create a poll. Fill in all relevant form fields (both answer fields especially). Click on the button to add a additional answer, (in my case I never get a response from this, this is how I discovered how to recreate this problem). While the icon spins to add an additional question click on the submit button. At that time I end up with a WSOD.

Gábor Hojtsy’s picture

Side note: does any of the other AJAX/AHAH callbacks work for you? Like changing the author username on a node, which provides an autocomplete?

Also, do you see this fatal error you opened the issue with in your error logs after you experience the WSOD? Or how did you get to know that error? Again, it looks like the cache data not being an array, but a few lines above, it is treated as such, and a new item is added to it, so you should get an error there too, right after the cache_get(). Interesting.

kwikone’s picture

Yes, other ajax calls all (that I have tested/used) appear to be working (at least any of the autocomplete such as for taxonomy term selections).
I discovered the error when I decided to check what showed up in my php error log (not the dblog/watchdog reports).
Yes, I agree that it is interesting and agree that it seems cache related and dont get at least some type of logged warning or notice prior to the fatal error. I am in the process of getting my server configured for php debugging (with xDebug) to see what more I can see, but due to my miniscule amounts of free time [huge copious amounts, :-), in my 28 hr days] it may be some time before I can get that far.

chx’s picture

Status: Active » Needs review
FileSize
1.5 KB

This should fix this bug because this is the only thing that differs between form.inc and poll ahah.

catch’s picture

FileSize
54.27 KB

OK I tried hard to reproduce the white screen (some very quick mousework to get the submit button in time required), but all I could get was the error attached. This appears patched and unpatched.

Leaving as needs review since I don't think it's necessarily connected, and I can't reproduce the original bug. I also don't think this is critical, but won't argue the point.

kwikone’s picture

Status: Needs review » Reviewed & tested by the community

Definitely works for me!! However, one question on the code. At lines 343 - 346 is the following

  $form += array(
    '#post' => $_POST,
    '#programmed' => FALSE,
  );

I am wondering why the comma after the FALSE. Does this not indicate an additional element to the array?

kwikone’s picture

The image (to me) seems to show something on the same order of having a server which disallows short tags and code with short tags which is not interpreted but just sent on as output.
However, the patch does resolve the issue for me so I marked it as ready to be committed.

catch’s picture

kwikone, it's common to leave the trailing comma in case something gets added to the array at a later date - it's easy to forget to add that extra comma when you're just adding a new line.

Gábor Hojtsy’s picture

The patch proposed by chx looks like a good cleanup here, but I'd like to have someone else *test* it too (so far only kwikone reported results).

kwikone’s picture

I agree. However, unless someone else has managed to recreate the original WSOD then they are only testing to make sure that nothing else has gotten broken which is a good thing to test for. When I marked as ready for commit I presumed that catch had at least tested to make sure that nothing else got broken.

catch’s picture

Yes, I did check everything works normally.

chx’s picture

So, catch tested everything else, worked. kwikone found it fixed the problem. I say it's the way it should have been in the first place. Sounds ready :)

Dries’s picture

Status: Reviewed & tested by the community » Fixed

Committed to CVS HEAD. Thanks!

Anonymous’s picture

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.