Table drag row weight doesn't update when Choices.js is applied to select inputs

Created on 15 March 2023, over 1 year ago
Updated 17 March 2023, over 1 year ago

Problem/Motivation

Table drag functionality isn't updating the row weight on Choices.js select elements.

<!--break-->

Steps to reproduce

Choices configuration:

  1. Enable Choices Globally
  2. Apply Choices.js to all select elements - select
  3. Include Choices.js on every page

Go to edit the Main navigation with a few menu links. Drag a link above or below another link and save. The links will return to the original order.

The order can be adjusted by showing the row weights and changing the value on the select elements.

🐛 Bug report
Status

Fixed

Version

2.0

Component

Code

Created by

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @JamesPosko
  • 🇩🇪Germany Anybody Porta Westfalica

    Thanks @JamesPosko I can confirm that. Already ran into this myself.

    As it's Drupal-specific, we should exclude the selectors in the initialization generally. Could you provide a MR?

  • @anybody opened merge request.
  • 🇩🇪Germany Anybody Porta Westfalica

    Having a short look at the (hidden) fields at /admin/structure/types/manage/page/form-display I don't think it's the weight field, because that's (visible and hidden) always a text input. I think it's the parent field at least in that form.

    Looking at /admin/structure/menu/manage/main it's indeed the .menu-weight select.

    Let's filter out both and try if it works. Could you do that? Additionally a test for all such cases in core wouldn't be bad.

  • Status changed to Needs review over 1 year ago
  • 🇩🇪Germany Anybody Porta Westfalica
  • 🇩🇪Germany Anybody Porta Westfalica

    Any other selectors to consider?

    I also thought about using the name$=['weight'] (ends with) selector instead, but it's not as performant as class selectors. What do you think?

  • Wow! This is great! Thank you for the quick response.

    I was able to clone the repository and test the merge request changes. The merge request works great on the menu table drag elements.

    Thinking about your last question, I tested the update with Paragraphs and the table drag elements use a different class on these elements. This produces the same issue as before. So the name$=['weight'] (ends with) selector might be a better way to catch the various instances of elements with the table drag functionality. Or maybe a way to skip the select elements with a parent that has a class of .tabledrag-hide.

  • 🇩🇪Germany Anybody Porta Westfalica

    Thank you @JamesPosko! Could you try to change the exclude to

    .tabledrag-hide is not be as good, as it MIGHT be removed if the weight is shown? Or we could combine both.
    Could you give it a try perhaps? Or aren't you a developer?

  • Status changed to Needs work over 1 year ago
  • 🇩🇪Germany Anybody Porta Westfalica
  • I'll give adjusting the selectors a try locally and update the merge request. Thanks for collaborating on possible solutions.

  • I went with using select[data-drupal-selector$="weight"] because the name attribute had a few different version of ending with weight with square brackets. The classes on the select element are all different when table drag functionality is added. I attempted to use offsetParent but if the element or any ancestor has the display property set to none it will return null.

    I tested this on Paragraphs, menus, blocks, roles, and views rearrange table drag elements.

  • Status changed to RTBC over 1 year ago
  • 🇩🇪Germany Grevil

    @JamesPosko great work! Works as expected!

    Thanks for the quick implementation and review!

    RTBC!

  • Status changed to Fixed over 1 year ago
  • 🇩🇪Germany Grevil

    Fixed, created a new release 2.1.3!

    • Anybody committed 1ecd0e7f on 2.x
      Issue #3348196 by Anybody, JamesPosko, Grevil: Table drag row weight...
  • 🇩🇪Germany Anybody Porta Westfalica

    Thank you all! I now did the same for parent.

  • Status changed to Needs work over 1 year ago
  • Thank you @Anybody for the assistance and collaboration on this issue. Thank you @Grevil for reviewing and testing.

  • Status changed to Fixed over 1 year ago
  • Automatically closed - issue fixed for 2 weeks with no activity.

Production build 0.69.0 2024