usable DraggableViews release for Drupal 7

@Pasqualle Hi and thank you for your tremendous work. I feel really sorry that we didn't cooperate on it. At the moment I try to concentrate on 7.x-2.x branch only and make it stable and I see much more advantages in it than bringing back to life 1.x version.

I really don't know how to use your version of module atm. Maybe we can make it compatible with 1.x version and fix in this way some of the bugs in 7.x branch? From your message I am not sure I understand what handlers work? As I understand only nodequeue? But well... nodequeue has it own sorting mechanism. So how we can benefit from having draggableviews sorting nodequeue items? How does relation entity weight field work?

Please share you opinion and lets cooperate.

Thanks!

We are using a lot of draggable views and I don't like the idea of rebuilding all of them.
The above patches had been tested long time ago and have never been applied.
Instead the module was reinvented.

Maybe you could assign Pasqualle as a co maintainer for 7.1.

@Pasqualle:

I have not actually used your version but I am successfully using the 2.x drupal.org version and I don't see a problem with it.

Because it provides it functionality via a field it can easily be added to any view type, and it already works on any entity as far as I know. I am usinf the file_entity module along with draggable views to reorder file entities used for an image slideshow.
I am even using it along with other sorts. My slideshow view sorts by taxonomy term weight (images are grouped by a term) and then the draggable views weight, so each individual term has it's own slideshow which is ordered by draggable views and all slideshows are ordered using the same draggable view.

The only problem I ran into was that the taxonomy term weight sort is called 'weight' and this module expects any sort named 'weight' to be its draggable views weight. See #1389440: Undefined index: draggableviews_setting_view in draggableviews_contextual_links_view_alter() (line 180 of draggableviews.module)

I have also done a test on sorting taxonomy views and it worked as expected.

Because it can be used on virtually any view I don't see why it can't be used with nodequeue, although I haven't tried.

Are you saying your version allows you to specify a field to use as the weight, instead of using an internal draggable views weight?
Originally I thought that was how this was going to work and I still think it might be useful, however since using the 2.x version it isn't necessary for my use cases.

So I guess my point is that 7.x-1.x is outdated can't do a lot of the things you want to do but 7.x-2.x is far superior and I think can do what you want to do already (and if it can't it would be likely easier to get 2.x to do what you want then 1.x).
I also see the maintainers point of view about maintaining more than one recommended branch.
It spreads developer power thinner and makes things more confusing for the users.

Assuming you have tried 7.x-2.x, what do you need to be able to do that it can't do?

7.1 has more features then 7.2.

It supports tree structures and node-reference fields.
So it is not superior but just a reinvention as the
maintainers didn't want to fix the bugs.

Wouldn't it be better though to add these missing things to 2.x and have everyone focusing their efforts on?
Because the parts of 2.x that aren't missing and it already supports things like full entity support (including taxonomy, which is an issue for some).

There is an issue regarding node references here that says it works (unless you are talking about some other sort of functionality) - #1386848: Incorrect working with node reference

However seeing as 7.x-1.x is still in dev, if a patch was made to go from it to Pasqualle's version I don't really see the harm in committing that do dev for people who might want it in the meantime (although with that argument you could just go get it from Pasqualle's link and get it too).
And seeing as drupal 6 is at 6.x-3.x you wouldn't have to feel obliged to back port as it isn't the same major version.

However there is still the issue about people being confused about which version to use and potentially ending up with people on an unsupported version (although that isn't uncommon in drupal anyway but it is good to avoid it where possible. An upgrade path between version would eliminate any issue here though.

@Merco, the problem we are facing in 7.x-1.x branch fixing bugs is complexity of the code. It is now extremely hard to fix it. Also the idea of 7.x-2.x branch is to use different approach in views: using form field instead of view display.

Regarding work of @Pasqualle, I would love to commit his work and cleanup 7.x-1.x branch, but I have a feeling that his version of 7.x-1.x is narrowed to his usecase. Specially when it is written that it is not compatible with 7.x-1.x.

@Pasqualle, could you please create a patch to add nodequeue functionality for 7.x-1.x. I will be very happy to test it and commit. Are you interested in maintaining 7.x-1.x branch?

@Merco regarding fixing 7.x-1.x bugs, could you please test patches in the queue and mark them RTBC so I can commit them faster. This will really help and I will be glad to have your support on this.

So which one is going to be the winner going forward? I do miss the integration of the flag weights module -- very handy in 7.1 to create groups of content and order them.

Pasqualle, you are my hero!

Just to add a bit more. There are a lot of users using 7.1.x. It just seems kind of tough to have no upgrade path and force them to recreate all of their views. I'm open either way, but integration with flag / flag_weights would help migrating views. Otherwise, the migration would be pretty signification for folks. Just my two cents.

@cschaub:
I can't agree more
We wrote some custom modules which export DraggableViews using features.
Those modules are used in several sites.
They sort taxonomies, entities, node references, and int fields.

We use patches like:

#1268824: Ajax Support
#1237008: Using draggable views to sort taxonomies
#1264636: Allow for any fieldable entity to be ordered
#1169790: Use the first visible field to handle the order

@ygerasimov:
#1237008: Using draggable views to sort taxonomies Reviewed August 14, 2011 at 3:46pm

@Pasqualle
Sorry I didn't see that you won't offer a upgrade path as well.
Imho 3 different DraggableViews version are even worse than 2 different versions.

As I understand main issue not to move to 7.x-2.x branch is absence of pluggable handlers. So lets take priority of creating this system and have handlers for Field API, Taxonomy.

At the moment I don't have many ideas how to provide upgrade path. If anyone has any thoughts about it, I very appreciate if you share them.

In the meanwhile I will work on applying listed in #12 patches to 7.x-1.x branch. Truly to say I really want to push all development to 7.x-2.x branch and keep maintaining of 7.x-1.x branch to bugfixing only.

@ygerasimov:
If all the draggable views settings in 7.x-1.x have equivalent settings in 7.x-2.x you can do an update function that runs through all the site's views looking for draggable views and converts the settings to the new model.
I haven't looked at actual code but it is likely possible.

In the case that there is functionality available in 7.x-1.x that isn't possible in 2.x then that will be an issue.

So outstanding issues of missing functionality from 2.x would have to be done first to get reliable updates.

Also, the project page should be updated to reflect the development direction -- folks should not be starting new projects with 7.x.1 based on the comments above.

@cshaub, that is good hint. I have updated project page. Thank you.

As 7.x-2.x does provide less features we can't migrate from 7.x-1.x neither
manually nor by an update function.
That means that on pages where 7.x-1.x is already running we have to
keep creating 7.x-1.x draggableViews.

A solution might be to rename the draggableViews 7.x-2.x module as it is
a complete new module.
Then you don't have to care about upgrade paths and you could offer both:

7.x-1.x older code base with more features
7.x-2.x newer code base with more support

Old modules could have dependencies to draggableViews 1
and newer modules may use draggableViews 2.

Also views which can be migrated without much work could run together
with views that require 7.x-1.x features on the same page.

@Merco, I don't agree on moving 7.x-2.x branch to different project as the aim of 1.x and 2.x branches are the same. Lets concentrate on implementing features of 1.x branch in 2.x and possibly writing upgrade path.

If you would like to update documentation or project page text please let me know how to do this so users will be more aware on the status of the module.

@Pasqualle can you run all those modules with different dependencies on one page?
@ygerasimov if there won't be two version then there has to be an update path.
I didn't want to criticize your volunteer work as everyone knows that building
this module was a lot of work.
However I am really disappointed now. You don't want to maintain the widely used
7.x-1.x release anymore. Many patches haven't been reviewed or commented for months.
Reviewed patches weren't applied. This is also the reason for this issue:
"usable DraggableViews release for Drupal 7"
We - the community - tested, patched and reviewed your module. Now you force us to
decide whether we want to spend a lot of time rebuilding and testing all depended modules
or to build new draggable views with 7.x-1.x which will get even less patches and improvements.
7.x-1.x was tested a lot and almost stable but now you ask us to switch to an alpha version
with no upgrade path.
Your intention to rebuild the module with a better approach (views form) is understandable
but how can we know if you will maintain it for the next 12 month or rather create a 7.x-3.x or
8.x branch without any upgrade path?

I have not seen many (if any) modules that support two major versions at the same time that work differently (maybe they do for a short period). It is just way too much to maintain and it confuses users when they have to choose which one to use.

It is also usually best practice to be making new features etc for the latest version. Unless you really need an old version to do something for a client, in which case I wouldn't hold my breath for it ever being committed.
Lots of modules have the problem that when they release a new version there is a whole heap of patches for a previous version. Usually what happens is those patches have to be ported to the new version or else they are forgotten about. It can be frustrating but it is not uncommon. It also happens with drupal core.

There is a lot of complaining about the 7.x-2.x version but there doesn't seem to be many people contributing patches to resolve their issues. Seriously, if we get the few things missing from 7.x-2.x in there there will be no need for this issue.

The upgrade path can still be done, but first 7.x-2.x needs to have all the features that are in 7.x-1.x.

It is annoying when you cannot find a solution to fit your needs without having to apply patches but unfortunately that is how open source can be sometimes.
I often use patched versions of modules (especially in drupal 7) when I require them. You just have to keep track of what is patched so you don't have troubles down the line when you are updating things.

Also, in #13 ygerasimov mentioned he would get to the outstanding patches for 7.x-1.x, so hope is not yet lost for that.

@Pasqualle - We have more complex systems than just a blog websites.
And the 7.x-1.x was a port and we patched it and hoped for a stable version:
[1214388]

But I guess ygerasimov made his point.
He wants to focus on a better stable rebuild and will maybe (rather not) build an upgrade path.
I will definitely upgrade some day. Probably without a upgrade path.

@Merco. In post #5 you mention the tree structure is supported, but the front page warns:
"7.x-2.x branch [...] In first instance it won't support building tree structure. Only dragging items for reordering."

Could you explain this a little more? My interest goes back to the DraggableViews GroupBy [1] Issue. I understand a GroupBy option as a "tree structure": parent items are ordered with DV and each child item under each parent is ordered with DV. Creating an arbitrary sort of both lists. There are a number of people eager for this functionality. I look forward to clarification.
---
[1]: http://drupal.org/node/566332

@xtiansimon - What exactly is your question?
There is only tree structure in 7.1.
We used it to reorder nodes in a hierarchy using the node refrence field and a int field.

I would like to ask everyone here to test Field API of 7.x-2.x. I have created "handlers" branch for this.

Please leave your comments in #1353738: 7.x-2.x FieldAPI handler.

Thanks!

Branch 7.x-2.x already has both Native and Field API handlers, compatible with VBO, has automated tests. I believe it will get beta release very soon. So it is recommended version to try.

Closing this issue.