While trying to look at a "roll your own" solution for displaying a progress bar (see my comment here: http://drupal.org/node/258696), I started digging through the available themeable elements. I'm also using Theme Developer to inspect the various renderings so try to compare code vs. result.

In the default implementation of webform-form, I see two variables ($form['submission_info'] and $form['navigation']):

  // If editing or viewing submissions, display the navigation at the top.
  if (isset($form['submission_info']) || isset($form['navigation'])) {
    print drupal_render($form['navigation']);
    print drupal_render($form['submission_info']);
  }
...
  // Print out the navigation again at the bottom.
  if (isset($form['submission_info']) || isset($form['navigation'])) {
    unset($form['navigation']['#printed']);
    print drupal_render($form['navigation']);
  }

The comments in the file make them sound like navigation that is handled when an administrator is browsing among completed submissions and not the form. Aren't these already covered in the webform-submission-page.tpl.php and webform-submission-navigation.tpl.php templates? I'm seeing nowhere in the module code where these form elements are ever populated.

On semi-related topic, if I did want to go down the path of creating my own progress bar, my best bet is to override theme_webform_view, correct? That's the only opportunity I see to have access to $node->webform['components] so that I can extract page break titles. My only apprehension is because in the default implementation, I see a conditional checking if the form is enabled and only renders the form if that is true.

function theme_webform_view($variables) {
  // Only show the form if this user is allowed access.
  if ($variables['webform']['#enabled']) {
    return drupal_render($variables['webform']['#form']);
  }
}

Is that better handled somewhere in the body of the function webform_node_view so that all overrides of theme_webform_view have to perform this check on their own?

If in either case I'm on the right path, I'd be happy to submit a patch. I just want check I'm not misunderstanding the code first.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

quicksketch’s picture

The comments in the file make them sound like navigation that is handled when an administrator is browsing among completed submissions and not the form. Aren't these already covered in the webform-submission-page.tpl.php and webform-submission-navigation.tpl.php templates?

I think you're right. They may have been left there for some measure of backwards compatibility or they may have simply have been forgotten when we created a separate template for webform-submission-page.tpl.php.

On semi-related topic, if I did want to go down the path of creating my own progress bar, my best bet is to override theme_webform_view, correct? That's the only opportunity I see to have access to $node->webform['components] so that I can extract page break titles.

I would probably suggest using webform-form.tpl.php. You have access to the node and webform components in $form['#node'], and information about the current page in $form['details'].

Is that better handled somewhere in the body of the function webform_node_view so that all overrides of theme_webform_view have to perform this check on their own?

That check is intentionally left there in the event that users want to show the form even though it is disabled. Perhaps that should be located in some other place, but making it accessible in the theme layer is a simple way of allowing users to change the behavior.

quicksketch’s picture

Title: What are the purpose of $form['submission_info'] and $form['navigation'] in the webform-form.tpl.php? » Extra $form['submission_info'] and $form['navigation'] in webform-form.tpl.php do nothing
Category: support » bug
Priority: Normal » Minor
Status: Active » Fixed
FileSize
1.02 KB

I've removed the excess code with this patch. These lines don't do anything any more.

Status: Fixed » Closed (fixed)

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