Webform causes error in PHP 5.3

I am getting this too :(

same problem here. Get the same warning message after I updated to 6.14 from 6.13 ( updated because 6.14 supports PHP 5.3 )

Here is my error message:
warning: Parameter 2 to webform_client_form() expected to be a reference, value given in C:\inetpub\wwwroot\Drupal_Beta\includes\form.inc on line 371.

Here is line 371:
// If $callback was returned by a hook_forms() implementation, call it.
// Otherwise, call the function named after the form id.
371: $form = call_user_func_array(isset($callback) ? $callback : $form_id, $args);

PLEASE CAN SOMEONE PATCH THIS.

The ACQUIA distribution of Drupal came with 6.14 Drupal and the latest Webform download (i.e. broken out of the box!)

Thank you :)

1. Is everyone who is experiencing this issue using PHP 5.3, or are people seeing it on earlier versions of PHP as well?
2. For people using PHP 5.3, did Webform ever work for you at all before upgrading Drupal to the latest version?

The reason I ask is that this sounds like it has the hallmarks of a PHP 5.3-specific bug, and I'm not sure if the Webform module really supports PHP 5.3 in general (most contributed modules probably don't out of the box).

Also, what is the actual effect of the bug besides the warning message - what things are actually broken?

The same thing is happening on a server running PHP 5.2.6 . What is broken is that on trying to make changes to an existing webform, eg. adding a new textfield, I am able to step through the process of editing the component's settings(default values, etc). And once it is created it even looks like its there when editing the form components however when viewing the form, I DO NOT see the newly created textfield.

I see the following warning when I try to edit the form component(eg. on page Edit component: test (textfield)):

# warning: implode() [function.implode]: Invalid arguments passed in /home/dm6/includes/form.inc on line 831.

ok. Looks like this last upgrade broke a bunch of stuff and there are patches out there to test:

#302240: button broken due to fix various problems when using form storage
#591696: 6.14 broke AHAH with form validation
#584536: Multipage forms are not working

I can't duplicate this problem.

Follow-up note - this patch seems the most comprehensive:
http://drupal.org/files/issues/drupal.form-button-submit.38.patch

@varunity, could you clarify whether or not you also see the original warning: Parameter 2 to webform_client_form() expected to be a reference, value given in \includes\form.inc on line 371. warning message that was first reported in this issue, or only the other warning message? It sounds like the other one might be a different bug.

@mgifford: I couldn't duplicate this problem either, which is one of several reasons I think it might be a PHP 5.3-specific bug, but I could be wrong.

I fixed my problem, by uninstalling php 5.3 (carefully removing everything), reinstalling nts php 5.2 etc....

Acquia keeps their crown...my mistake...they had 5.2 in their requirements :)

Yep, problem was PHP version 5.3 not Drupal version.

Yes, thank you.

It could quite well be a PHP 5.3 bug. Some edits to the template.php file removed the warning I was getting so that the problem I was having was no longer happening.

Looks like I had similar symptoms being produced by a different problem.

Thanks and sorry for the false alarm

I'm not going to stay that I fully understand the magnitude of the changes made in PHP 5.3.
Nor do I fully realize the impact that this proposed patch will have on the Webform module.

Please advise me in my purposed changes below.

In Webform-6.x-3.x-dev there are two (2) function calls that cause this error.

Issue?:
In both cases, the function defines the $node variable to be called by reference.

Analysis:
I've examined both functions and there does not seem to be any reason to have the $node variable called by reference.
Upon comparison to an identical function in the Node module, I can confirm that the $node variable does not even need to be called by reference.
Also, I believe that the $form_state variable in both functions SHOULD be called by reference. (could this just be a typo that has just gone in noticed? or no?)

Solution:
Removal of the ampersand & for the $node variable, in both functions, to no longer call this variable by reference, resolves the issues seen in PHP 5.3, and Webform functions properly, as it should.
Adding the ampersand & in both functions to the $form_state variable has no apparent affect, suggesting adding it to conform to the Drupal API. (is this even right?)

If this solution is incorrect or will impede the function of Webform in anyway, please advise and expound on the reasons, thanks.

**Please note that I did this patch for Webform 6.x-3.x-dev because that is what I had set up on my development machine at the time of this writing.

Looks to me like that's probably right - based on a quick glance at the code, it doesn't seem like $node is ever getting modified in those functions anyway.

If $node does need to be modified, there's a way to do it as well, but it's a little odd - you would need to set it by reference when preparing the arguments that get sent to the form (rather than or in addition to the form definition itself). Turns out PHP does things a little backwards in this very specific use case, and PHP 5.3 in particular chokes pretty badly if the rules aren't followed exactly correctly. For more details from a similar bug in Drupal core, see #547846: Drupal installation fails on MAMP & XAMPP due to pass-by-reference error.

Post #12 fixed it for me in 6.x-2.8, so far no problems with form function.

Yeah, I lost my webforms when I moved to a 5.3 server.

Symptoms:

In page source, the <form> tag is there, but the components of the form that I added to the webform node do not display.

In the admin, I cannot edit the form components. I can see the list, and when I click "edit" I am directed to what looks like the end-user View page of the form, again with no components showing.

Error logs are showing a lot of Function ereg() is deprecated... errors. Though, the file indicated in the error is /includes/file.inc

Haven't had a chance to apply the patch yet.

#12 looks correct to me also and should not have any negative side-effects. I've committed to both 2.x versions and the 3.x version.

Attached are additional patches for the 2.x versions.

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