Display summary page (aka review) before submission

I second that, this will be a great feature to have. I currently use a multi-page form, so having a summary page will help the user.

Agreed this would a good feature. Marking it as a possible feature for 2.x which I am going to start on soon.

See #1896712: [Meta] Features and Changes for Entityform 2.x

this could be a good feature to display a summary of what form data user is selected before confirm to submit.

is there any work around solution before 2.x come out ?
I really need this feature

I think there would be custom programming. Beside that it doesn't seem so.

I also need the feature pretty urgently, so I'm willing to (forced to, rather) begin working on a patch for it in the mean time.

I imagine I'll try to replicate what the Node module does it for its node 'Preview' prior to node creation. Anyone got any thoughts or pointers as to how it should be done?

I am thinking that it should be a checkbox option on the Entityform Type like "Show review before submit". So not all forms would have to have it.

It should not happen on Draft.

Fields should be validated before the Preview(they aren't validated on draft).

There should probably be a new "preview" View Mode which would determine which fields would be shown on the Preview screen.

The entityform should not actually be saved to the database until after the Preview screen is accepted.

There should be a "back" button to change the submission.

It will need to work with multi-page forms that are created with the Field Group module.

I imagine I'll try to replicate what the Node module does it for its node 'Preview' prior to node creation.

1 major difference I see in how the preview should act for Entityforms as oppose to nodes is Node preview shows on the same page as the add/edit form for nodes. I think it separate "review" screen for entityforms.

@bjcooper if want to contact me directly about this work, feel free. There is contact form/info on your Drupal.org account profile so I can't contact you.

@kasalla I don't think that will work b/c it is really not meant to be used by another form, in our case the entityform_edit_form.

This is more to confirm an action you about to take like deleting an entity.

From: http://drupal.org/node/470834

Sometimes it is useful to display a confirmation message before processing a form, especially when doing something irreversible, like deleting content.

While this a useful explanation for the front end user it is misleading to as to what is happening in the form system in Drupal. When you are on the node edit screen and you click the "delete" button what happens is

1. The add/edit form is submitted.
2. Drupal then sends you a separate form created by the conform_form function. This form is passed the nid of the node so it know which form to delete.
3. This form is completely separate

I think this will more be like a multi-step form. You can see an example in the Examples module, the form_example submodule multistep example.

@kasalla 1 problem I think that you are going to run into is the that confirm_form function use a $path variable to determine where the user is redirected to if they "cancel" the form.

$path: The page to go to if the user cancels the action. This can be either:

A string containing a Drupal path.
An associative array with a 'path' key. Additional array values are passed as the $options parameter to l().

So the problem when using with entityforms is that when the user clicks cancel(we might label it "go back") then they will lose the state of the current submission. With a multi-step form you can retain the $form_state.

The only way would be to store the $form_state in $_SESSION variable, keyed by a individual identifier (e.g. the form id) which is added to the cancel-link.

This would add complexity that isn't needed just to use confirm_form for something it really isn't meant to do. Adding info into $_SESSION would be a last resort.

I have been thinking about this and doing it via a multi-step form would not be that difficult. Just haven't had time.

These are great points; thanks @tedbow and @kaslla. I've just had another project come up, so I won't be working on this quite yet. We'll see who gets time first.

Here is quick first try. It will probably need work but it does work for me. It is against 2.x

Please review.

Changing to needs review

I have committed this to 7.x-2.x. Still could use some review

Thanks for report. I haven't seen this

    $entity_info = entity_get_info($entity_type);
    foreach ($entity_info['view modes'] as $view_mode => $view_mode_info) {
      if (!isset($settings[$view_mode]['custom_settings']) && $view_mode_info['custom settings']) {
        $settings[$view_mode]['custom_settings'] = TRUE;
      }
    }

This is were the error is coming from but our implemantion of hook_entity_info provides 'view modes'. So maybe it is coming from another entity providing module that used on the form?

If you want to figure it out you could either set debug or add these lines in(temporarly of course)

    $entity_info = entity_get_info($entity_type);
     if (!isset($entity_info['view modes'])) {
        drupal_set_message("entity type $entity_type has no view modes");
    }
    foreach ($entity_info['view modes'] as $view_mode => $view_mode_info) {
      if (!isset($settings[$view_mode]['custom_settings']) && $view_mode_info['custom settings']) {
        $settings[$view_mode]['custom_settings'] = TRUE;
      }
    }

Strange, to figure out if this related to viewing this screen you could try a couple things:

1. Make a very simple form and see if it has this problem. Then try to add other fields to it.
2. Try to use the 'review' view mode in way besides this screen,like make a View that list submissions using the 'review' mode. Does the problem everytime this view mode is displayed.

Changing fix to clean up 2.x issues

<?php
$form['actions']['submit']['#submit'] = array('custom_submit','entityform_edit_form_submit');
?>

That works very well. The problem is when I enable form preview before submission. custom_submit function runs before preview is generated and not after it was confirmed.