Allow multiple field widgets to not use tabledrag

This is a feature request and would need to be applied to the next development version.

OK here is the first pass for 8.0.x b/c the feature was wanted for 8.0.x.

Will need to re-create for 8.1.x-dev and write tests.

Re-roll for latest release

Re-roll for latest.

Love the idea, let's see what the bot thinks of it.
We'll probably want a test for this.

Allowing fallback to orderable when a contrib module overrides the WidgetBase::formMultipleElements() method.

Upload the right one...

Run tests

Test errors are all/mostly coming from "orderable missing schema". Looks like field config schema needs updating.

Re-roll.

Config fixes, NR just to check.

Can't say I agree with the implementation, doesn't really fit with 'cardinality', 'revisionable', 'translatable'.
Feels like it could be simpler, contained within Drupal\Core\Field\WidgetBase and 'settings'. Thoughts ?

Seems AssertConfigTrait::assertConfigDiff() is order sensitive.
Still not ready, will make interdiff for green patch.

Should be green.

+++ b/core/modules/field_ui/src/Form/FieldConfigEditForm.php
@@ -71,6 +71,16 @@ public function form(array $form, FormStateInterface $form_state) {
+        '#description' => t('Orderable multiple fields widgets are in a table with drag and drop.'),

This should go through $this->t().

@Munavijayalakshmi: Thanks.
Adding screenshots.

I love the idea of this, but shouldn't this be a widget setting (as stated in the IS) rather than a field setting? I can imagine that sometimes for the a field I might want a simplified widget without ordering for everyday use, but in a more advanced administrator UI I might want to allow ordering. Worth discussing at least.

And if it is a field setting, I'd expect to find it next to the cardinality settings.

@jonathanshaw: the original issue was for 7.x and there is a widget patch buried with it so it might explain IS.
I'm not aware of any architectural reasons it is so low level and expressed similar opinion in #20.
So far just restored the functionality of the patch from #8, certainly needs some discussion and direction from field subsystem maintainers.

Alternative/simpler implementation attached, moved it to widget settings, no schema changes.
Doesn't cover file and image fields, neither did original.

Edit:
The reasoning behind moving it into widget settings was that I felt that placing it near cardinality (in storage settings) would imply something about the underlying storage: that you can't count on the order items will be returned from database.
What I needed though was purely visual/widget side ability to get rid of that horrid table on fields that don't need reordering.

Also, the drawback of this patch is that it relies on each widget calling its parent in ::settingsForm(), which will cause troubles with contrib (it falls back to non-orderable in those cases).

Initial pass for schema, also fixed settings summary for fields with cardinality = 1.

I really like this patch! It kinda works for me on a first test.

One thing I wonder: I have custom field type with multiple properties, and now I'm missing a wrapper around each item. What would be the best approach here?

I had a rant somewhere about there being no concept of a component in Drupal's markup (collection of widgets/elements acting together as a single input), it is visible in core especially around issues with date/date range modules.
For now in custom/complex/mixed field types I add inside FieldWidget::formElement() something like:

$element['#type'] = 'container';
$element['#theme_wrappers']['container'] = ['#attributes' => ['class' => 'container-inline']]; 

You can also use hook_field_widget_form_alter to do this.

I also have a newer version of the patch that supports file and image fields running on dev, but I'm spread a bit thin at the moment so not sure when I'll get back to this.

Thanks that sounds good. If you post the current version I could test it, maybe work on it at the sprint weekend...

Here is a change that makes the patch apply to 8.4.4.

@k4v: Thanks, I checked the code in dev, file/image is very 'raw' at the moment, need to refactor it before posting, will post in a day or two.

Didn't touch tests.

Some test fixes.

Should be green.

thank you!

@tacituseu , Thanks for the patch. But while applying patch#63 terminal shows following error:

error: patch failed: core/lib/Drupal/Core/Field/Plugin/Field/FieldWidget/BooleanCheckboxWidget.php:33
error: core/lib/Drupal/Core/Field/Plugin/Field/FieldWidget/BooleanCheckboxWidget.php: patch does not apply
error: patch failed: core/modules/comment/config/schema/comment.schema.yml:14
error: core/modules/comment/config/schema/comment.schema.yml: patch does not apply

@Mohit Malik: Couple of string/comment changing commits went in recently, as a feature request it is rolled for 8.5.x where it applies cleanly.

Updating IS with new settings screenshot.

Patch #63 works very well for me, would like to see this in core :).

This is a reroll for Drupal 8.5.4, I removed the test additions from the now deprected base class.

Reroll for 8.6.x

We need an update path to add the new setting to existing form display config entities.

There is a similar update in #2863188: Hardcoded result size limit in the entity reference autocomplete widget., which could be adjusted for the current issue. Additionally the Config Entity Updater should be used in the update - https://www.drupal.org/node/2949630 .

Just a small fix: The twig template was missing from the core/module/system/templates folder.

This patch is only for 8.5.x.

Updated for 8.6

Just changed the name of the Test core/modules/field/src/Tests/FormTest.php to /core/modules/field/tests/src/Functional/FormTest.php

Multi column fields look bad when the row separator is removed.

Rerolled (should apply clearly to 8.8.0-beta1)

#85 has wrong end of file

Trying to fix some test failures

Thank you for all your work.
It's impressive how such a "small" feature means such an effort and over such a long period.

"Best" workaround that works for me:

/**
 * Implements hook_preprocess_HOOK().
 */
function THEMENAME_preprocess_field_multiple_value_form(&$vars) {
  // Remove tabledrag option for multivalue fields.
  if (isset($vars['table']['#tabledrag'])) {
    unset($vars['table']['#tabledrag']);
    array_pop($vars['table']['#header']);
    foreach ($vars['table']['#rows'] as &$row) {
      foreach ($row['data'] as $key => $rowrowdata) {
        if (!$rowrowdata['data']) {
          unset($row['data'][$key]);
        }
      }
    }
  }
}

Credit to: http://www.intheloftstudios.com/blog/remove-tabledrag-field-drupal-using...

The patch still applies cleanly to 8.9.x, however it needs work to run on 9.0.x and 9.1.x , some of the test files have moved around.

We need this for WCAG compliance, the tabledrag has a link that is empty and wcag flags this as an issue.

So I'm looking at this patch because I want to disable tabledrag on a multifield fieldset.

Reroll the patch for D9, will work on test cases.

The patch #94 no longer to appled. so I have re-roll the patch for D9.

Just want to share some love to the ones in this thread, I love you all 😂

Resolving failed test cases from #97

#37 says:
the drawback of this patch is that it relies on each widget calling its parent in ::settingsForm(), which will cause troubles with contrib (it falls back to non-orderable in those cases).

We should fall back to orderable for backwards compatibility.

Also we need an upgrade path per #74.

I do wonder whether we should split the issue. Add the theme component in one issue, then make it the default for all widgets in another (tricky!) issue.

reroll

I moved the latest patch to an issue fork and added support for the #description_display. I also removed the

element wrapping the label, I don't see why that one is needed. Finally, I added a copy of the template to Claro with the new description class.

Applied patch #105 on 9.2.x and it works fine.The orderable checkbox is displayed in the display settings after applying this patch.Also the functionality is working fine.

Before patch;

After patch:

RTBC +1

#105 Patch fails to apply on 8.9.13, had to go back to #87 which worked.

I patch manually and not going to attempt this one. I'll have to wait for it in a release. Meanwhile I'm using this. Throw it into your browser inspector and see if it does the job.

form tr td {
     padding: 4px 0;
}
.node-form .field-multiple-drag a,
.tabledrag-toggle-weight-wrapper,
.node-form .draggable a.tabledrag-handle {
    display: none !important;
}

The snippet from the external link (with a slight modification) at #89 works for me, thanks @handkerchief! There is, however, a small problem: all draggable tables in multi-value fields (even nested under paragraphs) are removed. For a selective removal, I modified it like this:

function THEMENAME_preprocess_field_multiple_value_form(&$vars) {
  $element = $vars['element'];
  if ($element['#field_name'] == 'field_my_field' && isset($vars['table']['#tabledrag'])) {
    unset($vars['table']['#tabledrag']);
    array_pop($vars['table']['#header']);
    foreach ($vars['table']['#rows'] as &$row) {
      foreach (array_keys($row['data']) as $key) {
        if (array_intersect($row['data'][$key]['class'] ?? [], [
          'field-multiple-drag',
          'delta-order',
        ])) {
          unset($row['data'][$key]);
        }  
      }
    }
  }
}

I just simply pulled the patch from the latest merge request which seems to be applying alright to 9.2.4.

Running a test against 9.3.x

I updated the MR and merged in 9.3.x but not sure how I can change the MR target. I don't seem to have permissions to do that. In hindsight, I think only the creator of the MR can do that, so sorry about that. @Pasqualle could you maybe update the target branch?

Attached is a 9.3.x patch as well.

@seanB: I think Gitlab / d.o integration is smoother if you rebase MRs against the target branch, instead of merging back into the fork. That's why this issue is now very hard to read with what Gitlab is saying between #116 and #117. There's always a tag saved on every force push to git.d.o, so we always have the full history.

Thanks,
-Derek

p.s. Yes, there's sadly no way for most contributors to update Gitlab MR metadata, including changing the target branch or resolving threads. That requires the author of the MR or one of the core committers. We are at least discussing this as part of the Gitlab acceleration initiative, but it's not yet clear if we can do anything about it.

Yeah, sorry about that, probably should have created a new MR for 9.3. Any suggestions on what I can do to fix this particular MR and undo the mess I created?

+1

Changed the target branch and hard reset (with force push) to the commit mentioned in comment #107
The diff seems to be ok-ish.
https://git.drupalcode.org/project/drupal/-/merge_requests/450/diffs

Need manual rebase and conflict fix.

Not sure about the MR history, if it will create any issue when merged.

Created new branch and MR against D10.1

Todo: There are 2 new themes in D10: olivero and starterkit_theme where the new template file should be added.

Rebased both MR for 9.5.x and 10.1.x.

Remaining tasks:

- Add tests
- Add template file for olivero
- Add template file for starterkit_theme

Attached is the patch version of MR 450 for those working with composer patches.

Hi @anneke_vde
You can access the composer patch you need for an MR by visiting the changes tab and adding “.diff” or “.patch” to the end of the url: https://git.drupalcode.org/project/drupal/-/merge_requests/2851/diffs.diff

Edit: It has been rightly pointed out this isn't a reliable URL to add to composer patches, and would need downloading and storing instead. Whereas patch files are consistent and reliable to use as a composer patches URL if using that method.

@Driskell: the .diff url is very practical, but I think it'll return a different diff as the MR gets commits pushed. In order to ensure a build doesn't end up having code you didn't properly test/review, it's better to have an actual patch file.

@jedihe Ah quite right! I see now, thanks. I normally download the patch and commit it and hadn't considered that approach of direct URL. I'll edit my comment to clarify in case others see it.

Thanx for the clarification, that was indeed the reason why I uploaded the patch file.

Added a rebase removing the template for "stable" (only stable9 remains in D10) and an attempt at fixing the failing test from last run.

Only did it for 10.1.x since is the only branch that is receiving features now.

Another thing the proposed code is not handling is the existing widgets that will be rendered as non-orderable after the change.
I found this change
https://git.drupalcode.org/project/drupal/-/commit/2c3f5743df1dc19515258...
That sets the tooltip as a mandatory setting for Drupal 11.
We should something similar here:

• Treat non-configured widgets (orderable is null) as orderable
• Add a entity presave that adds the default settings

Since there is no layout builder for forms modes there is no need for a hook_post_update.

Seems that patch does not apply to D10.2

I confirm, patch is not applicable to 10.2

The patch did not apply on 10.2 because the field.widget.settings.language_select are moved from language.schema.yml to core.entity.schema.yml.

Here is a patch that does apply to 10.2

Thanks @Wilfred Waltman , applies now perfectly

Confirming #141 patch works for

• Drupal 10.2.6
• PHP 8.2.12

The patch from #141 works well for me on Drupal 10.2.7 and PHP 8.2.12. I have extended the patch to only build the _weight field when "orderable" is set to TRUE.

My last patch missed the template /core/modules/system/templates/field-multiple-value-without-order-form.html.twig so this one adds that in

Here's the patch for the merge request https://git.drupalcode.org/project/drupal/-/merge_requests/11595

Reroll for branch 10.5.x.

The patch in #150 unfortunately resolves the merge conflict between this patch and D10.5 incorrectly. The conflict is that the FileWidget settingform introduces a warning if the upload progress PHP extension is not available. The patch in #150 removes that again.

Here is a patch for D10.5 that retains the notice.

Patch #152 appears to be working well for Drupal 10.5.1 so far.

Patch #152 working for me too.

Rerolled the patch from #149 to work with latest 11.3. New MR at https://git.drupalcode.org/project/drupal/-/merge_requests/14184.patch and attached is the patch file.

Good feature. I’ve always found it strange that tabledrag was required.

Even when there are zero items and nothing to reorder, tabledrag is still present. See screenshot. Why show it until you can actually reorder something? Fixing that might be beyond the scope of this issue, but figured I'd mention it here.