Add support for detecting the triggering element when buttons are changed client-side

Created on 6 August 2015, over 9 years ago
Updated 2 May 2024, 7 months ago

I fall into problem that if some of buttons changed on client side and form has several submit buttons,
first button will be selected as $form_state['triggering_element'].

There is a related topic for D8 to rely on #name of buttons and ensure that #name is unique within form.
What i want to make with this patch is just backport of same idea.

If button was not identified by #value instead of just take first from buttons, just try to look up within POST data by button's #name if it exists.
Advantage of this approach that all backward compatibility supported.

✨ Feature request
Status

Needs work

Version

11.0 πŸ”₯

Component
FormΒ  β†’

Last updated 2 days ago

Created by

πŸ‡·πŸ‡ΊRussia IRuslan

Live updates comments and jobs are added and updated live.
  • Needs backport to D7

    After being applied to the 8.x branch, it should be considered for backport to the 7.x branch. Note: This tag should generally remain even after the backport has been written, approved, and committed.

  • Needs issue summary update

    Issue summaries save everyone time if they are kept up-to-date. See Update issue summary task instructions.

Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • The Needs Review Queue Bot β†’ tested this issue. It either no longer applies to Drupal core, or fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

    Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.

    Consult the Drupal Contributor Guide β†’ to find step-by-step guides for working with issues.

  • πŸ‡¨πŸ‡¦Canada nickdjm

    So I've been debugging this in 9.5.10 and none of the patches above seem to identify the triggering element properly.

    I tracked the issue down to the buttonWasClicked() method in FormBuilder. It specifically checks to see if the name and value of a button is found in the getUserInput() array, but buttons do not submit values. Their value is used as the text to display in the button, if if they are added to the getUserInput() array the value will be an empty string and never match to criteria for marking the button as clicked.

    I also noticed that the key for any button on the form will only show up in the getUserInput() array if it was the button used to actually trigger the form submission.

    I wrote a patch that adds another check to buttonWasClicked() that checks to see if a button's name is a key in the $input array, and if it is, it flags the button as the one that was clicked and results in the proper triggering element being flagged.

  • πŸ‡¨πŸ‡¦Canada nickdjm

    As a note: I know this needs some work, just wanted to get a patch posted to build upon.

  • πŸ‡¨πŸ‡¦Canada nickdjm

    I have updated the patch in 57 to fix an issue causing views apply/cancel/remove buttons to not submit properly.

    The AJAX call _was_ adding a value to the "op" input, so the logic I had in 57 was flawed. We should only assume the input was clicked if the value matches exactly or if the value is exactly empty. Anything other than those 2 outcomes means we can't assume that button was clicked.

  • πŸ‡¨πŸ‡¦Canada nickdjm

    Further testing of both my patch and the previous patch has revealed that properly identifying the clicked button works in some scenarios, but not others.

    In the case of my patch, it actually was breaking layout builder's submit buttons because they all have the same name- so disregard my patch.

  • πŸ‡ͺπŸ‡ΈSpain abelass

    Hi, is there a patch for d10 available?

  • last update 7 months ago
    Custom Commands Failed
Production build 0.71.5 2024