In-place sorting will not save sort order when Views render cache is used

I am getting the same behavior, shutting off caching didn't help.

I'm seeing a lot of issues in the queue relating to this module not working. I feel something should be on the module page.

Creating a separate view for the sorting didn't work either. I tried both a separate display and a separate view.

Changing priority since I see many related issues that don't seem to be getting attention.

I have had this same problem. Seems to work well if the view have simple filter criteria. If a have a more complex view, using relationships of any kind the results could be not what you spect.
When you define the "sort criteria" for your view, you must not select any relationship even if you used a relationship as a filter criteria for your view. Changing this, my draggable view started to work again.

Same issue on my site with sort order not saving. My view has a relationship but there are no filters using that relationship. However, the site is a view of content that anonymous and authenticated users have flagged (Flag module along with Session API for anonymous flagging), so the Draggableviews: Flags field has the flag relationship. If I use the Draggableviews: Content field, I cannot drag the view, only sort by weight, and still cannot save the order.

Updating to 7.x-2.0+56-dev saves the draggable sorting on my site. Others have reported in this issue that it also works for dragging but not for sorting by weight.

Stop adding comment when it has nothing to do with the topic (CACHING), it is related to something else.

Moving back to normal priority as there are workarounds.

I create a test view of this and confirm that the display is not working

For the Native handler it is saving the order to the database, however it is not display the results.

Found this in views_bulk_operations_form_alter()

  // Cache the built form to prevent it from being rebuilt prior to validation
  // and submission, which could lead to data being processed incorrectly,
  // because the views rows (and thus, the form elements as well) have changed
  // in the meantime. Matching views issue: http://drupal.org/node/1473276.
  $form_state['cache'] = TRUE;

VBO does a lot of similar things that draggabeviews does, and caching is one of them

Nevermind #10 does not work.

This patch fixes the following:
1.

If you only enable query caching, the View sort will be reflected, but only after a cache clear

Clear views cache after each submit of draggable view. We clear cache only for current view.
2.

Reasonable mitigation: Provide some sort of warning to end-users when in-place sorting and Views render cache are used on the same page. Even better, detect when this is attempted and just prevent the user from ever saving this configuration set.

Validation for draggableviews_handler_field_draggable has been added.

Please test and review this patch.

Before testing.
#1 - We should not prevent the view from being save, rather, displays a warning. The goal is to warn the user that the views display cache will be cleared on each save.

Testing #12 patch - View with caching enabled:
1. Clear cache
2. Go to view and change order works.
3. Repeat #2 works until you refresh the page. Once you refresh the page, it does not fire draggableviews_form_alter() until cache expires and/or cache is cleared. This is where we add the #submit = 'draggableviews_views_submit', which saves the order and, with this patch, clears the cache for the view.

I was looking at other modules on how they handle this, and so far, no one has an answer.

Fiverstar - #2297231: Fivestar Not Working for Anonymous Users with Cache Enabled
VBO - #1307360: Node delete action doesn't fire if views cache is enabled.

So maybe we do need to throw an error message.

3. Repeat #2 works until you refresh the page. Once you refresh the page, it does not fire draggableviews_form_alter() until cache expires and/or cache is cleared. This is where we add the #submit = 'draggableviews_views_submit', which saves the order and, with this patch, clears the cache for the view.

Can't reproduce it. Are you sure you have disabled render cache for view? Because this patch doesn't fix problem with views render cahce, it fix problem with query view cache.

How I turned on caching: In your view display -> other -> caching -> time based.

Yeah, but Render output should be set as Never cache. See screenshot

See your screenshot. That makes sense now. The results are cache but the HTML/form is not. Should work.

With this patch we don't prevent views save and only show a warning message about incompatibility of Draggable Views and view cache render.

@ Comment #17 - I see what you mean now. I had both Query and Render set to X time. I double-checked and if you have query set to X, it still works

• Re-roll patch against latest dev.
• Added back the validation from #12.
• Instead of a drupal_set_message() I added HTML markup to the views_ui_edit_form. With #19 it used drupal_set_message which would display message on the next page load. This way the message shows up on when you edit the caching option render value.

Possible improvements

• throw form error with form_set_error(). This would add 'error' class to field and cache_option element. By default it would make their links red.
• form validation for cache_options and field draggablviews. I tried the code below with no sucess
  

  /**
   * Implements hook_form_FORM_ID_alter().
   */
  function draggableviews_form_views_ui_edit_display_form_alter(&$form, &$form_state, $form_id) {
    if (isset($form_state['section']) && $form_state['section'] === 'cache_options') {
      $form['#validate'][] = 'draggableviews_cache_render_check';
    }
  }
  
  function draggableviews_cache_render_check(&$form, &$form_state, $form_id) {
    dsm('test');
    $test = $form;
  }
  

Forgot the patch to #20.

Draggable views does not work when you have a contextual filter. I had one: content type and it did not work. Removing the contextual filter fixed it.