I've got some code to create a new node which I'm trying to test, but it never gets invoked. I know this as I've put a breakpoint at the start of the function I'm calling from my code (node_save), but it never breaks there, even though this technique works with eval'd PHP code in other modules.

I've also tried it in additional validation, but it doesn't get called from there either.

Interestingly, it must be being parsed though because if a miss a semicolon or something, I get the usual PHP error reported.

Thanks in advance for your help.

Comments

quicksketch’s picture

Category: bug » support
Priority: Major » Normal

I don't quite understand this request. What are you trying to accomplish and how are you trying to do it? I generally don't provide support on how to write code in the Webform issue queue.

akarabin’s picture

I've got the same problem and didn't find the way to solve it, any PHP code that I'm using into de Additional processing, even an echo "hello world" doesn't work, altough I am pretty sure that redirection or Confirmation Message at least are working, I've already check permissions for this module to work for any user and still having no processing. I'm using exactly the same version. Thanks

quicksketch’s picture

Any call to echo or print won't show up, because the code is executed within an eval() command and any output is discarded. If you want to print out debugging messages, use the dsm() function provided by devel module.

akarabin’s picture

Thanks but not using devel module, but any operation into my php code it is not been evaluated, I've used the drupal_set_message and it didn't work. Also I'm using the drupal_write_record() function to insert a new register and it doesn't work either.

brack11’s picture

the same here: no code is working, as last resort tried $node->webform['confirmation'] = 'http://google.com'; with no luck

keva’s picture

neither $node->webform['confirmation'] nor $node->webform['redirect_url'] result in a redirect

quicksketch’s picture

neither $node->webform['confirmation'] nor $node->webform['redirect_url'] result in a redirect

I found the reason for this is because Webform PHP loads a copy of the $node variable for you to work with, rather than modifying the one Webform works with directly. This results in changes to the $node object not having any effect.

The code from webform_php.module that does this execution:

function webform_php_client_submit($form, &$form_state) {
  $node = node_load($form_state['values']['details']['nid']);

  if (substr($node->webform['additional_submit'], 0, 2) == '<?') {
    // Support for Drupal 5 validation code.
    $form_values =& $form_state['values'];
    // We use eval here (rather than drupal_eval) because the user needs access to local variables.
    eval('? >' . $node->webform['additional_submit']);
  }
}

However, the code IS being executed just fine, but changes to the $node object have no effect.

roball’s picture

Title: Additional processing/validation PHP code is not being invoked » PHP code changing the $node object has no effect
catofcheshir’s picture

So is there a way to set redirect by this module?

jennypanighetti’s picture

So, what DOES this module do, then? I need to set a conditional redirect in the node and add additional_emails in the node. With additional processing no longer supported by webform, how in the world do I add additional_emails now???

goodwillhinton’s picture

Any luck in resolving this problem? I am seeing the same thing.

Thanks!

primerdp’s picture

Category: support » bug
Priority: Normal » Major

Hi - is there a possible workaround for this available? I am in dire need :)

primerdp’s picture

So, sincerest apologies in advance if I break community guidelines here. This is a hack. I thought I would share it for those of you who need things *now*, but do not put this in a production system.

I know very little about Drupal, as this is my first day using it. So, for now, here's something that got it working for me:

$ diff sites/all/modules/webform/webformNew.module sites/all/modules/webform/webform.module
2003,2006d2002
<   if ($form_state['did_update_node']) {
<     $node = $form_state['updated_node'];
<   }
< 


$ diff sites/all/modules/webform_php/webform_phpNew.module sites/all/modules/webform_php/webform_php.module
84,86d83
< 
<   $form_state['did_update_node'] = 1;
<   $form_state['updated_node'] = $node;

Anyway, this could absolutely break everything as I did zero unit tests (or anything, for that matter).

goodwillhinton’s picture

primerdp: Thanks so much for that quick hack. That does seem to work. I'll do some testing and let you know if I find anything else.

kruser’s picture

subscribe

kruser’s picture

If you just want to redirect, I found that the drupal_goto(); function works...

http://api.drupal.org/api/function/drupal_goto

jfinkel’s picture

Perfect. Thanks.

roball’s picture

(pls ignore)

no2e’s picture

subscribing

Anonymous’s picture

Using drupal_goto() prevents the webform from showing as submitted. It doesn't show up under the submissions list or send an email out... it's like the submission didn't even happen.

Using this code:

<?php 
  if ($form_values['submitted_tree']['step_1']['are_you_currently_a_student'] == '0' && $form_values['submitted_tree']['conference_fees']['choose_conf_fee_reg'] != '')
   {
    drupal_goto('submitted','s=n');
  }
  if ($form_values['submitted_tree']['step_1']['are_you_currently_a_student'] == '1' && $form_values['submitted_tree']['conference_fees']['choose_conf_fee_reg'] != '')
   {
    drupal_goto('submitted','s=y');
  }
?>

It redirects perfectly though.

FooZee’s picture

I've found a solution, which is not supposed to be the normal behaviour, but worked fine for me, I found out that using " echo " ... u can just output whatever u want ! .... if u directly used something like echo "You have been Registered, successfully!" it won't appear as good though!... but think of using firebug to put this in the main content-area of ur theme ! (i.e. make echo output a static HTML page exactly similar to your website, and as I've mentioned, u can always get that code very easily with a tool like firebug :D

quicksketch’s picture

I wouldn't suggest the approach in #21, since if you print to the page it may prevent further processing by Drupal during the form submission. If you want to print content to the page, I suggest theming the confirmation page for the webform, as described in THEMING.txt included with Webform.

ainz’s picture

This worked for me: http://www.vilepickle.com/blog/2010/11/11/0086-redirect-webform-submissi...

It looks confusing at first but if you look at it, its quite simple:

Firstly the code he uses in Additional Processing to some extent adds to the confusion:

  if ($form_values['submitted_tree']['fieldset']['fieldname_under_fieldset'] == '0' && $form_values['submitted_tree']['fieldset_last_page']['fieldname_under_fieldset'])
 
   {
    $_SESSION['exredirect']['redirect_url'] = 'http://example.org/submitted?s=n';
  }else{
    $_SESSION['exredirect']['redirect_url'] = 'http://example.org/submitted?s=y';
}

Just use whatever if statement resolves TRUE for your particular webform based on your fieldnames. I used:

  if ($form_values['submitted_tree']['participant_type'] == 'international_participant')
    {
    $_SESSION['exredirect']['redirect_url'] = 'http://example.org/submitted?participant=int';
  }else{
    $_SESSION['exredirect']['redirect_url'] = 'http://example.org/submitted?participant=local';
}

Dont forget if you changed the name of the variable being passed you have to change it in the php code on the submitted page as well. Values are being submitted to the database without any problem

Anonymous’s picture

That's actually my blog post :P

The first if statement is checking a field on the first page of the Webform (the one I really want to check) and also if a field is defined on the last page of the Webform. The reason I did this is because I used it on a multi-page Webform and it would perform the validation from the snippet when I hit "next page" and not just the "submit" button on the final page. I had to do an additional check to make sure the field on the last page was defined. Unsure if it's a bug but it seemed like something that shouldn't be happening.

ainz’s picture

:) Nice...small "world". Now I get to thank you! I was trying to do it on your blog but it wasn't immediately obvious where I should create an account (or maybe I didn't try hard enough :S. I had thanking you on my TODO list though. This was a life saver. Had to look at it for a while but it worked perfectly once I figured out what was happening. I thought the php page as a processor was genius! I understand what you were doing now that you explained it.

I really need to get comfortable with mod development so I can help with issues like this but thanks again!

cashbrown’s picture

Big ups @ vilePickle for the fix. I made one small change: rather than create a "formredirect" page like you said in your instructions, I threw together a small "formredirect" module with the drupal_goto() and other code I needed. That way I can do this without enabling PHP filter :)

Thanks again!

Anonymous’s picture

Actually another caveat of the drupal_goto in a separate page that I found was that if you have search enabled on your website your cron will not run properly. It encounters the drupal_goto and actually executes it, redirecting away from your cron run. Apparently this was a big issue when I googled it and it hasn't been fixed in years. I fixed it by disabling search on the site I use this on because it wasn't needed (there were other workarounds that... didn't work for me). Cashbrown's module approach is probably a much better solution... you might look into putting that up for the public on drupal.org.

HMahoney’s picture

I have been trying to solve this problem for several days. I'd really like to see Cashbrown's approach. Please?

ainz’s picture

cashbrown’s picture

I'll clean up what I have and try to get it posted in the next few days. What I put together was very specific for my purposes; passing information to an authorize.net gateway. At the moment it's barely cobbled together :)

ainz’s picture

This might be obvious but I had to ask. What is the downside to referring directly to the actual node instead of loading a copy of it?

quicksketch’s picture

What is the downside to referring directly to the actual node instead of loading a copy of it?

I'm not sure, but I may have done this specifically done this so that you couldn't break your webform by doing something like $node = node_load($other_nid);, which had caused some support requests in the past.

Really the big reason right now is because I don't want to have to modify Webform in order to support this module which I don't really want to exist anyway.

phacts’s picture

I have found a way to solve this problem using an approach that I think quicksketch intended for the webform_php module. Basically, open up the module and copy the hook_form_alter code to your own module, then do this:

<?php
/**
 * Implementation of hook_form_alter().
 * I literally took this right out of the webform_php module, which is what quicksketch intended.
 */
function MYMODULE_form_alter(&$form, &$form_state, $form_id) {
  // Affect all Webform forms.
  if (substr($form_id, 0, 20) == 'webform_client_form_') {
    // Add the submit handler after the existing Webform submit handler,
    // but before the second Webform handler. Pop off the first one and add
    // ours second.
    $first = array_shift($form['#submit']);
    array_unshift($form['#submit'], $first, 'MYMODULE_client_submit');
  }

}

/**
 * FAPI #submit handler. Execute some code, using the actual $form variable.
 */
function MYMODULE_client_submit(&$form, &$form_state) {
	// alter the $form['#node'] variable here all you want, and it will actually work!
}
?>

I use this to alter the email sendto address in the $form['#node'] object, and it works. Enjoy, and good luck!

quicksketch’s picture

Status: Active » Closed (won't fix)

#1043088: This project is abandoned, please stop using it

Note that any API changes needed to dynamically change the submission URL or other settings via an API change would still be considered, but if you're writing a custom module like you should be anyway, you can just set $form_state['redirect'] anyway.