Problem/Motivation

"Per webform" overrides for previous and next label are not taken into account.

Steps to reproduce

Drupal 10.2.5
Webform 6.2.7

1. Create a webform and override the previous and next label, at the "webform" level.
2. Do not override labels at the "wizard page" level
3. Check on the webform : buttons labels are still using the native labels, not the ones overridden at step 1

If I override the labels at "wizard page" level, these values are correctly taken into account.
But as my buttons have the same labels on all pages, it would be much easier if I could enter their value just once, at the webform level.

Issue fork webform-3468142

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

clemorphy created an issue. See original summary.

aaron.ferris’s picture

Can confirm this, seems we fallback to the default global webform settings should a 'per page' wizard next/previous label not be defined.

From a quick look, we could possibly add another condition in WebformSubmissionForm that uses the following order:

1. Per page wizard settings as a priority
2. Then Per webform settings
3. Then fallback to default settings

IE, like the attached MR.

aaron.ferris’s picture

Status: Active » Needs review
liam morland’s picture

Version: 6.2.7 » 6.3.x-dev
clemorphy’s picture

Thanks a lot aaron.ferris
I have tested your MR from #3, applied on version 6.2.7, and it works perfectly for me.

Edit : not so perfectly. I have the following warning (without noticeable impact) :

Warning: Undefined variable $next_button_custom in Drupal\webform\WebformSubmissionForm->actions() (line 1567 of modules/contrib/webform/src/WebformSubmissionForm.php).

liam morland’s picture

Status: Needs review » Needs work
Issue tags: +Needs tests

It looks like $next_button_custom is not getting set. That needs to be fixed. This also needs tests.

aaron.ferris’s picture

Ah yes, ive fixed that - id need more time to look at writing a test.

clemorphy’s picture

Ah yes, ive fixed that - id need more time to look at writing a test.

I confirm that the error is gone with the updated MR!506
Thank you.

darvanen’s picture

The button label doesn't get overridden *there*, but it does get overridden in \Drupal\webform\Element\WebformActions::processWebformActions

      // Apply custom label.
      $has_custom_label = !empty($element[$button_name]['#webform_actions_button_custom']);
      if (!empty($element['#' . $settings_name . '__label']) && !$has_custom_label) {
        if (isset($element[$button_name]['#type']) && ($element[$button_name]['#type'] === 'link')) {
          $element[$button_name]['#title'] = $element['#' . $settings_name . '__label'];
        }
        else {
          $element[$button_name]['#value'] = $element['#' . $settings_name . '__label'];
        }
      }

jrockowitz made their first commit to this issue’s fork.

jrockowitz’s picture

Status: Needs work » Needs review

Let's see if the tests pass with 6.3.x and decide if additional test coverage is needed.

jrockowitz’s picture

Below are my review steps

  • Install webform_examples module (/admin/modules)
  • Goto Example: Wizard (/form/example-wizard)
  • Set the Wizard button label to {prev} and {next} (/admin/structure/webform/manage/example_wizard/settings/form)
  • Confirm that labels are NOT applied.
  • Switch to the MR
  • Confirm that labels are applied.
jrockowitz’s picture

Status: Needs review » Needs work

Yep, I am not seeing any test coverage and here is where I think we need to add some \Drupal\Tests\webform\Functional\Wizard\WebformWizardAdvancedTest

jrockowitz’s picture

Status: Needs work » Needs review
jrockowitz’s picture

Issue tags: -Needs tests

jrockowitz’s picture

Status: Needs review » Fixed

Now that this issue is closed, please review the contribution record.

As a contributor, attribute any organization helped you, or if you volunteered your own time.

Maintainers, please credit people who helped resolve this issue.

Status: Fixed » Closed (fixed)

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

clemorphy’s picture

Is it normal that it hasn't been merged into branch 6.2 too?

liam morland’s picture

At this point, 6.2.x is only fixing serious bugs and security issues. It goes EOL with Drupal 10 in a few months.