Not working with Group By feature

This is because function getHtmlId() returning same table ids for all tables:

in DraggableViewsField.php

    if (\Drupal::currentUser()->hasPermission('access draggableviews')) {
      $options = [
        'table_id' => $draggableviews->getHtmlId(),
        'action' => 'match',
        'relationship' => 'parent',
        'group' => 'draggableviews-parent',
        'subgroup' => 'draggableviews-parent',
        'source' => 'draggableviews-id'
      ];
      drupal_attach_tabledrag($form, $options);
    }

and
In function draggableviews_preprocess_views_view_table(&$variables)

  // Add table attributes.
  $variables['attributes']['id'] = $draggableviews->getHtmlId();

we are using getHtmlId()

  public function getHtmlId() {
    return Html::getId('draggableviews-table-' . $this->view->id() . '-' . $this->view->current_display);
  }

and while we are using groupby as your attached screenshot , it will add multiple tables on page

I created a patch and please check and let me know if helps. Thanks

#3 is works fine. Thanks!

So the patch fixes the look of Group By but does not fix the functionality of it. If you are grouping by tags and an entity is in multiple groups then the last time it get list will be the value.

Group #1
Node 1 (0)
Node 2 (0)
Node 3 (0)

Group #2
Node 5 (0)
Node 2 (0)

Will result in Node 2 getting value 4. (5 items, so values are 0,1,2,3,4)

Group #1
Node 1 (0)
Node 2 (4)
Node 3 (2)

Group #2
Node 5 (3)
Node 2 (4)

The current code saves Node 2 to the database as a weight of 1, then it resaves it with a weight of 4.

Re-roll patch attached

Re-roll patch attached.

The patch in #6 worked for me.

The patch in #6 didn't work for me.

Fatal error: Maximum function nesting level of '256' reached, aborting! in /var/beetbox/modules/contrib/draggableviews/src/DraggableViews.php on line 33
Call Stack
#	Time	Memory	Function	Location
1	0.0077	244736	{main}( )	.../index.php:0
2	0.0770	635576	Drupal\Core\DrupalKernel->handle( ???, ???, ??? )	.../index.php:19
3	0.0892	1791520	Stack\StackedHttpKernel->handle( ???, ???, ??? )	.../DrupalKernel.php:657
4	0.0892	1791632	Drupal\Core\StackMiddleware\NegotiationMiddleware->handle( ???, ???, ??? )	.../StackedHttpKernel.php:23
5	0.0893	1791944	Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle( ???, ???, ??? )	.../NegotiationMiddleware.php:50
6	0.0893	1792376	Drupal\page_cache\StackMiddleware\PageCache->handle( ???, ???, ??? )	.../ReverseProxyMiddleware.php:47
7	0.0897	1800408	Drupal\page_cache\StackMiddleware\PageCache->pass( ???, ???, ??? )	.../PageCache.php:78
8	0.0897	1800488	Drupal\Core\StackMiddleware\KernelPreHandle->handle( ???, ???, ??? )	.../PageCache.php:99
9	0.0957	2097776	Drupal\Core\StackMiddleware\Session->handle( ???, ???, ??? )	.../KernelPreHandle.php:47
10	0.0983	2250352	Symfony\Component\HttpKernel\HttpKernel->handle( ???, ???, ??? )	.../Session.php:57
11	0.0984	2251288	Symfony\Component\HttpKernel\HttpKernel->handleRaw( ???, ??? )	.../HttpKernel.php:68
12	0.1430	4880784	Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch( ???, ??? )	.../HttpKernel.php:158
13	0.1441	4921552	Drupal\Core\EventSubscriber\MainContentViewSubscriber->onViewRenderArray( ???, ???, ??? )	.../ContainerAwareEventDispatcher.php:108
14	0.1446	4957072	Drupal\Core\Render\MainContent\HtmlRenderer->renderResponse( ???, ???, ??? )	.../MainContentViewSubscriber.php:90
15	0.1446	4957488	Drupal\Core\Render\MainContent\HtmlRenderer->prepare( ???, ???, ??? )	.../HtmlRenderer.php:117
16	0.1447	4975408	Drupal\Core\Render\Renderer->executeInRenderContext( ???, ??? )	.../HtmlRenderer.php:227
17	0.1448	4975464	Drupal\Core\Render\MainContent\HtmlRenderer->Drupal\Core\Render\MainContent\{closure}( )	.../Renderer.php:582
18	0.1448	4976192	Drupal\Core\Render\Renderer->render( ???, ??? )	.../HtmlRenderer.php:226
19	0.1448	4977096	Drupal\Core\Render\Renderer->doRender( ???, ??? )	.../Renderer.php:195
20	1.9432	25725880	Drupal\Core\Render\Renderer->doRender( ???, ??? )	.../Renderer.php:450
21	1.9725	26286760	Drupal\Core\Theme\ThemeManager->render( ???, ??? )	.../Renderer.php:437
22	1.9738	26295128	twig_render_template( ???, ??? )	.../ThemeManager.php:384
23	1.9753	26308344	Twig_Template->render( ??? )	.../twig.engine:64
24	1.9753	26325072	Twig_Template->display( ???, ??? )	.../Template.php:411
25	1.9753	26325536	Twig_Template->displayWithErrorHandling( ???, ??? )	.../Template.php:403
26	1.9753	26326736	__TwigTemplate_0b39505df84b691c5a3640573ee0790767231d2654971965753660bef51abd95->doDisplay( ???, ??? )	.../Template.php:432
27	2.0044	26456448	Drupal\Core\Template\TwigExtension->escapeFilter( ???, ???, ???, ???, ??? )	.../iea7nWHuMTZsyfxSLrw5nbN7w8NOITMVa7-bEmLmZSs.php:114
28	2.0044	26460304	Drupal\Core\Render\Renderer->render( ???, ??? )	.../TwigExtension.php:490
29	2.0044	26460352	Drupal\Core\Render\Renderer->doRender( ???, ??? )	.../Renderer.php:195
30	2.0045	26465160	call_user_func:{/var/beetbox/core/lib/Drupal/Core/Render/Renderer.php:378} ( ???, ??? )	.../Renderer.php:378
31	2.0045	26465328	views_pre_render_views_form_views_form( ??? )	.../Renderer.php:378
32	2.0858	26984128	Drupal\Core\Render\Renderer->render( ???, ??? )	.../views.module:655
33	2.0858	26984176	Drupal\Core\Render\Renderer->doRender( ???, ??? )	.../Renderer.php:195
34	2.0859	26989264	Drupal\Core\Render\Renderer->doRender( ???, ??? )	.../Renderer.php:450
35	2.0859	26993712	Drupal\Core\Theme\ThemeManager->render( ???, ??? )	.../Renderer.php:437
36	2.1072	27516456	draggableviews_preprocess_views_view_table( ???, ???, ??? )	.../ThemeManager.php:287
37	2.1099	27541536	Drupal\draggableviews\DraggableViews->getDepth( ??? )	.../draggableviews.module:108
38	2.1099	27541608	Drupal\draggableviews\DraggableViews->getDepth( ??? )	.../DraggableViews.php:51
39	2.1099	27541608	Drupal\draggableviews\DraggableViews->getDepth( ??? )	.../DraggableViews.php:51
...

@mediabounds, you don't move something to RBTC when I clearly stated it needs work and the reason.

Sorry!

Sorry, but exception I posted before is caused not by your patch (#6) but due to current module implementation - in other words I get the same exception even without your patch being applied. For some reason entity parent id is persisted, even I'm not constructing a tree of descendants, where on stable branch it'd stay "flat" 0.

Reapplied patch for version 8.x-1.0

Sorry, wrong file on comment #12

Updated patch in #13 to remove any extra markup that may be on the title value (like in the case theme debugging is on).

Oops, uploaded the wrong patch in #14

Thanks everyone for your work on this.

The patch doesn't seem to apply correctly to 8.x-1.x-dev. Also some coding standard stuff needs work:

1. +++ b/draggableviews.module
   @@ -84,8 +84,15 @@ function draggableviews_preprocess_views_view_table(&$variables) {
   +	  // Add table attributes.
   +	  $variables['attributes']['id'] = $draggableviews->getHtmlId($key);
   +	}
   

   Use spaces instead of tabs.

2. +++ b/src/DraggableViews.php
   @@ -79,10 +79,21 @@ class DraggableViews {
   +	$sets = $this->view->style_plugin->renderGrouping($this->view->result, $this->view->style_plugin->options['grouping'], FALSE);
   +	foreach ($sets as $title => $rows) {
   +	  $fieldGrouping[] = $title;
   +	}
   +	return $fieldGrouping;
   +  }
   

   Use spaces instead of tabs.

3. +++ b/src/Plugin/views/field/DraggableViewsField.php
   @@ -74,16 +74,21 @@ class DraggableViewsField extends BulkForm {
   +    // get array of field group title
   

   Comments start with a capital letter, end with a period.

4. +++ b/src/Plugin/views/field/DraggableViewsField.php
   @@ -74,16 +74,21 @@ class DraggableViewsField extends BulkForm {
   +          'source' => 'draggableviews-id'
   

   Missing trailing comma.

Here's an attempt at an improved patch. It works for me :-)

A small improvement on top of #17. We don't need to check access inside the foreach loop, it's more efficient outside of the loop.

Small fix for an undefined variable error when the view has returns no results.

Good catch John, thanks! Maybe if you have some time, you could also have a look at #2980508: Twig debug mode breaks draggable view, which may be related to this issue.

#19 is working for me.

Marc, the issue definitely surrounds all of the html comment code in each variable. Unfortunately, didn't have time to dig into that quite yet.

I was having an issue where the crossbars would disappear seemingly randomly. I noticed the fieldGroups array was returning empty even though I had field groups set up. This patch seemed to fix the issue.

Fixed the issue with draggableviews working with fieldgroups while in Twig debug mode here. Just need to apply one more striptags filter to the conditional.

One more time - forgot to remove the dump().

Is it just me, or does the last patch ONLY work if you have grouped content? Like, if my content isn't grouped, I don't see the ability to rearrange anymore. (I do have twig debug mode on.)

There's also a warning:

Undefined index: in web/modules/contrib/draggableviews/src/DraggableViews.php on line 82

Taking out that line that's throwing the warning seems to fix not-grouped views as well.

It worth mentioning that #26 works only for a single-level grouping. Adding another level of grouping does not work as this patch does not handle the "deepest" group but rather uses the top-most. I'm looking into the patch for this.

Attached patch works with unlimited number of groupings. See interdiff for changes since #26.

Also, this patch cleanly applies together with https://www.drupal.org/project/draggableviews/issues/2767437 (Allow sort handler to select the view that stored the order).

I couldn't get patch #30 to apply to the dev version until I removed hunks 2 & 3 for draggableviews.module. I then couldn't get the patch to work with groupings three deep. Is there any special configuration required?

@PapaGrande, there has been a few commits to dev since 5 months ago, so its understandable that the patch might need to re-rolled.

I never heard of anyone grouping 3 deep, you might be the only one (not saying that's a bad thing, just unique).

Let's try this again - needed to correct a small error in the reroll.

This is not working for me, since my grouping field is a taxonomy term associated to the node.

Debugging the patch i can see that the fieldGrouping() function is returning an indexed array of ids, which are the target_ids of the terms. So this does not work with the condition added in draggableviews_preprocess_views_view_table :

if (trim(strip_tags($variables['title'])) == trim(strip_tags($row)))

I guess we should check wether the field is a direct child of the entity or if it is from a referenced entity, not sure how to do this properly though...

#36 worked for me. The field I'm grouping by is a taxonomy reference field. My site is currently on D8.9.0.

This patch was not applying for me on 1.x-dev and core 8.9.1. Here is a re-roll.

Whoops, let's try that once more.

I'm running 8.9.1 with the latest 1.x-dev, and I have a grouped view where I am displaying Resource page nodes, and I'm grouping by their node reference field (Topic page). My presentation view display also uses a Contextual filter to make this work.

I was unable to get patch in #40 working for my situation. I was also unable to apply patches from #39, #36. As the screenshot in #30 seemed very similar to my use case, I looked at the date that was posted (19 Jul 2019) and attempted to recreate the same conditions by targetting the same commit that Alex would have used (2f9716 from 1 Feb 2019).

In case you're interested, this is 7 commits behind the latest one on 1.x-dev.
To do this I ran the command `composer require drupal/draggableviews:1.x-dev#2f9716`

I then applied the patch from #30, and am very happy to confirm it's working nicely.

I would suggest that we re-roll the latest patch to incorporate whatever #30 has that #40 doesn't (node reference grouping with contextual filter)

Sorting view page

Views UI - Sort display

Views UI - Presentation display

.

You might also require this patch first:
#3153830-8: DraggableViews not working after update to 2.0.0

with both patches, it seemed to work ok

however my use case is a bit unique so I won't be able to use this module for this case, great module though, thanks.

Thanks for testing this too Joseph!
Just a note, I believe you're using 2.0.0 / 2.0.x-dev of the module based on the link to the patch you posted and this issue is specifically for 1.x-dev.

This may help explain the difference between me not being successful in getting the patch to apply on the latest 1.x-dev, but you being successful with 2.0.x-dev. But glad to hear you've got it working.

I am using latest version: 'draggableviews 2.0.0' But am not get draggable based on category.

#3 patch work for me

I have upgraded to draggableViews 2.0.0 thinking it would solve this issue. Found this thread, tried to apply this patch + the patch Joseph posted on #43 but that didn't work unfortunately. So I've downgraded to 1.x-dev, applied the patch from #40 and I still have the same issue...

I'm on 8.9.9 and I have a table grouped by 2 taxonomies. The first table gets rendered fine and has the handles showing, all the tables that follow have the row weight column instead. It's like tabledrag can't find all the tables to add 'tabledrag-hide' class to them. Attached a screenshot to show what I mean, I had exact same results with 2.0.0 and the patches mentioned, but then I also had duplicates showing...

Update: Removed one of the grouping and the issue indeed got resolved (patch #40 and 1.x-dev). So prob the issue now is when you have more than one grouping.
Update 2: Decided to upgrade to 2.0.0 again, and I have the same results than 1.x-dev. It works with the patch and 1 grouping, if I add a second grouping to the table, it breaks.

I ended up using the Drupal api to make a draggable table.

Using #tabledrag , see how-to on https://drupalize.me/tutorial/output-table?p=2766

core sorting, example: https://drupal.stackexchange.com/questions/259095/specify-default-sort-h...

these two references helped me out a lot I have a nice drag and drop table of items using out of the box core drupal apis.

Recreated patch on 2.0.x branch

+1 RTBC

Patch #48 is working for me without problems with 2.0.2-rc1 (Drupal 9.2.10)

the related issue was marked as fixed, this patch is still needed.

Just as an information, in case s.o. still has problems. After rendering the view I used for #49 with the existing frontend-theme it was broken again. When rendering the view 'Bartik' it was correct again. So I don't think this is a problem of this module, but of the theme. I'll pass this to our FE-team, or leave it as it is, as it's only about the colored headline, which is a nice-to-have .

I don't think that this is theme related. I tested this patch and initially it didn't work for me (Drupal 9.3.13). I used 3 themes: claro, seven and bartik.

My view was configured to display the sticky property for nodes as first column in the table. This was generating this warning:
Message Warning: Trying to access array offset on value of type null in draggableviews_preprocess_views_view_table() (line 107 [...]

But if I move the title before the sticky, then it's working fine on all themes.

Added a setting within Draggableviews:Content to enable/disable hierarchy

Added a setting within Draggableviews:Content to enable/disable hierarchy

#54 isn't really working for me. I have a taxonomy with hierarchy where a parent's children may have the same labeling as another parent's children (e.g., Term A > Financial, Term B > Financial). They get their own tables appropriately, but they don't consistently get the draggable crosshairs. I think it looks like the second table with the duplicate labeling is the one that doesn't get the draggable options.

See next comment

I found an issue with the patches when table titles were not unique. Tables with the same title inside the same view get the same HTML ID. Because of this, the tabledrag JS is not applied properly.

In my case, I was using 2 group by clauses - by primary category and secondary category. With the secondary category usually empty, I had many subtables with an empty table title (title = ""), and all of them had the same ID.

I'm not sure how this should be fixed. I've attached a patch that extends #54 which works for me, but it's not a very clean one.

Patch #48 worked for me on version 2.1.3 of the module

Patch #48 worked for me on version 2.1.3 of the module also.
Thank you

just found out - if you add new node (if there is group by)...it will create a temporary table until anyone click SAVE Order.
so this is not good I would say.

Patch #54 worked for me on version 2.1.3

Well, it seems #54 can't be applied to 2.1.x anymore.
So here is a re-roll of it for 2.1.x.

As the module moved to 2.x and the patches also, lets set that in the version of this issue report also.
FYI: I did not test the functionality so can't confirm this works and you should read previous comments.

This patch is not working for me, I am grouping by taxonomy terms and loading it through a relationship.

I was able to reproduce the problem, and verify that the patch in #63 resolved the issue. I tested with a list field, with a taxonomy reference field (displaying as a label), and I also verified that this module still worked with an ungrouped view after patching. Merged in, so that simple use cases can be resolved.

@nicxvan Yours sounds like a most complex use case, so please file a separate issue for that, including detailed steps to reproduce.

Looks like this was committed as of June 1, 2024. Could someone confirm?

This is already marked fixed.

The commit was actually May 28th, but it's in 2.1.4 which was released on June 1st.

Is there a specific issue you're having?

No, just double checking to make sure the patch is now obsolete.