Can't modify or remove sort criteria

@moniuch I have problems reproducing this bug. Could you please provide step by step instructions how to have Weight sort criteria, that cannot be edited / removed?

I have this same problem today.

In recent times, I have successfully made Draggable Views in a Drupal 7 environment.

Today is the first time that I tried to apply a dragging setup to the Views that come with Ubercart (aka "_catalog" or "uc_catalog").

At first I got an error message in the Drag sorting settings, and something about the Date module. I thought it was wierd that I needed the Date module for dragging, but I installed it anyways because I need the Date module for other things.

Anyways, no improvement.
I still see an error message "An illegal choice has been detected." in the drag sorting setup and I CANNOT remove the sorting at all.

In Drupal's error log I see a few of these form warnings:

"Illegal choice all in type element."

Date Monday, May 14, 2012 - 11:24
User ****************
Location http://*********.******************.net/admin/structure/views/ajax/config-item/uc_catalog/catalog/sort/weight
Referrer http://*********.******************.net/admin/structure/views/view/uc_catalog/edit/catalog?destination=catalog%2F2&render=overlay
Message Illegal choice all in type element.
Severity error
Hostname ***********************

I still can't reproduce the problem :( I clicked though interface back and forward and can't make any element validation error "An illegal choice has been detected.". Can you trace what form element causes this error?

Same problem here.

I have traced with XDebug and it seems that inside the AJAX petition strangely Views trys to render the exposed form options for another field that is not related to current View.

I'll try to collect more data and expose it here.

In the draggableviews_handler_sort handler all available views are built in the options_form method.

In my case I have another view with an exposed filter. When this view gets rendered the exposed filter form is rendered to, but the $form array has the always_process set to true, so my guess is form is processed and the illegal option comes from this exposed filter form that's redered and processed that shouldn't be processed.

I've tried to repoduce this using a fresh drupal installation but I couldn't.

I got the same issue but I found a temporary solution to edit my views.

Edit views parameters here :
admin/structure/views/settings >> disable automatic preview
admin/structure/views/settings/advanced >> disable the javascript of views

& then u can edit the draggable views order criteria or field...

this is just a tips but a patch would be cool ;-)

Having the same issue, when trying to use a sort defined in one draggableview in another normal "front-end"-facing view. I am also getting a bunch of these warning, though I am not 100% sure they are related:

Warning: Invalid argument supplied for foreach() in views_plugin_display->uses_exposed()

Tried the suggested workaround of #9.

Changing the order of items in the view does'nt change the position of the list.

Also this error shows up:

Notice: Undefined index: sorts in draggableviews_handler_fieldapi->options_form() (regel 32 van ~~~/public_html/sites/all/modules/draggableviews/handlers/draggableviews_handler_fieldapi.inc).

http://jawi-online.nl

This issue occurs whenever there are errors in building any of the views on your site.
Draggableviews builds all displays of all views on your site to build the 'Display sort as' select list. [draggableviews_handler_sort->options_form()]
If any of those views has an error then the validate function of the draggableviews options form will fail and nothing will happen.

In our case we had an exposed filter in a completely unrelated view which was marked 'required' but had no default value. Views renders the exposed filter form during the building of the view and drupal validates a form when building it. This caused the form_set_error() to be called. On validation of the options form form_get_errors() is checked and will return something. This prevents the options_form submit handler from being called.

For me the prefered solution would be to figure out some other method of finding views/displays since the current method uses a lot of memory, does not scale well and is sensitive to errors in other views.

An alternative could be to call form_clear_error() in draggableviews_handler_sort after building all the views but this may suppress validation errors in the options_form itself.

Nice feedback "JvE" !!
Would be a great sullution. For now I will give your advice a try

I posted a *possible* patch for this issue at #1717830-1: Exposed filters with added javascript cause failure to load sort criteria settings overlay.

Patch in #1717830-8: Exposed filters with added javascript cause failure to load sort criteria settings overlay. fixed issue.

Marking as duplicate as it seems the patch to fix this is in the other issue. #1717830-8: Exposed filters with added javascript cause failure to load sort criteria settings overlay.

One additional comment for someone who might see this thread; we also found this to be a problem after deleting a content type.

We were very deliberate in our approach to removing the content type. Content was deleted first, then views, and then the content type itself. Also all caching features were disabled. However, we started receiving errors with Draggable Views after these steps were performed.

The issue was ultimately resolved by performing a full clearing of the site cache. Once this was completed, the Draggable Views errors disappeared.

I also have this problem. Created a set of views (one for content one as controller), everything worked ok, draggable views included.
Deleted it by stupid mistake, created another identical set few minutes later and now I cannot get it to work.

Cannot remove sort criteria from content view, cannot update it either (asc to desc etc). No error message, the dialog screen just doesn't respond. Tried to flushing the caches, disabling the module etc. For a while the controller sort of worked - it did change the content views order but it did not remember it itself, so after reloading the page it showed wrong sort order in controller. Now the controller remembers the right order and sets it itself but the content view is not affected at all.