We just updated the DraggableViews from 8.x-1.2 to 2.0.0. We are using Drupal 8. On 8.x-1.2 everything was working.

When changing the order on the View that has the order in it, the order in the database is changed and the order on this View is also changed, but the order on the View that is displayed on the Frontend it's incorrect (the same View is incorrect also on tha admin pages, not just Frotnend).
When downgrading to 8.x-1.2, everything works again.

Comments

joco_sp created an issue. See original summary.

sumit.prajapati’s picture

Yes, We are facing the same issue but in 8.x-1.2 we were getting duplicate nodes after adding distinct and aggregation use. its resolved on 2.0.

joco_sp’s picture

sumit.prajapati your issue is something else.

alexpertsi’s picture

Draggable views 2.0.0 also not working on Drupal 9.0.1 (+9.0.0) (PHP 7.3.19, 10.3.23-MariaDB)

jddh’s picture

Same here on Core 8.9.1

istryker’s picture

Please test the latest 8.x-1.x-dev branch as it should be the same as 2.0.0

cebronix’s picture

Tried on the 8.x-1.x-dev branch as well. Same results. No sorting.

sumit.prajapati’s picture

StatusFileSize
new507 bytes

Created a patch and tested:

Drupal Version: 8.8.6
DraggableViews Version: 2.0.0

cebronix’s picture

Confirmed the patch fixes the sorting issue but now the duplicates are back. 8.9.1 using 2.0

istryker’s picture

Thanks for the update. I guess removing that code woulf break something, as I remeber the code being added for a reason. If you guys fix this then I am more than happen to push it up right away. For now I do not have time to investigate this problem for a few weeks

getekid’s picture

I tried 2.0.0 today for a client's website and the patch fixed the issue.

Regarding of weather it would break something or not, I did some backtracking and I found that that segment of the code was added under issue 3089597 to address the problem with duplicate rows in the draggable page. I believe that adding view_display in the query is the reason the sorting filters for other displays break, because when loading another display it will look for that one in the DB and therefore return no results. If e.g. I have two displays "page_listing" and "page_draggable" (the later obviously for setting the ordering) then the table will store "page_draggable" in the view_display column while when loading "page_listing" the $view->current_display row in the query will return "page_listing" and therefore not find any results.

From another perspective, since this module expects only one "draggable" display from a View and that display name is stored in the DB table, therefore it is redundant to query more than the view_name (and arguments) since any other display should draw data from that.

I can try and do some more robust testing in the next days, but looking at the code and the results I got I believe patch in #8 is legit.

chandeepkhosa’s picture

Status: Active » Reviewed & tested by the community
StatusFileSize
new99.38 KB
new101.75 KB
new98.89 KB
new42.87 KB

I installed the 2.0.0 version of the module today on my Drupal 8.9.1 site and confirm that the sort order wasn't applying. After applying the patch in #8 it is now working perfectly. This was tested successfully on a view that has 2 displays - a sort page & presentation block.

Sort page - Views UI
Sort page - Views UI

Sort page - Display
Sort page - Display

Presentation block - Views UI
Presentation block - Views UI

Presentation block - Display
Presentation block - Display

nicoleannevella’s picture

The patch in #8 worked for me, but not on a display with contextual filters.

Drupal 9
Views 2

I have a two Block Views, a Page View (unordered) that uses a contextual filter from the URL (term name), and a Page View (table) thats used for sorting.

At first, I only had the two blocks and the sorting table. Applied patch #8 and it fixed the problem of weight not being saved/stored. I added a page view with contextual filter, and that page is not sorting properly while the other three are. I fiddled around with the settings in the contextual filter and relationship and did get it to sort properly in the Display section beneath the Views UI, but when viewed in the actual page display, the sort of the draggable weight is not being obeyed. Which is weird to me how the sort in my views display can be different than the sort in the actual page display.

jsutta’s picture

The patch in #8 works for me as well on D8.9.2.

I'm not noticing any duplication, but that wasn't happening before the patch either on my site.

daniel korte’s picture

@nicoleannevella Contextual filters are broken by #2903567: Args not working which requires a hook in order to restore the old functionality of using a single ordering for all contextual argument scenarios (no contextual filters applied and with contextual filters applied). Using the following hook would ignore per argument ordering and restore the previous behavior:

function MY_MODULE_draggableviews_join_withargs_alter(array &$view_args, $context) {
  $view_args = [];
}
devad’s picture

Patch #8 didn't fix this issue in my case.

D8.9.0
DW2.0.0

My draggable view to sort nodes (with draggableviews content field) works nice.

However, at homepage view an attempt to sort nodes by DraggableViews weight "Sort Criteria" does not work because the DraggableViews weight field value inside view is always zero.

My homepage view does not have Contextual filters.

draggableviews_structure table looks good. The weight field is properly filled with proper values. They are not all zeros.

Before DW2.0.0 upgrade everything worked well.

devad’s picture

Here are two dblog errors which appeared during previously mentioned view build. They might be connected to something else but posting here just in case.

Location:	/admin/structure/views/ajax/handler/proba_08/page_1/field/draggableviews?_wrapper_format=drupal_ajax
Referrer: 	/admin/structure/views/view/proba_08
Message: 	Warning: array_filter() expects parameter 1 to be array, null given in Drupal\views\Plugin\views\field\BulkForm->validateOptionsForm() (line 263 of /home/mysite/public_html/core/modules/views/src/Plugin/views/field/BulkForm.php)
Location: 	/admin/structure/views/ajax/handler/proba_08/page_1/field/draggableviews?_wrapper_format=drupal_ajax
Referrer: 	/admin/structure/views/view/proba_08
Message: 	Warning: array_values() expects parameter 1 to be array, null given in Drupal\views\Plugin\views\field\BulkForm->validateOptionsForm() (line 263 of /home/mysite/public_html/core/modules/views/src/Plugin/views/field/BulkForm.php)
caspervoogt’s picture

#8 solved it for me. I did notice some oddness when dragging an item to the last position; it would frequently not save it in the right order, but would show it as second to last. I even displayed row weights to confirm each item had a different weight, and they did, but it still would save it in the wrong order. Only by dragging the last item up and down, and then dragging the other item to the very bottom did it save the order correctly. Not intuitive. Just FYI.

sumit.prajapati’s picture

@devad
Have you tried with new draggableviews views, if not then please try then check same issue are getting or not.

devad’s picture

devad’s picture

deleted

devad’s picture

deleted

devad’s picture

Sorry for empty posts... I have accidentally opened this issue in IE11 browser and it posted few empty ones.

Re:#19
Both existing views and new added views which are set to sort nodes by DraggableViews weight "Sort Criteria" are broken after v2.0.0 update.

zanvidmar’s picture

This patch fixed my issue however I used combination of some other pathces + hook update. I can confirm that contextual filters are working in my case now. This is not entirely related to this issue but I am posting my situation and solution here for anyone with similar issues and to point out that this patch alone will not solve all the issues.

I am using draggableviews 2.0.0

This are all my patches (composer.json):

"DraggableViews displays multiple node instances when used in multiple views => https://www.drupal.org/project/draggableviews/issues/2867159": "https://www.drupal.org/files/issues/2020-06-22/draggableviews_displays-2867159-51.patch",
"DraggableViews not working after update to 2.0.0 => https://www.drupal.org/project/draggableviews/issues/3153830#comment-13722121": "https://www.drupal.org/files/issues/2020-06-26/draggableviews-sorting-issue-for-2.0.patch",
"If you have two instances of same view (id and display) on same page, with different arguments, draggable function does not work because html id is identical. This patch is fixing that issue. => https://www.drupal.org/project/draggableviews/issues/2903567#comment-13283192": "https://www.drupal.org/files/issues/2019-10-03/set-arguments-as-part-of-draggable-view-id--no-index--2903567.patch"

Because previously I used "Args not working patch" (patch below) in my database in "draggableviews_structure" table under "args" column, there were extra "[]" in some cases where I was using the arguments. There is also a comment about this issue.

"Args not working => https://www.drupal.org/project/draggableviews/issues/2903567": "https://www.drupal.org/files/issues/2019-09-05/draggableviews-args-not-working-2903567-10-D8.patch",

Because this extra "[]" was fixed with this commit I have to update my database as well to get back all the correct orders and to clean up the database of potential duplicates. This is my update hook:

<?php
/**
 * Update draggable views arguments data for draggable views 2.x
 */
function mymodule_update_8001(&$sandbox) {

  $connection = \Drupal\Core\Database\Database::getConnection();

  $query = $connection->select('draggableviews_structure', 'ds')
    ->condition('ds.args', '%][]', 'LIKE')
    ->fields('ds', ['dvid','view_name', 'view_display', 'args', 'entity_id', 'weight'])
    ->execute();
  $results = $query->fetchAll();

  foreach ($results as $draggable_view_item) {

    $new_arg = str_replace('][]', ']', $draggable_view_item->args);

    /**
     * Step 1:
     * Delete existing duplicates that already do not have extra "[]"
     */
    $duplicates_query = $connection->select('draggableviews_structure', 'ds')
      ->condition('ds.args', $new_arg)
      ->condition('ds.view_name', $draggable_view_item->view_name)
      ->condition('ds.view_display', $draggable_view_item->view_display)
      ->condition('ds.entity_id', $draggable_view_item->entity_id)
      ->fields('ds', ['dvid', 'view_name', 'view_display', 'args', 'entity_id', 'weight'])
      ->execute();
    $duplicates = $duplicates_query->fetchAll();

    if (!empty($duplicates)) {
      $dvid = array_column($duplicates, 'dvid');
      $connection->delete('draggableviews_structure')
        ->condition('dvid', $dvid, 'IN')
        ->execute();
    }

    /**
     * Step 2:
     * Change argument for existing orders (remove extra [])
     */
    $connection->update('draggableviews_structure')
      ->condition('dvid', $draggable_view_item->dvid)
      ->fields(['args' => $new_arg])
      ->execute();
  }
}
igonzalez’s picture

#8 works for me in drupal 8.9.2

nicoleannevella’s picture

@Daniel Korte

thank you!!

devad’s picture

@sumit.prajapati #19

I have checked a bit further...

If drag view and display view are two displays inside the same view then patch #8 works.

If drag view and display view are separate views patch #8 does not work.

Current 8.x-1.2 version does not have this limitation because it does not have problematic part of code introduced here:

#3089597: Support media entity type.

Solution might be to revert patch #9 commit above completely as suggested by patch #14 in the same issue.

Additionally... the following issue is also similar to our issue but it is limited to 8.x-1.2 version currently:

#2767437: Allow sort handler to select the view that stored the order

Patch #70 in this issue is removing problematic part of code as well, so if Patch #70 will be properly adjusted and committed to 2.0.0 version I suppose our issue will be solved also.

sumit.prajapati’s picture

@devad you have done lot of R&D part (Good work)

If drag view and display view are separate views, there is no relation so it will not work. btw i have not tried this way.

As you commented I have tried Patch #70 its not worked for me.

bellenss’s picture

#8 works for me in drupal 8.9.3

randell’s picture

Can confirm, #8 works on Drupal 8.9.5.

dubs’s picture

Thanks for the patch, which works well in a simple case. IMO the better approach is the one referenced by @devad above - https://www.drupal.org/project/draggableviews/issues/2767437. This allows site builders to choose the view and display ID which is more flexible.

carma03’s picture

Just to confirm #8 works good on D8.9.1 and DraggableViews 2.0.0. Thanks @sumit.prajapati

robertom’s picture

Hi all, sorry for my bad english

I have same problem. The "break" is introduced with #3089597: Support media entity type. but it is not necessary to completely remove the view_display from the join.

Attached a patch that maintains the join with the view_display, if in the views there is a field of type draggableviews (so, the "sort display").

I think the final solution must be #2767437: Allow sort handler to select the view that stored the order, but this patch is a temporary workaround.

P.S. be careful because, in my case, after the update to 2.0.0 it doesn't keep the previous order and the views have to be reordered. in my case I have a contextual argument in the views, but in the original database I have the args column empty, so in version 2.0.0 it is as if I have never ordered the view

snowcoder’s picture

Applying patch #8 seemed to make everything work again as far as sorting order goes, however, I now get duplicates of each of my items in the listing. Not sure why this is happening now and why it lists 2 of each item.

devad’s picture

@sumit.prajapati #28

As you commented I have tried Patch #70 its not worked for me.

Regarding patches in #2767437: Allow sort handler to select the view that stored the order

Patch #70 is for 2.0-x branch, and patch #81 is for 8.x-1.x branch. If you try to apply them viceversa the apply will fail.

Simplified patch #78 is demo-free and tests-free and it can be applied properly to both 2.0-x and 8.x-1.x branches.

alexpertsi’s picture

Just to confirm #8 works good on D9.0.7 and DraggableViews 2.0.0. Thanks @sumit.prajapati

ssingh7377’s picture

#8 works fine on D8.9.9 and DraggableViews 2.0.0.
Thanks @sumit.prajapati

nevergone’s picture

Status: Needs review » Reviewed & tested by the community
larskhansen’s picture

Confirming the patch on Drupal 9.0.9 and DraggableViews 2.0.0.

It would be nice to get this patch into the code, thank you.

zebda’s picture

I tried the patch #8 and #33, running D9.1.0 and Draggableviews 2.0.0. I also tried the dev version of Draggableviews but without any succes. The draggable views weight of my items is 0 for all items? Any idea on how to solve this?

Update:
I added the view to set the order, in the same view as the display view. And now it is working.

caspervoogt’s picture

#8 works for me on a clean 2.0.0 install on D8.9.10, but as others noted above, no contextual links. Instead I am displaying the order block directly on the page, which works for me.

alabandit’s picture

#8 works for me
#33 Fails

2.0.0 D9.1.2
A simple list of sortable titles
And a grid of blocks set to display full content

gaspounet’s picture

Another post to confirm that patch #8 is working (draggableview 2.0.0 and Drupal 8.9.13), thanks!

visios’s picture

Confirming patch #8 is working for me with Drupal 9.1.3.

markiz’s picture

After applying patch number 8, it works ONLY, if administration of draggable view is in the same view, as front end view.
Thank you very much for this great module and for patch number 8!!

styrbaek’s picture

Any one have an idea of how to get this to work with contextual filters?

devad’s picture

@styrbeak #46

In my case it was enough for all my content to be sorted the same way both in views with contextual filters and in views without contextual filters. So, I have used the Weight module and it works nicely.

If you need different sorting for two different views (same content) you can accomplish this as well by adding two Weight fields to your content type (or any other entity you need to sort).

You can hide the weight fields from content administrators (node forms) easy, and use them "in the background" just for drag-and-drop sorting.

If you need a complex sorting solution, take a look at Entityqueue module. It has working D9 version and there are few nice tutorials for it on web.

I hope this helps.

masher’s picture

Also confirming patch #8 is working for me with DV 2.0 on Drupal 8.9.13.

Many thanks

thhafner’s picture

Also confirmed that #8 works on 8.9.13.

seanr’s picture

StatusFileSize
new14.13 KB

I can't get either patch to work correctly when the contextual filter is getting a term from the current node. I've attached the view config since I'm certain I'm not explaining that in any sensible way. LOL

jaroslav červený’s picture

#8 work me on Drupal 9.1.5

joco_sp’s picture

I just tried this patch, because it seams that includes the solution from #8 from this issue and it has an additional feature, which I was waiting for quite some time -> The option to select from which view to use the draggable sorting. It seams that it is working so far. Will monitor how the solutions works out after some time and post my findings.

hockey2112’s picture

Drupal 9
Draggable Views 2

View has a contextual filter (like a taxonomy page)

DV weight not working, shows up as "0" for each item on that page.

SaraT’s picture

I'm on 8.9.14. I did the same as #52. Unfortunately I had the same problem as #53. I have a view page and blocks that have a different sort based on the taxonomy term chosen in the filter. I need to be able to save a unique sort order for each filtered view without altering the sort order of another filtered view.

teknocat’s picture

It seems to me that the solution here needs to be a configuration setting for the draggableviews weight sort element that allows you to choose which sorting display it should take the weight from. This will then allow you to have more than one sorting display in a view that can then be applied to other displays within the same view.

Of course the other very simple workaround to that is make separate views, each with just one sorting view. I would tend to do that anyway as I would find it less confusing and better organised to separate the views and name them according to their purpose, if they are the same content but sorted in different ways.

firfin’s picture

Patch did not work for me as my listing en sorting views are separate.
Like stated before in this thread (even in the previous post) the solution lies in #2767437: Allow sort handler to select the view that stored the order.
This problem does not even exist of the patch there is applied.

I would even go so far as to mark this issue a duplicate of that one, as it is A. older and B. has a (mostly) working patch. But that is not my call to make.

gooddev’s picture

istryker’s picture

Chose the fix in #2767437: Allow sort handler to select the view that stored the order. It is now commit and is is part of 2.0.1 release. You may have to resave your views, both for the display and the ordering. There is now an additional option to select which view and view display order to use (just like 7.x-2.x).

istryker’s picture

Status: Reviewed & tested by the community » Fixed

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.