Taxonomy Term Weight & Hierarchy support submodule

I tested this module. This is the first taxonomy patch that handlers hierarchy.

I found one problem. The module does double indentation. This is gone once I removed the following:

/**
 * Implementes hook_preprocess_views_view_table().
 */
function draggableviews_taxonomy_term_preprocess_views_view_table(&$vars) {
    $display = $vars['view']->display[$vars['view']->current_display];
    if(isset($display->handler->handlers['field']['draggableviews'])){
        $order_view = $display->handler->handlers['field']['draggableviews']->view;
        if (!empty($order_view->field['draggableviews']->options['draggableviews']['hierarchy_handler'])) {
            $hierarchy_handler_object = draggableviews_get_handler_class($order_view->field['draggableviews']->options['draggableviews']['hierarchy_handler'], 'hierarchy_handler');
            foreach ($vars['rows'] as $key => $row) {
              $first_column = current(array_keys($row));
              $field = (object) array('view' => $vars['view']);
              $depth = $hierarchy_handler_object->get_depth($field, $key);
              $vars['rows'][$key][$first_column] = theme('indentation', array('size' => $depth)) . $vars['rows'][$key][$first_column];
              $vars['row_classes'][$key][] = 'depth-' . $depth;
            }
        }
    }
}

Attach is the zip file, minus the above code, minus the 5 extra whitespaces, as a patch.

See #1916380: Roadmap to add taxonomy support to module

Confirm that #1 doesn't work but #0, does.... tested against dev branch.

I have no idea how this sub-module works. Or how my view needs to be set up to make this module work.
My view displays the terms of a hierarchical taxonomy "similar" to what it should look. Some terms are in mixed order or child of wrong parent...

Is this module still able to work on the current 2.x-dev head for draggableviews?
Or do I just don't get the point on how to build a draggable view using taxonomy weights and parents?

@guedressel I've had success with this patch, however, mostly due to the fact that it's a standalone sub-module, as opposed to actual changes in the original draggableviews module itself. Just drop in the sub-module and it'll work with a couple notices which are trivial to fix (not checking whether term has parents before accessing key).

Sorry. This module is not working for me.
Views result have the rows not sorted correctly.
Depth is correctly calculated, but without correct row order of the view result everything looks messed up.

Maybe you have an example view-export to show me how it would work?

@guedressel: I was able to make this work.

Dependencies
* draggableviews-7.x-2.0+56-dev (latest -dev)

Setting up view
* Enable Taxonomy Administration view (from https://drupal.org/project/admin_views‎)
* Add draggableview field
* Set Sort handler > Taxonomy Term
* Set Hierarchy handler > Taxonomy Term

Exported view is attached. Hope this helps.

(disregard these attachments, instead see the ones in next post)

I added sorting of the rows in post-execute hook, attached is the result as a patch and as a zip.

It would not work with pager.

Also, I've not spent time figuring out the view variable structure, so I am not sure if there are cases where $view->field[X] is different from $view->display[$view->current_display]->handler->handlers['field'][X] or why this round-about way of accessing the field was deemed needed in the original preprocess implementation, but I've kept it.

There are still places in the code where use of $something->tid is hardcoded that should probably be replaced with $something->{$field->field_alias} for this to work when the draggableviews field is set to use some secondary relationship, etc. It works as is for the straightforward case though.

Since the changes from #1 are kept and the "(almost) duplicate" preprocess is removed in this version, you have to add the draggableviews sort handler in order to trigger the hierarchy preprocess from the base draggableviews module. If you use other sorts as well, you should probably add it last, and also add a sort by taxonomy term weight.

Oops, in the above version I had messed up the sorting, here is the working one.

One more small fix

@georgir: Thanks for your work.

This patch is a rewrite of the patch in #13. It adds required term properties directly to the view query, instead of making an extra query to retrieve the hierarchy. It removes the relationship with the draggable structure and modifies the sort handlers.

It fixes the way to sort the view result, which was not correct.

I tried to simplify the code and to stick to the Draggable Views module way. There are a lot of code comments to explain my choices.

Tested with some multilevel hierarchy successfully.

Notes:

• It will not work with term having multiple parents if the "distinct" clause is not present (this should be specified in a README file probably).
• It so, only the first parent is taken in account, but the other parents are not lost on save.
• This may not work correctly with a pager, when the first term of the page is not a root term
• Extending DV would be easier if the join handler made a call to a "make join" method of each draggable handlers (if going this way, I could open a feature request)
• Same remark for the sort handled

For the problem of handling hierarchy with a pager, it seems to be a global issue with DV, isn't it? I found some issues about that.

Handling paging is a known problem with hierarchy. Hierarchy adds complexity as you can cut a hierarchy off.

@iStryker: OK, I confirm what I thought. So the pager issue is not specifically related to this taxonomy handler and my related remark in #14 can be ignored.

The patch below fixes a small bug when the order option is not defined in the field definition.

Use to get several warning and errors, by applying #17 all those errors and strange behaviors are gone and it works very well now :)
Marking it as RTBC
Tx @B-Prod

#17 works amazingly. This is by far the best out of all of the taxonomy related solutions. Hierarchy works out of the box as well. Thank you!

I found a pretty big incompatibility for users that do not have permissions to edit the Taxonomy terms. For those users, none of the terms are shown and neither is the drag markers. By default, terms should still be shown, just not the edit links.

The following notices are shown on the page:

Notice: Undefined index: draggableviews in draggableviews_taxonomy_term_get_draggable_field_from_view() (line 100 of /var/aegir/platforms/drupal-7.51/sites/SITE/modules/draggableviews/draggableviews_taxonomy_term/draggableviews_taxonomy_term.module).
Notice: Trying to get property of non-object in draggableviews_taxonomy_term_get_draggable_field_from_view() (line 100 of /var/aegir/platforms/drupal-7.51/sites/SITE/modules/draggableviews/draggableviews_taxonomy_term/draggableviews_taxonomy_term.module).
Notice: Undefined index: draggableviews in draggableviews_taxonomy_term_get_draggable_field_from_view() (line 100 of /var/aegir/platforms/drupal-7.51/sites/SITE/modules/draggableviews/draggableviews_taxonomy_term/draggableviews_taxonomy_term.module).
Notice: Trying to get property of non-object in draggableviews_taxonomy_term_get_draggable_field_from_view() (line 100 of /var/aegir/platforms/drupal-7.51/sites/SITE/modules/draggableviews/draggableviews_taxonomy_term/draggableviews_taxonomy_term.module).

Actually modifying the weight and parents of a term need the "edit" permission, as those 2 are term properties that are only editable on the term edit form.
So users without the "edit" permission should not be able to reorder the tree.

How did you get these notices?

In this case the notices appear automatically when viewing the views page without draggable access permissions.

I managed to fix the notice. Attached is both the patch and the interdiff. Please review.

#23 still applies cleanly against the newest dev.

#23 Indeed still works fine with latest dev version :)