Messages In Multipage webform

I can't reproduce this using the latest dev. I tried both with and without the Automatically Save Drafts Between Pages option.

I suspect that some other module is modifying the form. You'll have to debug to see what's going on. If you do find that there is a bug with Webform, please re-open with more information.

I suggest you start by disabling all webform-related modules other than webform.

Also, a stack trace to see which caller of webform_submission_create is the problem would help.

Same behavior, same issue:

Notice: Undefined index: submitted in webform_submission_create() (line 56 of /var/www/develop.lva.lt/drupal/sites/sgk.lsmuni.lt/modules/webform/includes/webform.submissions.inc).
Warning: Invalid argument supplied for foreach() in webform_submission_data() (line 24 of /var/www/develop.lva.lt/drupal/sites/sgk.lsmuni.lt/modules/webform/includes/webform.submissions.inc).

Steps:
fill webform's fields in page 1
press "Next ..."
fill webform's fields in page 2
press "Next ...", then "Previous ..."
press "Next ...". Ooops, issue.

Edited:
I eliminate those warnings by adding some lines to function webform_submission_create:

function webform_submission_create($node, $account, $form_state, $is_preview = FALSE, $prototype = NULL) {
 -- $data = webform_submission_data($node, $form_state['values']['submitted']);
  ++ $data = array();  
  ++  if (isset($form_state['values']['submitted'])) {
  ++     $data = webform_submission_data($node, $form_state['values']['submitted']);
  ++ }

I'm having this same issue on an intranet site I'm developing and the error is strangely inconsistent. The group of webforms have almost identical components set up in an identical fashion, but the error is only kicked out on two of six webforms.

The only reason I even did multiple webforms was to keep the data separate by category, but the categories all require the same components. (for example, if you had one webform collecting info regarding "cars" and a different webform for collecting info regarding "trucks")

They are all styled identically as follows:
Start
CID1 = A simple intro markup component,
CID2 = a simple number component for entering the number of items you want to enter (i.e. "How many cars do you have?")
Page 2
Fieldset 1 = "First Car"
Fieldset 2 = "Second Car"
Fieldset 3 = "Third Car"
Fieldset 4 = "Fourth Car"
Preview
Complete

Form settings allow blocks, save draft button, save on next page

Conditionals are
If CID2 > 0, Fieldset 1 Shown
If CID2 > 1, Fieldset 2 Shown
If CID3 > 1, Fieldset 3 Shown
If CID4 > 1, Fieldset 4 Shown

That's it in a nutshell, but the errors kick out when I proceed to page two in 2 of my 6 webforms ...

I have telephone, date popup, and structured text modules enabled, but none of these fields are used in the two webforms which are kicking out the errors and the webforms where they are used are not kicking out any errors.

I ran cron, updated, erased cache, uninstalled rules and other modules that are touchy with webforms, but the errors are still there.

BTW, I meant to write that the conditionals are ...

If CID2 >= 1, Fieldset 1 Shown
If CID2 >= 2, Fieldset 2 Shown
If CID3 >= 3, Fieldset 3 Shown
If CID4 >= 4, Fieldset 4 Shown

First, disable those other modules to validate they they aren't causing the issue.
Second, removing conditionals one at a time to see if one or more is relevant.

Basically narrow down the circumstances until you can diagnose why some of your webform have the issue and others don't.

Or hire a developer to install a debugger, put a break point on the offending line and get a stack trace and explanation. I don't see any other way I can help from afar.

My errors disappeared when I removed the page breaks, but I thought the inconsistency was interesting. All 6 webforms had a "how many" field on page one and conditionals set to show that number of fieldsets on page two, but only two of the webforms would show the error while the other four were fine. Perhaps it had something to do with whether I set the page break before I set the conditionals? That factor may have differed between the webforms, but I'm not sure. All I know is that updating didn't fix the two webforms with the undefined index error, only removing the page breaks did.

@sjekoken -- can you start with a new webform node and no other webform-related modules enabled and provide the simplest instructions necessary to reproduce the issue?

It seems (krum exposing it) like function webform_submission_create() is calling twice on navigate to back/next webform's page.
In first call, it comes with !isset( $form_state['values']['submitted']) and generates warnings, because variable $data is not set. In second call, the variable $form_state['values']['submitted'] is filled in and provide a valid behavior of function. I think, a little patch, like

 -- $data = webform_submission_data($node, $form_state['values']['submitted']);
  ++ $data = array();  
  ++  if (isset($form_state['values']['submitted'])) {
  ++     $data = webform_submission_data($node, $form_state['values']['submitted']);

will eliminate a garbage warning... :). Not tested in other environment, different from project, on I'm working now. Sorry. :)

@vitalijus -- We need to figure out the root cause. We don't add tests to handle data that we know should be present. Instead we figure out why the data isn't present make make it present.

I do see an inconsistency in markup.inc, function _webform_render_markup_after_build():

  // Convert existing submitted data to an in-progress submission.
  if (!empty($form_state['storage']['submitted'])) {
    module_load_include('inc', 'webform', 'includes/webform.submissions');
    $submission = webform_submission_create($node, $user, $form_state, TRUE, $form_element['#webform_submission']);
  }

$form_state['storage'] is tested, but $form_state is passed to webform_submission_create. However, I cannot create a situation where storage is set (i.e. the form has already been built once for a multi-page form) and yet $form_state['values']['submitted'] isn't also set.

Are you using some ajax on this page, perhaps? I need more data to help find the root cause.

@DanChadwick: no, I'm not using any Ajax calls :) & OK, I can debug or test function _webform_render_markup_after_build() and submit results. But later, because vacations, vacations :).

This message can be reproduced if save draft and preview pane is enabled. Once the user logs out at preview screen but does not submit and logs back this message appears.

Re #13. Thanks for this. I've reproduced the issue, but it is unrelated to the markup issue above. I think we have two different causes. The #13 issue is caused as a regression to the code which resumes a draft at the highest saved draft page. webform_client_form sets $form_state['storage'] but doesn't set the ['values']['submitted'], which I think it should.

That still leaves the issue with markup components. The right values would be those calculated in webform_client_form's $input_values, but that isn't available easily in the webform component.

This patch makes two changes:

1. When the form is built, the most current values, as determined by the submission, the stored values, and the input from the user, and as evaluated by the conditionals, is stored in the $form_state['#conditional_values']. It was already stored in $form['#conditional_values'] (for the purpose of being passed to the browser for use in executing intra-page conditionals with javascript). By saving these values in the $form_state, they are available to components. The markup component uses these values to generate tokens.
2. When a draft is resumed (i.e. when the webform node is displayed and there is already a draft saved), the $form_state['values']['submitted'] is set the the calculated conditional values. This is already stored in $form_state['storage']['submitted'], but ['values'] is needed to generate a submission for the purpose of the preview page. Previously ['values'] was only set if a new preview page was being forced onto the user because the last current page is blank.

Both of these changes should both provide the correct values for tokens and avoid the PHP notices. I have tested all the relevant cases that I can think of, but additional testing would be welcome.

Committed to 7.x-4.x.

Port to D8 needed.

I just experienced and followed this issue today, 4 hours later Dan fixes it.

If only all issues were as easy/quick to solve :P

Committed and pushed to 8.x-4.x.