When using the FieldAPI and you open the page and save without making any changes the weights are reset.
I did not test this on Native draggableviews.
The problem actually occurs when loading the page.
All weights are reset because of a views limitation.
The key on the row in views has a limited length, so in the get function of draggableviews_handler_fieldapi the check on the $field_name fails and the $value is not returned.

I wrote a little patch for that. It is not save but it solves my immediate problems.

CommentFileSizeAuthor
draggableviews_views_limitation.patch935 bytesJan van Diepen

Comments

ygerasimov’s picture

ygerasimov commented
Status: Needs review » Postponed (maintainer needs more info)

Sorry I cannot reproduct. What I have done:
1. Added integer field to article
2. Generated articles
3. Created a table view with draggableviews field Field API handler based on my integer field. Sorted by integer field.
4. Saved a view once (did some changes in order)
5. Saved a view without any changes

Weights are still the same and order is kept.

Please advise how to reproduce your case?

istryker’s picture

istryker commented
Status: Postponed (maintainer needs more info) » Fixed

Issue is 36 weeks old. I cannot reproduce either. This probably has been fixed in the latest dev as it has fixed the problem with most mis-configured views. To my knowledge the patch has not been applied.

Cleaning up issue queue. Closing issue. Reopen if you still have an issue.

Jan van Diepen’s picture

Jan van Diepen commented

Sorry for the late reply and for what it's worth.

As mentioned in my original issue, the problem occurs only when the name of the field is too long.
The key on rows in views is a combination of the name of the table and the name of the field. The key is limited in length.
So if the combination of the two is longer that the maximum key length it is truncated.
Since the name of the field is at the end, this is truncated and will not be matched in the check.

Since it has probably been fixed in the latest dev, I will not re-open the issue.

istryker’s picture

istryker commented
Status: Fixed » Postponed (maintainer needs more info)

Ok I did not understand before. What you are saying has some logic. I still cannot reproduce this. How should I reproduce this @Jan_van_Diepen? Have a field with the maximum length? Use a relationship so the sql query name its extremely long?

Below is the current Get() code from the FieldAPI handler 

  function get($field, $index) {
    // Get the name of selected field.
    $field_option = $field->options['draggableviews']['draggableviews_handler_fieldapi']['field'];
    list($field_table, $field_name) = explode(':', $field_option);
    // Current row.
    $row = $field->view->result[$index];
    // Check whether key has table name and field name in it.
    foreach ($row as $key => $value) {
      if (strpos($key, $field_table) !== FALSE && strpos($key, $field_name) !== FALSE) {
        return $value;
      }
    }
  }
Jan van Diepen’s picture

Jan van Diepen commented

I can see the patch is not applied.
It's the combination of $field_table and $field_name which is extracted from $field->options['draggableviews']['draggableviews_handler_fieldapi']['field'].
All the keys in $field->view->result[$index] are checked for the presence of both $field_table and $field_name.
So if you have a very long $field_name, it should fail.
$field->view->result[$index] is put on $field by the views module and views used to put a limit on the length of the key.
So if the issue has been solved it is because views has changed its policy on the length of the key.

I'll see if i can find some time to setup a new environment and test it on the latest stable and dev releases of views.