DraggableViews

Last updated January 6, 2011. Created by gustav on July 16, 2008.
Edited by justin.cherniak, drclaw, andrew.lansdowne, sevi. Log in to edit this page.

..makes views draggable

The DraggableViews module can be used to organize simple lists and complex structures via drag n' drop. The configuration is quite easy as you just have to access the style-plugin settings.

If you want it QUICK

1. Activate the module and navigate to the edit-page of an existing view.
2. Add the field "Draggableviews: Order" at the Fields section.Make sure not to check "Exclude from display" or you won't be able to use the drag/drop feature.
3. Now change the Style-plugin at the Basic settings section to Draggable Table and enter the Style plugin settings.
4. Scroll down to the Draggable Table settings and choose the Order field you added just before, probably called 'Order'. Choose "Native" handler.
5. Save the settings. You'll be prompted to sort the view by the Order field
6. Add "DraggableViews: Order" at the Sort criteria section and place it as the first Sort criteria. For sorting order, choose "Ascending". Save the view and you're done.

Creating a "Sorting Interface" for a view

Suppose that you have a view that needs to be sorted arbitrarily. The *simplest* solution is to create a "weight" field in the content type you're trying to sort... but that comes with a whole mess of problems that we don't need to get into right now. With DraggableViews you can create a "sorting interface" that will allow users to sort the result of the view using Drupal's built in drag and drop funtionality. The simple overview for this is:

1. Create a view
2. Create one display that will be the actual list displayed to visitors
3. Create another display that will act as a "sorting interface" and be used to sort the result of the view

For this example we'll describe a view that is a list of the employees at a small-medium drupal shop. The view is of the 'View type:' Node, and each employee at the company is represented by a custom Node type: "employee".

Using the view we've conceived above (a list of the employees at a small-medium drupal shop,) imagine we've created the relatively simple view with fields for Name, Position, a Head-shot (image), and a quick Bio. We also have one 'page' display set up with the path "about-us/our-team". The page is going to be used on the Company website and we want the employees to be in order of "importance" with the boss at the top, and moving down the corporate ladder after that. This is where DraggableViews comes in:

1. Once we've got the view working just right, we'll Clone the display. (The rest of these instructions will be for the newly cloned display.)
2. Rename the cloned display to indicate that it's for sorting.
3. Change the path. For the sake of this example let's use "about-us/our-team/sort"
4. If it's not already present, add a hidden field for the Node's nid. The DraggableViews module needs the nid to use as a reference
5. OPTIONAL: You can at this point remove fields from the display. When I'm sorting the list, I really just want to see the name and position so I would probably axe the Bio and Image fields. The only thing that the DraggableViews module actually requires is the Node's nid (which we added as a hidden field in the step before this)
6. Now you'll want to follow the 6 steps in the "If you want it QUICK" instructions above
7. As a final extra step, you'll go back to your regular page display for the view and add "DraggableViews: Order" at the Sort criteria section and place it as the first Sort criteria. For sorting order, choose "Ascending".
8. And that's it, your regular page view at "about-us/our-team" should sort itself based on the way you sort it using the draggable view at "about-us/our-team/sort"

This method of creating a "sorting interface" is great for preserving the flexibility of "Unformatted" (for the actual page view) but still use the power of DraggableViews for the sorting.

Simple lists

See "If you want it QUICK".

Hierarchies

If you want to build hierarchies you have to set the parent field. Use "Draggableviews: Parent" and choose "Native" handler if no third-party modules tells you something else. The maximum hierarchy depth can be specified at Define the depth limit.

Permissions

Use the "Allow Reordering" permission to allow other roles to rearrange views. Otherwise the user will not see the drag-handles.

What you should be aware of

• Don't rely on the live preview. Commonly its output differs from the actual output.
• Using paging for large views with hierarchies can result in dramatic loss of performance because the view needs to be reloaded one to three times in order to display all relevant nodes. Actually this already takes effect when Items to display (Basic settings) are limited.
• The reordering does not seem to work if you have Caching turned on for the view. The drag/drop works but upon save it reverts to the previous order. If you need caching then have a seperate display for re-ordering, and turn caching off for that.

Third-party modules can implement their own handlers to save the structure information where ever they want. Always use "Native" handler if you don't use a third-party module that tells you something else. The fields "Draggableviews: Order" and "Draggableviews: Parent" (use both in combination with native handler only) are unique for each view but not unique for different displays of the same view.

Additional settings

• Show input fields?: You can decide whether order input fields (order, parent) should be visible or not (If javascript is disabled all fields will be visible anyway).
• Define the depth limit: You can constrict the user in building hierarchies. -1: Unrestricted. 0: No hierarchies allowed. 1: Only one hierarchy level allowed. 2: Only two hierarchy.....
• Node type: You can define certain node-types to be "root" or "leaf". "Root" nodes cannot be subordinated. "Leaf" nodes cannot have child nodes. (this options will only be shown if the views base table is "node")
• Show expand Links: If checked little blue triangular icons will be shown next to the first field of a parent row. The expand/collapse state will be saved after hitting the "Save" button.
• Default is collapsed: Self-explaining..
• Unique for each user: The user-ID will be used to store/read the expand/collapse states from/to the database.
• How many rows should be displayed of the previous/next page: This setting makes it possible to drag a node (or term, user, etc.) from one page to another. (only makes sense if Items to display are restricted)
• The user cannot rearrange nodes (locked): No drag handles will be shown. Rearranging will not be possible but indentation of subordinated nodes (or terms, user, etc.) will be themed.
• Behavior of new nodes: Self-explaining..

Native handler settings

• Use arguments as well as view ID to order nodes: The views argument will be used to read/write order/parent values to/from the database.
  If any display uses arguments (and defines the "DraggableViews: Order" field; Native handler assumed) all displays (non-"Draggable Table"-style-plugins) will use arguments in their queries too (except they tell us explicitly something else). See #565146: Defined order not respected when Style different than Draggable Table

Pro's and Con's of the Native handler (described on this page)

• + minimum of overhead
• - no compatibility with other modules

If you don't need to use the order/hierarchy values with other modules you should always use the native handler.
Compare with the CCK handler.