Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Problem/Motivation
With a large number of fields on the Manage Display page and when moving fields to the Disabled section sometimes it jumps to the bottom and changes are lost.
Since each of these operations requires a backend ajax call there is a potential that if the user proceeds to select and move multiple fields that their work will be overwritten by the ajax response.
Steps to reproduce
- Use a slow connection. This will not be obvious on a typical local dev setup.
- Create a large quantity of fields (over 20)
- Edit the default managed display and proceed to move multiple fields into the Disabled grouping
Proposed resolution
N/A
Remaining tasks
N/A
User interface changes
- Would it possible to include a button to move all fields to the disabled section, rather than piecemeal. There will be many sites that have more than a few fields. A normal site builder with multiple fields would have to move all fields individually (in our case it's 20+) by hand, while waiting to make sure that the ajax callback is completed -- which isn't always obvious to a normal site builder. A dev might be able to look at the chrome dev tools network tab but that is out of the question for a normal site builder.
- For moving fields between Groupings 'Field', 'Disabled' don't require an ajax call. When adjusting 'Labels' and 'Format' it makes sense to require the ajax call for obvious reasons. Question: I wonder how fieldgroups and other other custom functionality would be affected by this.
- Disable drag and drip while Ajax is running
API changes
N/A
Data model changes
N/A
Release notes snippet
Original report by generalconsensus
I've attached gif videos showing our basic demo site running with multiple fields in which you can clearly see the ajax call and the 'lag behind' of the callback and the ux issue.
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | lag_behind_display_field_move_2.gif | 3.04 MB | generalconsensus |
| lag_behind_display_field_move.gif | 5.08 MB | generalconsensus |
Issue fork drupal-2741387
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:
changes
Comments
Comment #2
generalconsensus CreditAttribution: generalconsensus at Forum One commentedComment #3
generalconsensus CreditAttribution: generalconsensus at Forum One commentedComment #4
generalconsensus CreditAttribution: generalconsensus at Forum One commentedComment #11
Amber Himes MatzThank you for the report and for providing steps to reproduce and even a gif of the problem in action! We triaged this as part of the Bug Smash Initiative. Because there's been no activity for many years, this issue needs to be re-verified on a currently supported version of Drupal with some manual testing.
Comment #12
quietone CreditAttribution: quietone at PreviousNext commentedFurther discussion and testing shows that this is reproducible when the connection is slow. For example, I was able to reproduce this with simplytestme but not my local ddev environment. We (Amber Himes Matz, larowlan and myself) agree that this can be a feature request. I am updating the issue meta and summary accordingly.
Comment #13
quietone CreditAttribution: quietone at PreviousNext commentedImprove the problem/motivation.
Comment #16
bnjmnmThis disables drag handles while Ajax is in progress. Maybe there's something more elegant like queueing the drags but this approach will work.
This is probably better categorized as "needs architectural review" - not every theme is accounted for among other things. Test this in Claro. There should be some eyes on this before the full gate-appeasing MR is fleshed out.
There's no test coverage, but since this is timing related I'm not sure if that's an option. Perhaps
hold_test_responsecould be used?Comment #17
smustgrave CreditAttribution: smustgrave at Mobomo commentedSeems to have a build error.
Will this require tests?