A hierarchy describes relationships between parents and children; since this is a mechanism for classification, the sorting order of children (child nodes) must not be random. E.g. think of the role of the first born child in history of mankind.

In the 6.x-1.x branch these relationships could be arranged in an outline; in 6.x-2.x there is no such mechanism anymore, so the order of children nodes can not be rearranged anymore. If you browse through the "hierarchy" with something like 'Custom Pager', the child nodes are randomly scattered around and there is no way to change this.

I consider this a (serious) bug since the whole reason for a sorting mechanism is to keep things in order. The 6.x-2.x branch doesn't accomplish this anymore, or maybe only under very narrow conditions (if all nodes are put into the menu system, I guess), which don't apply for my use case.

Comments

jonathan_hunt’s picture

jonathan_hunt commented

Dupe, see http://drupal.org/node/624516#comment-3719956

jonathan_hunt’s picture

jonathan_hunt commented
Status: Active » Closed (duplicate)
asb’s picture

asb commented
Status: Closed (duplicate) » Active

Hi Jonathan,

I'm aware of issue #624516, but this one is a different problem. In short, this is about editing the nodes in a node hierarchy; in 6.x-2.x, there is no way anymore to move a node between hierarchical levels; even the local task 'children' only allows to move the direct children up or down (e.g. from position 2 to position 4), not to make the node in position 2 a child of the node in position 4 (like 'Menu' and 'Book' module would allow).

In 6.x-1.x there was an outline mode which allowed that kind of editing; in the current dev release, nou need to edit every node you want to move around, one by one. If you have a couple of hundred nodes in your node hierarchy, you won't have any idea about the other nodes on the same level anymore since there is absolutely no visual represnatation about the structure.

To keep track of you site's structure you basically need to draw the node hierarchy on a large sheet of paper and then start rearranging the nodes. As it currently is, it doesn't help you to build hierarchical structures anymore, but it makes it harder to manage and maintain.

achton’s picture

achton
Location Denmark
commented
Title: How to arrange order of child nodes? » How to arrange hierarchy of child nodes?

Altering the title, I think that makes more sense?

jbylsma’s picture

jbylsma commented
Component: User interface » Drupal/PHP Code
Status: Active » Fixed

Drupal 6.x-2.x hooks directly in with Drupal's menu, so you should be able to easily sort items at /admin/build/menu-customize/primary-links (or whichever menu you are using).

asb’s picture

asb commented
Status: Fixed » Active

@jbylsma: Thanks for the reply. However, you assume that Drupal's menu system is actually used to manage the structure of all (!) nodes of a website, and obviously that is not true for all of us, especially not if the website has more than some dozend nodes.

Drupal's menu system does not scale beyond a few hundred items; if you put some thousand nodes into it, at first the UI becomes almost unsuable slow, and if you drive this further, data structures in the backend start to corrupt (maybe because some operations time out, but I have never understood what the root problem is).

One of the advantages of (earlier versions) of 'Node Hierarchy' was, that hierarchical structures could be managed with this module, that couldn't be handled properly by Drupal core's menu system. If 'Node hierarchy' simply would imitate core functionality, what would be the point of using the module?

Also, 'Node Hierarchy' does neither require nor force the use of the menu system, as far as I know; so I don't consider this issue as fixed in any way. The problems described in the initial issue plus the elaborated notices in #3 still exist for me.

jbylsma’s picture

jbylsma commented

I apologize, I believed your issue was more concerning the organization of child items.

There has been a lot of disappointed over the transition from 6.x-1.x to 6.x-2.x. As you noted, the core issue is that 6.x-1.x maintains the hierarchical relationship independent of the Drupal menu system and 6.x-2.x maintains the relationship within the Drupal menu system. The "nodehierarchy" table, found in 6.x-1.x and below, has been eliminated from 6.x-2.x and higher. The new "nodehierarchy_menu_links" table is only a relationship table between menu items and nodes' nids.

I found a post of Ronan explaining his reasons at #371519-1: Don't save all nodes in the nodehierarchy table. Unfortunately, 6.x-2.x's slow development path (6.x-2.x forked off in May 2008 but didn't have a stable release until March 2011), limited maintenance, and a messy issue queue has further exasperated the issue.

At this point in time, I would not recommend using the module for sites with a "large" number of nodes, which I'm assuming your site is. I've typically used Node Hierarchy on sites with 300 or less node hierarchy nodes, but I know that this doesn't help anyone with an existing site. mcunningham briefly described converting over to using "node reference/views attach/draggable views" in #1319292-5: Performance on node add/edit. With resources divided against Drupal 6 and 7, as well as my limited time and ability to help out with the module, I don't think that this issue will be resolved and the limited nodes will simply evolve into the module's "requirements." I'd be much happier to be wrong, though.

Here are some further issues:
#1402476: Fail to migrate from Node Hierarchy 6.x-1.3 to 6.x-2.1 (or 2.0): which probably was caused by a faulty upgrade process from 1.x to 2.x. I've posted a patch about that at #1552432: Rewritten 6.x-2.x hook_update
#1087016: Failed upgrade from 6.x-1.3 to 6.x-2.x-dev: describing a failed upgrade with scaling issues. Further issues at #1319292: Performance on node add/edit
#576968: 6.x-1.x -> 6.x-2.x Upgrade Path: additional upgrade issues

asb’s picture

asb commented

@jbylsma: Thanks for your elaborate reply; there's absolutely no need to apologize, of course; I'm happy with any constructive comment.

In my use case, I haven't installed 'Node Hierarchy' on actually largish sites (by our internal definition: > 100k nodes), but on one site where we heavily rely on 'Node Hierarchy', we have a lot more than a couple of hundred nodes, and we really have problems with Drupal's menuing system (some time ago, the reason for using 'Node Hierarchy' in the first place was a critical issue in the migration from D5 to D6 which destroyed the book module's hierarchy; as far as I remember, the root cause for this was some kind of integration of the - previously independent - book hierarchy into core's menuing system). Seems like the workaround starts to fall apart, as well.

I'll look into the approach from #1319292-5 as it appears to be a more robust alternative - thanks for this pointer!