After clicking 'Show weights' all of the weights are the same. If there are 3 items, then they are all -3. If there are 8 items, then they are all -8. The rows/items are in the correct order though.

This is:

  • Misleading.
  • An accessibility issue.
  • Leads to other reporting issues in the queue when their view is not setup correctly or they have another problem.
CommentFileSizeAuthor
#11 draggable_views_order_issue.jpg51.12 KBbcdev
#4 draggableviews-same_row_weight_values-1780498-4.patch681 bytesistryker

Comments

Jason Dean’s picture

Jason Dean commented

Yep experiencing the same here...

mgifford’s picture

mgifford
he/him
Primary language English
commented
Issue tags: +Accessibility

Just tagging.

istryker’s picture

istryker commented
Priority: Normal » Major

Changing priority. This causes major accessibility issue.

istryker’s picture

istryker commented
Assigned: Unassigned » istryker
Status: Active » Fixed
StatusFileSize
new draggableviews-same_row_weight_values-1780498-4.patch681 bytes

This problem was introduce in #1660508: 'New items appear bottom of the list' option fails in PostgreSQL because of COALESCE function

Patch attached.

Committed 91406b8.

This might reoccur if #1787764: Unknown column caused by orderby alias not matching field alias gets committed.

istryker’s picture

istryker commented

For better values of the weights see issue #1901192: Row weight values range should be the same as what gets save to database

rongok’s picture

rongok commented

the patch doesn't solve the issue. All the weights are still same after applying the patch.

istryker’s picture

istryker commented

@rongok, after your comment, I went ahead did some more investigation.

One solve technical problem. If it is a new view (or a view with a new set of filter settings & (x) Use all arguments is selected), then all rows will be 'zero' as every row has a value of (2^31 - 1).

Technically 'zero' is the lowest value in the range.

This is how it works currently

      $form[$this->options['id']][$row_index]['weight'] = array(
        '#type' => 'select',
        '#options' => range(-$range, $range),
        '#attributes' => array('class' => array('draggableviews-weight')),
        '#default_value' => $handler_object->get($this, $row_index),
      );

This will probably change with #1551230: Add pager support for DraggableViews tables, when it adds the complexity of a pager.

NaX’s picture

NaX commented
Status: Fixed » Active

I think this same problem exists for the Field API handler version and this patch seems to only apply to the native handler. I think the Field API version should add the sort field as a normal field to the query and then read it back in the get() function.

Sorry, I don't know the views api well enough to provide a patch.

istryker’s picture

istryker commented

Ok I will take a look at this. I did not think this would be broken, as its able to weight number from the field value. Maybe you have your view broken.

NaX’s picture

NaX commented

Everything works fine for me, except when I click "Show row weights". The drop-down select for every row defaults to the first option.

bcdev’s picture

bcdev commented
StatusFileSize
new draggable_views_order_issue.jpg51.12 KB

I'm seeing the same behavior as NaX using the dev build I downloaded on 2/5/2013. Once you drag a couple items around and hit save, it will then save the order as expected. However, you still see all of the items with the same view order (see jpg).

istryker’s picture

istryker commented
Status: Active » Fixed

@web_junkie - the way you describe it, is what you should expect. You create a new view, and all the values are the same or are nulll/not set. They will all be the same [-(# of items)]. Once you click save, then they will all get a value.

I cannot recreate this problem with FieldAPI and the latest 7.x-2.x-dev

FYI - you sort by the weight. IE if you have a field called weight, then you sort by "Content: weight", not "Draggableviews: weight".

NaX’s picture

NaX commented

@iStryker
When you tried to reproduce the problem did you click on "Show row weights" exposing the weights drop down and then trying to change the order using the drop down selects. Or is this a different problem and should have its own new issue.

istryker’s picture

istryker commented

This is for showing the Row weights value correctly. @NaX if you try to sort using show weights and it does not work, then thats another issue.

NaX’s picture

NaX commented

@iStryker, The problem I have is exactly the same as the original issue summary describes, but I think we are discussing two problems here.

Drag and drop ordering is working fine by its self, the problems exists when "Show weights" is clicked and the weight drop down selects are shown. One thing I can confirm is that the described problem is only 100% reproducible when you from a fresh page load do not use the drag and drop at all and then click "Show weights".

The first problem is that the drop down selects default to the first value as per the issue summary and web_junkie screen shot.

The second problem is that when you use the drop down selects to set values and click save the values are not used and all order field values are set to zero because the value used was NULL (unconfirmed). Where the zero/NULL comes from, I don't know.

@iStryker, please let me know how you would like to proceed with this going forward. Do you want us to open new issues? Is there something you need from me to help you reproduce, test or debug this. I tried to look into it myself but my Views API skills are were not good enough.

NaX’s picture

NaX commented

Ok, I ran an experiment where I created to identical views the only difference besides page paths was the sort field being used. I got it sort of work in the one view and not working as per previous posts in the other. The only difference between the two fields from what I can tell is that the one was called 'field_order' or and the other used my usual naming convention "field_[node:type]_sort_order" in this case field_slideshow_sort_order.

I hope that helps.

Status: Fixed » Closed (fixed)

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

DeFr’s picture

DeFr commented

Adding a pointer here for those ending up on this issue when searching the issue queue, and that would be in the same situation as NaX: the problem with draggable views not showing correct weights with long-ish field names is tracked in #2005000: 'Show Weights' are broken with long field names.

NaX’s picture

NaX commented

@DeFr, Thanks, that does seem to be my problem.