Component value is corrupted in multistep forms (w/ Payment for Webform)

I have been digging through the code for a while, and it looks like Webform incorrectly sets the component value, but indeed only for multistep forms.

What happens is that Webform uses the value of the button that is part of the component as the component value.

I don't plan on fixing this issue considering it seems specific to Payment for Webform. If there is a particular patch or suggestion that can be made to avoid this problem in Webform, I'm happy to take a look, but I probably won't go digging into this particular conflict without more information.

@quicksketch: is it normal that the _webform_display_payment_webform() hook is called when the component is on another page?

The "display" hooks are only called when a component is having its value (rather than the form element) displayed. This happens when e-mails are sent, when viewing a submission, or when rendering a token for a previous field's value. Normally, none of these things happen until the final form is submitted. If it's happening between pages, there may be some kind of processing that is happening that Webform is not anticipating.

+++ b/payment_webform.webform.inc
@@ -81,7 +81,12 @@ function _webform_submit_payment_webform($component, $value) {
-  $pid = $value[0];
+  if (isset($value[0]) &&  !empty($value[0])) {
+    $pid = $value[0];
+  } else {
+      return;
+  }
+
   $label = t('Payment !pid', array(
     '!pid' => $pid
   ));

Just empty() should work too, and can you make sure this complies with the coding standards?

Also, can you explain the rationale behind this patch?

The comment is short, cryptic and refers back to this issue, so it needs some more love. What is a "bogus string value", why can it happen, and why is this the right solution?

+++ b/paymentreference/paymentreference.module
@@ -526,6 +526,12 @@ function paymentreference_field_access($op, $field, $entity_type, $entity, $acco
+
+  // Protect against a bogus string value: https://drupal.org/node/1994392
+  if (!is_numeric($pid)) {
+    $pid = 0;
+  }

We shouldn't do this. The form element documentation clearly states that the default value needs to be an integer. If there is a chance that a module sets something else, that module will have to add this check itself.

yes. That documentation says the default value which needs to be a Payment PID, which in the class Payment is documented as an integer.

Also able to reproduce this if you delete a payment and then return to the original webform, WSOD & same error

Bump. Does this problem still occur?

Good to know! We can't commit that, however, as this is a Webform issue. We'll either have to fix Webform or add a workaround to Payment for Webform.

What about this patch from #3. Does that work?

Could someone answer this question from #12?

What is a "bogus string value", why can it happen, and why is this the right solution?