Problem/Motivation
In the media widget Views (both grid and table displays), I tried enabling the reset button option in the exposed form settings as this gives a better UX to content editors.
While enabling the option does show the reset button in the widget, clicking it redirects to /admin/content/media-widget/image?name=&sort_by=created&op=Reset with an "Access Denied" error.
I'm not sure if the root cause is the similar issue I found: https://www.drupal.org/project/drupal/issues/3346820 or if the media library widget has a bug itself causing the issue.
Steps to reproduce
- Go to:
/admin/structure/views/view/media_library/edit/widgetand enable the Reset button option in the exposed form settings. - Add a node or other entity that has a media reference field, with the form mode set to use the media library widget.
- In the media library widget filter the results in some way, this should then show the reset button.
- Click the reset button to reset the form filter options.
- You should be redirected to
/admin/content/media-widget/image?name=&sort_by=created&op=Resetwith an "Access Denied" error.
Proposed resolution
Fix bug so that the reset button on media library widget form correctly resets the form.
Remaining tasks
N/A
User interface changes
N/A
API changes
N/A
Data model changes
N/A
Release notes snippet
N/A
| Comment | File | Size | Author |
|---|---|---|---|
| #10 | ajax_not_working_on_reset.mp4 | 993.81 KB | anushrikumari |
| #2 | 3376978-evidence.gif | 5.27 MB | carolpettirossi |
| Screenshot 2023-07-25 at 10.41.22 PM.png | 20.55 KB | pcate | |
| Screenshot 2023-07-25 at 10.50.15 PM.png | 24.34 KB | pcate |
Issue fork drupal-3376978
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
Comment #2
carolpettirossi commentedI'm facing the exact same issue.
Comment #3
anybodySame issue here! It's even worse, all the values intered in the form behind the modal are then lost, as the page reloads!
Presumably this is kind of duplicate of this issue #3346820: On views with AJAX enabled, exposed filter "reset" causes (non-ajax) page load, but I think we should keep both open as this one shows how critical the result of the page reload can be!
Comment #5
bkosborneRan into this myself after adding the missing "reset" button for the filters. It's too bad, as it would really improve the UX if we could add the button, especially to reset the text filter.
Comment #6
aaron.ferris commentedI've also recently come across this. We've hidden the button if it can't be used in certain scenarios.
I wonder how complex the issues with the form reset are based on the comment in https://git.drupalcode.org/project/drupal/-/blob/11.x/core/modules/views... probably not trivial.
Comment #7
adwivedi008 commented@aaron.ferris I think hiding the reset button won't work.
In certain cases, we can hide it but from the user's perspective it would be not very clear if the button is visible at certain places and hidden from certain places
Comment #8
aaron.ferris commented@adwivedi008 - indeed, its not perfect, but ultimately preferable to a button that exists which completely breaks the journey.
Comment #9
joshua.boltz commentedI get it, this seems complicated, but seems like it lost traction. Has this moved into another issue?
Comment #10
anushrikumari commentedI was reviewing the behaviour in the modal and turns out that the reset does not trigger any AJAX, as it is happening for the Apply Filter button.
This issue is similar to the https://www.drupal.org/project/drupal/issues/3346820
Comment #11
anybodyToday we saw that now even the "Filter" button isn't AJAXified anymore in modals, and it's moved to the modal actions!
So currently the whole media selection is broken. Any idea?
Update: This patch was the reason: #2897377: $form['#attributes']['data-drupal-selector'] is set to a random value so can't be used for its intended purpose