I have two page view displays in the same view for displaying and sorting a particular content type. Module version is 7.x-2.0+21-dev.

I am facing the following problems, after following the README included in the module:

  • When creating 2 displays in the same view, the "display view" cannot access the "sort" view, I suppose because the view is not yet saved. This might be OK, but when I check the Draggableviews sort field in the main view it selects any pre-saved sort view it can find, even from a totally different view, this is confusing.
  • When going to the sorting view, I see that all weights are set to an equal value (at least when I click on show weights). e.g. for 5 rows, all show a weight of -5, even though different weights were set last time I saved the order. This is peculiar. Note that the order view does show the last saved order regardless off the weight shown...
  • I can basically not get the order of the sorting page to be taken into account in the main view display, even though both views have the same sorting criterion with asc order.
  • "Order view" contextual link is not shown. I have not changed any permissions yet, but I suppose it should work for the administrator (user 1), right?
  • After disabling the argument usage to see if it matters for the sort and saving the view, I encounter PHP memory size error for both the original and display view, even though memory_limit is set to 128M in php.ini:

    Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 1626 bytes) in C:\xampp\htdocs\salsaspring\sites\all\modules\views\plugins\views_plugin_display.inc on line 76

Thus, I am left with a broken view. Tried recreating it or cloning if from another view that works (although the sorting doesn't work there either), but I again got the PHP error after a few edits. Also now I cannot even edit the working views because I get memory size errors in the AJAX when editing the view.

I am attaching an export of the view in case it helps.

Thank you in advance

CommentFileSizeAuthor
view_export.txt10.28 KBmarktheshark
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

marktheshark’s picture

marktheshark CreditAttribution: marktheshark commented
Issue summary: View changes

additional info

marktheshark’s picture

marktheshark CreditAttribution: marktheshark commented

Note that deleting the sorting view and the sorting criterion in the main view makes it work again (albeit, without any particular sorting order).

iStryker’s picture

iStryker CreditAttribution: iStryker commented
Priority: Major » Normal

I'll give my 2 cents on this issue.

You are using views slideshow. To my knowledge this module uses alot of memory as it uses image style. Again to my knowledge image styles uses alot of memory. (I could be totally wrong in this)

I used eclipse IDE to walk through the code function by function to solve another problem/issue. In the code, I notice that the views were loaded multiple times. Some of them seem to be unnecessary, but I could not be for sure.

I cannot benchmark your example, as I do not know what other modules you have install.

It would be nice if we could benchmark

  1. Drupal without draggableviews installed.
  2. Drupal view with draggableviews ordering
  3. Drupal view with a draggableview weight sort.

In your case I would add 3 more test.

  1. Drupal view with a view slideshow, but no draggableviews ordering or sorting.
  2. Drupal view with a view slideshow draggable view ordering.
  3. Drupal view with a view slideshow with draggableviews weight sorting.

This issue is definitely not major, as you can just increase the PHP limit.

marktheshark’s picture

marktheshark CreditAttribution: marktheshark commented

I know the memory limit can be raised, but more than 128 MB of memory for a view?

I have disabled DraggableViews for the time being, perhaps I'll use custom sorting via another field or check out nodequeue.

Dubs’s picture

Dubs CreditAttribution: Dubs commented

I have the same issue here. I upped to memory to 512M but it still maxes out. It seems to eat up whatever it's given!

iStryker’s picture

iStryker CreditAttribution: iStryker commented

There must be an infinite loop in the code then.

@Dubs, are you using view slideshow too? If not, what is your view? Is it simple or complex? Does it have an image field.

Dubs’s picture

Dubs CreditAttribution: Dubs commented

@iStryker - thanks for getting back so quickly.

I'm using a view with the following displays: -

  • Page - displays a list of taxonomy terms with images in a grid view - no slideshow!
  • Attachment - an HTML list of taxonomy titles used as a Menu View item
  • Page - the actual ordering page - a table view of titles only

What's interesting is that it was working until I added the sort criteria on the page with images. The sorting was fine on the 2nd page and the menu view attachment. The memory problems occurred as soon as I added the sort criteria to the page with images.

iStryker’s picture

iStryker CreditAttribution: iStryker commented

Awesome feedback @Dubs. I think a line by line walk-thorough in Eclipse is in-order to find the bug. I will not have time to test this for atleast a week.

In the meantime, can you test something for me...

  1. Clone the view and remove the 3rd order displays.
  2. In the new view, reference the draggableview sort order from the original.
  3. In the new view, change the path of the page for testing.

Does the new view give you the php memory limit error?

DenisVS’s picture

DenisVS
Location Belgrade
CreditAttribution: DenisVS commented

same this problem
---upd
Pager must be less infinity, e.g. not zero.

Dubs’s picture

Dubs CreditAttribution: Dubs commented

Hi, sorry for the delay in responding... I changed my view to get to work with the default taxonomy ordering and it took a while for me to change it back for this test.

Yes, the issue appears to go away when I have the ordering page on a separate view.

Dubs’s picture

Dubs CreditAttribution: Dubs commented
Issue summary: View changes

formatting

markus_petrux’s picture

markus_petrux CreditAttribution: markus_petrux commented
Issue summary: View changes

Hi!

This issue also happens in 8.x... the code enters in a never ending loop when draggableviews tries to compute the depth when item has parent. The id of the parent seems to be set as the same id of the item, so the index is the same and the method keeps recursing itself.

No idea where the root of the problem is. :(

Cheers

jordan.jamous’s picture

jordan.jamous CreditAttribution: jordan.jamous at Eighty Options commented

Hi, I agree with @markus_petrux . Currently I am trying to upgrade from 1.0 to 2.0.1. Somehow on reordering an element, draggableviews[x][id] value gets copied into draggableviews[x][parent], causing DraggableViews::getDepth() function to go into an infinite loop. This is on a fresh install of drupal 8.9.18 on bootstrap or seven theme.

PHP Fatal error:  Allowed memory size of 536870912 bytes exhausted (tried to allocate 262144 bytes) in /var/www/html/drupal/web/modules/contrib/draggableviews/src/DraggableViews.php on line 60

I have no idea why the JS behaves this way, I tried to lookup for any bugs in core tabledrag.js found nothing. I will open a new ticket and supply a workaround to the infinite loop.I may have a look if this happens on 9.x as well.
Note that I followed the README.md on 2.0.1 to install the module, but I think it might need to be revisited as it is a bit confusing (I would revise it myself but I can't get the draggable behaviour to work :| )
Thanks all of the hard work