Menu order changing when nodes are edited

It seems odd, because it *kind of* affects menu weights--at least, for the short term, as far as I can tell. When we rearrange items, they change on the next refresh, but then when a node is edited, the menu order changes, so it must not *really* be affecting the menu weight.

Isaac

Rearranging children should alter their menu weights. The ajaxiness of the outliner means that the menu will not reflect that immediately (I could in theory reload all menus on each click, but that would be quite complicated and would slow down rearranging somewhat). You should see the new menu order next time you refresh (as you say you are)

Menu order getting changed after a node save is not desired behavior however. Can you describe this a little more? Step me through the process. Does the menu order get out of sync with the child order? Does the child order change unexpectedly? Does the menu order revert to some previous state?

Thanks
Ronan

I can try to track down some details. Not sure if I'll have time today, but I'll do my best.

Hey all -

hansBKK, do you happen to be using Revision Moderation (or something similar--I'll get to the reason shortly)?

I've been testing a bit and on this issue. I've built a view to show the NH sort order value of all children, and have a function in template.php to show my menu weight.

Here's what I do:

1. Go to "children" tab and sort the way I want things. For example, I move "Item A" around.
2. Refresh the page / go to another page in the section / whatever--to see the results. The menu shows up in the order I intend.
3. Check the "children" tab to see my NH sort order value. It's as expected.
4. Edit item A and save.
5. This seems to be key: My revisions are in moderation, so I publish the revision. Up to this point, the order stays as I left it in the children tab. After publishing the revision, my NH sort order value is changed from what it was to the highest value, as is the menu weight.

It appears that, if revision moderation is off for the node that's moving around, editing the item and saving it does not change the NH sort order value, leaving it the way I put it in the child tab. :p Not sure what all that means, and I don't know if I described the problem right or not, but it might be a good direction to try.

Isaac

---Edit---

By the way, I may be seeing things. I don't think so, but it's possible. So if someone in a similar situation could verify, that'd be great.

Any word on this? I did a little digging around, and it looks like the guys working on the location module also had some data loss issues that they've fixed in the Location 3 (still in development.) Out of curiosity, if NH sees an empty value for NH sort order, does it automatically assign it the highest value? 'cause that would seem to make sense with what I'm seeing...

Thanks,

Isaac

Hmm... Maybe I am just crazy, then. Maybe I can set up a test site some time and build till it breaks.

Has anyone else seen this / found a solution? I'm still trying to track it down, but haven't had much luck.

OK, I've tracked down some stuff and it seems that, for some reason, the line:

$node->order_by = 100000;

is being called (in function nodehierarchy_insert_node). I think that's because $node->old_parent is always empty. I'm a little confused about what $node->old_parent is, but this seems to be what's causing my problem. The whole "menu items seemingly reordering themselves" is causing some pretty major headaches, and I'm happy to help resolve it any way I can. Help?

Thanks,

Isaac

OK, my particular version of the issue is definitely related to revision moderation. When a page is first saved (but it's in moderation), node->old_parent is equal to node-> parent, so nodehierarchy_insert_node doesn't do anything. However, the new revision is in moderation, and when the new revision is reverted / published, node->old_parent is empty on the reverted node. This means that nodehierarchy_insert_node runs, the order_by variable is pumped up really high, and the node's menu weight is pumped up as well, dropping it to the bottom of the menu.

I'm pretty well out of my league digging at this point, but it looks like this happens because old_parent is set in nodehierarchy_nodehierarchyapi, in case node_form, which isn't called at all during publishing of revisions.

So, I think I've got at least an understanding of what's happening. But I have no idea how to fix it. If anyone can lend further insight or a fix or anything, that'd be great.

Isaac

I'm trying to figure out how to stop the nodes from jumping to the bottom upon submission of a revision as well. I'm really struggling, here. Anyone made any progress on this?

I'll look back at what I ended up doing in the morning and report back in. I got it working, as long as I didn't use Revision Moderation's "Publish this revision" link, just the "revert" link on the revisions tab. Has something to do with the form creation and such.

Isaac

I'd appreciate it a lot. Many thanks!

I've actually disabled revisions entirely and the node (Page, in this case) is still getting pushed to the bottom of the menu on any edit. I can actually see how it is doing it in the code, but I can't figure out how to stop it, even while wielding many //'s.

What ended up working for me was to edit nodehierarchy.module. Around line 280, in function nodehierarchy_nodehierarchyapi, I changed:

    case "update_parent":
      nodehierarchy_insert_node($node);
      _nodehierarchy_create_menu($node);
    break;

to:

    case "update_parent":
      if($_POST['op'] != "Revert") {
        nodehierarchy_insert_node($node);
      }
      _nodehierarchy_create_menu($node);
    break;

It worked in my situation, but if you're not doing revisions, that might not solve your problem. The issue seems to be that if old_parent doesn't get set when the form is updated (on line 245), then the parent and the old_parent aren't equal, and NH thinks that it should change order_by and then normalize it around 325.

I'm just telling it that if it's reverting, not to call the insert function. There's some reason I did it the way I did, but I didn't do a good job of documenting it.

I kind of wonder if old_parent should go into the DB. I hate extra DB calls as much as the next guy, but I think this would resolve the issue and would do it in such a way as to make NH more future-proof / other-module-proof. But I don't have the coding chops to do it.

Hope that helps. If you make any more progress on this, I'd love to hear about it.

Isaac

Well, I intend to use revisions, so that helps a lot. It definitely fixed the problem that I've been having and I'll continue working with this solution until an official patch is available.

My many thanks.

I agree with all of your sentiments about storing the old_parent id. Unfortunately, I'm in the same position. Not quite experienced enough, yet, and working on a site that doesn't have time for that kind of development until we get a beta rolled out for internal testing.

Again, thank you very much!

Wellllllll now it isn't working again. I didn't change anything. I'm convinced that I thought it was working before but must've tested the wrong thing.

Here's the problem: Whenever I edit a node that already exists, it re-adds it to the menu, thus sticking it at the bottom. It does this, presumably, to enable the title to change (guessing here), but there isn't a good way to fix it that I can discern. The problem exists regardless of revision use.

Any thoughts?

AAAUUGGH!

I'm having the same problem. I think I've tracked it down to this module. My main menu weights keep getting set to 180, 193, 181 and 190 for some bizarre reason. I'm not sure why; I can even change them directly in the db and they change back as soon as I save a node, even if it's not a content-type I've enabled hierarchy on. I've tried clearing the cache beforehand, the whole nine yards, and I have no idea why it's happening! It's not related to node revisions for me, because I have optional revision-saving and I haven't been using it (I'm pre-production).

Sorry, didn't mean to make it 'critical.'

Ok, I did some work on this - it seems that every time you save a node, "rebuild menu" is getting triggered (even if it's not checked.) The module rebuilds the menu back to whatever order the nodes are in in the hierarchy (ie: when they were added, for top-level nodes). In and of itself this makes total sense, but I hadn't been able to reorder my top-level nodes because Site Outline isn't working for me. To fix this in the meantime, I went in and changed their order manually in the nodehierarchy table to match the order my menu items are in.

I have also encountered this problem, originally in Drupal 6.2 and then in a clean install of 6.6. I wasn't sure what module was causing the problem so I started by creating a test menu, adding a node (no problem), enabling Nice Menus, adding a node (no problem), enabling the FAQ module, adding a node (no problem), and then adding Node Hierarchy. As soon as I edited an existing node to assign it to a parent, the order of my top-level menu items changed. I can put them back in order, but if I create another piece of content--even if it's a content type that doesn't have a default place in the hierarchy and I don't assign one--they go back out of order.

The strange wrinkle in my case is that the top-level items do not appear in the order they were added; the page generated by the FAQ module, which I added last, is first.

It looks like I can try the solution in #20, but that doesn't seem very convenient for long-term maintenance...

Solution 20 apparently Works for Me™. I have no clue what's going on in the code, but the menu weights of all nodes with a parent of 0 were being reset to the order by field in the nodehierarchy table, with 1 having a weight of -10, 2 was -9, etc. no matter what type of content I was adding. Additionally (and I have no idea if this is by design or not) any content I added, whether or not it was hierarchy enabled, was added to the nodehierarchy table with a parent of 0. Menu items that were not content (the contact form, the front page, and a link to an external site) did not have their menu weights altered.

I have only one cck content type that's hierarchy enabled, with a cloned hierarchy_child_list that only has title information changed embedded as a field. It also has a menu, body and title, but no other custom fields. Since I only wanted the top level of each hierarchy I was creating in my primary menu, I was creating all menu field entries for each top level node by hand, and never selected recreate menus in the nodehierchy fieldset.

As a test, I added a page (which is not hierarchy enabled), then tried to add it to the menu via the menu fieldset on it's edit page, and give it a weight of -15. It was forced to a weight of -5. It had a parent of 0, and it's order by number was 6 which makes that -5 correct, relative to it's order by weight (the node with parent 0 and order by 1 was weight -10, as reset by the nodehierarchy module).

Thanks for checking this out, I'll try to get a fix up as soon as I get a chance.

R

I'm having the same/ a similar issue.

I have NH enabled on a content type. If I edit any node of ANY content type my menus all get reordered. Disabling NH resolves the issue but I need to use it for a section of my site. Is a patch imminent for this problem?

Cheers

D

I too am having this problem.

Every time I rebuild the menu from the node, the Drupal menu system gets overwritten with whatever is in the nodehierarchy table. This definitely should not be happening for root level menu items because there is no way to manage their order through the NH interface as far as I can tell.

Making matters worse, changing the order of child nodes on the Children tab doesn't have any affect on the Drupal menu system, but it is change the nodehierarchy.order_by field.

Can we change this priority to critical? It's a show stopper for me and I would assume it is for others.

THANKS!

I think I got to the bottom of the issues that were plaguing me and some of the others in this thread. Be very careful with these instructions and this patch. While fairly decent with PHP, this is the first time I have seen NH's code and I don't know if it might break something else.

NOTE: THIS PATCH IS VERSION 1.1 - NOT DEV! THEREFORE, I HAVE CHANGED THE VERSION OF THIS THREAD TO 6.x-1.1. I HOPE THE ONLY BREACH OF ETIQUETTE I AM MAKING IS SHOUTING!

I have three nodes: Page A0, Page A1, Page A2 which are all children of Section 1. I was having problems with the reordering of the nodes on the Children tab not being reflected in the menu when navigating away from the page. I was also having the familiar problem of having the the menu items change when rebuilding the menu item. I have addressed both these issues.

I kept a log while making changes so that I could retrace my steps. All of the code changes in the log are in the patch file attached. Here are the gory details.

In function _nodehierarchy_create_menu, $item assumes the $node->menu array. The array looks like this:

Array
(
    [delete] => 0
    [mlid] => 541
    [module] => menu
    [hidden] => 0
    [has_children] => 0
    [customized] => 1
    [options] => Array
        (
            [attributes] => Array
                (
                    [title] => Page A0
                )

        )

    [expanded] => 0
    [parent_depth_limit] => 8
    [link_title] => Page A0
    [parent] => primary-links:535
    [weight] => -50
    [plid] => 535
    [menu_name] => primary-links
)

A bit farther down, I see this:

$item['weight']   = $node->order_by - 11; // Editable menu weight range used to start at -10.

What is code trying to achieve here? What's interesting is that there isn't a $node->order_by value in set - so $node->order_by is essentially 0 and so the result of the above equation is -11.

Where weight was -50 in my menu, it's now -11

Before I updated my node (Page A0) with "Recreate Menu" checked, the order of my menus was:

Page A0, weight: -50
Page A1, weight: -49
Page A2, weight: -48

After the update, my menu_links table shows this:

Page A1, weight: -49
Page A2, weight: -48
Page A0, weight: -11

This order is reflected in my navigation. So why is Node Hierarchy mangling the weight? Simple removing that line of code gives me the desired result. (I feel odd just removing a line of code that had to have been put there a reason!)

So, now for the issue where clicking on the up/down arrows yields no changes in the menu_links table -- the Drupal menu table.

The function _nodehierarchy_set_menu_order seems to have a logical flaw for what I want it to do. I don't quite understand the explanation at the top of the function, but I have observed that menu_link_save() is never being executed because if ($child_menu = _nodehierarchy_get_child_menu($nid, $parent_menu['mlid'])) results in FALSE.

Why? Well, it looks like we're passing the wrong variable. _nodehierarchy_get_child_menu is not expecting mlid as the second argument - it is expecting plid!

Changed this line from:

if ($child_menu = _nodehierarchy_get_child_menu($nid, $parent_menu['mlid'])) {

to:

if ($child_menu = _nodehierarchy_get_child_menu($nid, $parent_menu['plid'])) {

Problem is that $parent_menu doesn't have plid. This required me to alter the query in _nodehierarchy_get_menu() from:

return db_fetch_array(db_query_range("SELECT mlid FROM {menu_links} WHERE link_path = '%s'", "node/$nid", 0, 1));

to:

return db_fetch_array(db_query_range("SELECT mlid, plid FROM {menu_links} WHERE link_path = '%s'", "node/$nid", 0, 1));

Now I can see the mlid ID coming back which can now be passed to _nodehierarchy_get_child_menu() per code change above.

That if statement is now evaluating to TRUE and we're able to update the links. However there are some more changes needed. The same "-11" equation is in this if block:

$link['weight'] = ($order_by-11);

I removed that and replace it with:

$node->nid = $nid;
$node_additions = nodehierarchy_load_node($node);
$link['weight'] = $node_additions['order_by'];

The nodehierarchy_load_node() function already exists and it is expecting the node object so I need to set it just before calling the function. Then we need to set the order by to the link weight.

When testing I discovered something obvious -- that changes in the sort order of children in the menu administration screen would not get reflected in the Children tab because those sort orders are in different tables. Therefore, anytime we load the Children tab, we need to update the nodehierarchy.order_by field with the corresponding value from the menu_link.weight field.

We can do that in the "load" case in nodehierarchy_nodeapi(). I quickly found out that anytime you click on the up or down arrow, an AJAX call occurs and the "load" case is hit. We definitely don't want to load in menu_links weights when trying to update the order - it will simply overwrite our changes. That's why will see a substr() function to see if the term "ajax" is in the q value. You will also see a new function that I added to handle setting the nodehierarchy.order_by to the menu_links.weight value.

GOOD LUCK!

Forgot to change the status.

I've tested this patch and it does fixes some a some of the of problems.

What it appears to fix:
1) editing a non-menu node doesn't mess up the menu order (thats great as it makes the site usable again!)

There is still some problems it doesn't address and that is:
2) when you edit a node that is part of the menu it loses its menu order and ends up at the bottom of the menu
3) when to reorder a node on the site-outline it changes all the menu weights for nodes, which means that menus that aren't nodes aren't updated. For example if you have a menu linking to "contact" for the contact modules page, what happens is contact page suddenly becomes at the top of the menu and all the other nodes are underneath (at least this is whats happening for me).

I don't really care about (3) that much, but (2) is definitely a problem and means you can't edit a node without having to re-order the menu.

I think when you update a node it should only need to do any re-ordering if you change the parent node, since it is very rare that I need to change the parent node I have just disable the nodeapi update function and if I need to update a node parent I can just manually re-order the children later.

So this is my fix, but may introduce other problems for people...

/**
 * Implmentation of hook_nodeapi().
 */
function nodehierarchy_nodeapi(&$node, $op, $teaser = NULL, $page = NULL) {
  switch ($op) {
    case 'fields':
      return;
    case 'insert':
      nodehierarchy_invoke_api("update_parent", $node);
      break;
    case 'update':
      break;
    case 'load':
 

What about v5.x-1.2?

Yes, I am using 5.x-1.2 and am having similar problems. When some nodes on our site are published, the menu order resets itself to some other state. We are also usign revision moderation tools as well.

There is still some problems it doesn't address and that is:
2) when you edit a node that is part of the menu it loses its menu order and ends up at the bottom of the menu

Odd, I can't reproduce the problem with my patch. Maybe there is something else you have on/off with regard to menus that is not the same as my environment?

3) when to reorder a node on the site-outline it changes all the menu weights for nodes, which means that menus that aren't nodes aren't updated. For example if you have a menu linking to "contact" for the contact modules page, what happens is contact page suddenly becomes at the top of the menu and all the other nodes are underneath (at least this is whats happening for me)

Ah, I didn't test with anything that isn't a node. The fact is, all of my pages are of type "Page" and then I embed things from there -- views for example. Using the Insert View module makes it easy for clients to update text before or after a view without having to trust them with updating a view - which is a very intimidating screen. I think you can also embed the contact form as well. Not exactly a solution, but rather a way to avoid the situation altogether while getting some other benefits.

Patch #26 by capellic does work for me, but it breaks updates functionality. I included the missing lines in a new patch

Sorry double post

Menu order(for third level) still changes when editing a parents node

subscribed

Even with the patch(s) my menus are still re ordering themselves when I edit a page/node content
Note: it does not happen when I disable Node Hierarchy mod.

Does anybody have a real fix for this?

Maybe this patch works for you
Added update handling

thank you for the patch ... I decided to not use the node heirarchy module and that fixed the menu issue.

I've made some changes to how menus are updated which may help with some of the issues listed above. I have yet to track down the Revisions incompatibility but am on the case.

Could anybody experiencing menu issues try the latest dev (5 or 6) and let me know if it fixes your issues?

Thanks
Ronan

I've tried the latest 6.x-dev and it seems that the menu problems has been solved. Great work!

Great. I'll mark as fixed then unless somebody else weighs in against.

Thanks again all
Ronan

Mhm sorry but the problem seems to existy in my case.
I've installed the newest version, but when I run the update Script for example, the order is getting crashed. :(

Yeah, I thought I had noticed this as fixed on my site for a time, but now I'm having problems again. I don't have time to do any debugging at the moment, but just wanted to re-open this issue.

I'm encountering the same problem as capellic. I updated to the latest dev version as of 3/20/2009. When "Create Menu Items" is set to always, it seems to rebuild the menus when you edit content. To solve this, I just changed to Options -- Default to Yes. The menu order does not seem to change anymore.

To fix this you should prevent node hierarchy from rebuilding the menu when editing a node. This can be done by setting "Automatically create menu items": to "Optional - default to no" for the used contenttype in the setting screen.

This will disable menu generation. If you want to change the menu you can add menu items en re-arrange menu items in the menu settings screen.

Hmmm....
I have many sites running an almost idential configuration includeing node hierarcy. Suddenly, one of them started behaving like this, reordering nodes when they're edited. And, not even that, the parent node has it's weight automatically changed when editing a CHILD node and saving (I don't understand this at all)...

I even tried updating to the 6-2.x dev version and the problem persisted.

I've tried many different approaches but it's still happening. Just wanted to throw in my 2 cents that this issue hasn't gone away.

Ok, I did a bunch of work trying to track down this bug. I think it MAY have something to do with revisions. None of my other clients use revisions, but the one problem client WAS using them, and it appears that when a page with a revision was edited, it messed up the menu order.

Hopefully this insight helps find the bug....can anyone else confirm this?

Ok, forget my last post. It's now happening on nodes other than revisions. This is driving me absolutely crazy...any thoughts on the cause? It seems like the 'create menu items' setting is stuck on "always" or something....

struggling with kinda this too in 6.x-1.2
no node revisions here

when rearranging child nodes of top node, menu position of the top node changes to last.
in menu_links table, weight is now -11

i think i wont be able to further debugging as i stop using nh for now

I'm going to upgrade this to critical. Those of us experiencing this issue are not able to use this module on a site.

Also, just a note which is possibly related: Now, even on a fresh install, the latest version of NH (6.x-2.x-dev) is creating menu items even when "Show item in menu" is set to 'never'. Now, the items are NOT being 'shown' in the menu, but they are being created in the menu system (as disabled items). Not sure if this is expected behavior, but this autocreation/generation of menu items when set to 'never' seems to be the cause of menu reordering as well (ie. it regenerates/creates menu items and sets their weight when we don't want them to).

Hopefully this is another helpful piece of info....

Is anyone not currently experiencing this problem? If there were criteria by which it could be avoided, at least we could implement a workaround while we wait for a fix to arrive. This is pretty much a dealbreaker for Node Hierarchy, but a lack of a way to unify menus, breadcrumbs and paths is pretty much a dealbreaker for Drupal--for my clients at least.

No revisions here, if it helps. Drupal 6.14, NH 6.x-1.2.

Something else I've found that may help others. On the site I was having this issue with, i found a mixed use of 2 ways of creating menu items: Node Hierarchy for menu items and the standard Drupal menu input (under "Menu Settings" on each node's edit screen). This mix-use of different ways to add items to the menu may be causing issues of some kind.

@Rob_Feature #53

Good point. The Menu Settings fields show up on my node edit form in addition to the Node Hierarchy fields. At first glance, I can see how these may conflict, but I never use the Menu Settings fields so I would *hope* that the values would never be considered. (But maybe instead it's grabbing the default weight of 0?)

Did you find a solution to this?

Okay, after a few days of digging into the code, I think I have solved this mystery. It's at least solved for my site... I would appreciate if you guys would try my patch set and see it solves some of your issues. If you want to chat about this, you can find me on AOL instant messenger as gwgengler most work days. (I'm in US/Central time zone.)

Note that my patches are against version 6.x-1.3, 2009-Nov-03.

What is happening when the menu order changes is that there is a synchronization problem between the order of peer nodes in the Node Hierarchy table, and the order of the corresponding menu items in drupal's menu system. Because the sequences are out-of-synch, you see bizarre behaviors all over the place. And things can get even stranger because NH doesn't restrict its menu management to nodes that can be in the hierarchy.

For a given parent node (NID), you can check if things are out of synch by executing a few Mysql queries.

What Drupal thinks:

select m2.link_path,m2.link_title,m2.weight from menu_links as m1 join menu_links as m2 on m2.plid=m1.mlid where m2.menu_name = 'primary-links' and m1.link_path = 'node/NID' order by weight;

What Node Hierarchy thinks:

select nodehierarchy.*,node.title from nodehierarchy join node on nodehierarchy.nid=node.nid where node.type='page' and parent=NID order by order_by;

Once things get out of sync, the quickest way to fix things is to use the up or down arrows on the Site Outline or the CHILDREN tab of the parent node. When you change the position of any child node, NH will attempt to renormalize all peer nodes in the NH table, and bring the drupal menu items back into synch. It sometimes fails to do so, however.

I believe the changes I've made in the module code help NH to do the right thing, most of the time. Here are the functions I've modified, and a short explanation of what I've done:

---------------------------------

function _nodehierarchy_create_menu():
// Editable menu weight range used to start at -10.
$item['weight'] = $node->order_by - 11;

I see no reason for subtracting 11 from the NH order_by value to get a menu weight. It messes up the position of nodes you update, and causes much confusion. I have removed the -11, but left the weight setting, which is important for keeping updates from altering a node's position among its peers.
---------------------------------

function nodehierarchy_insert_node():

If an existing node is updated, and the parent does not change, the order_by property is never added into the node. If the user has selected "Recreate Menu", the menu item is recreated with the wrong weight.

My fix is to add a simple elseif clause that sets up the order_by property:

elseif ($node->nid && (@$node->old_parent == @$node->parent)) {
/// if we have a valid node, and the parent has not changed
// load up the order_by field, in case it is needed for later operations
$additions = nodehierarchy_load_node($node);
$node->order_by = $additions['order_by'];
}

--------------------------------------------------
function nodehierarchy_get_children():
function _nodehierarchy_normalize_child_order()

In both of these functions, no distinction is made between nodes that are managed by node hierarchy and those that are not.

This causes major problems when you work at the top of the hierarchy. Here's why. Node Hierarchy creates a record in its table for every node in the system, and the default value for the parent column is 0, which means the top of the hierarchy. I have a site with 500 pages, and I have told Node Hierarchy that pages can be parents and children. I also have several thousand other nodes.... news articles, job posts, event calendar items, etc.

All of these other "unmanaged nodes" are set to parent=0, because that's the database column's default value. So they are peers of the top-level pages of my site. When I tell NH to reorder the top-level pages of my site, it causes several thousand queries, and messes up the normalizing of peer page order because all these unmanaged nodes are assigned slots in the sequence. Aack.

We can leave the debate about whether NH should put a record in its table for every node in the system for a later time. That seems strange to me, but I can see how it might be helpful.

If it is going to do this, however, I believe it should do everything it can to avoid modifying nodes it is not supposed to manage.

I have fixed this by creating a new function modeled on _nodehierarchy_get_parent_types, which returns a combined array of all content types that can be either a child or a parent.

And I have modified the queries in nodehierarchy_get_children and _nodehierarchy_normalize_child_order so that they restrict their work to the NH-managed nodes.

Wow... thanks for taking a stab at this. I tried with a patch of my own, but it fell short. I have applied your patch to a dev version of a very small site that I have.

I am pleased to report that when I edit a child node and check "Recreate Menu", the node remains in the right order in Drupal's menu system and is in sync with NH's order -- awesome!

As for the top level nodes, I checked "Recreate Menu" for a top level node and it threw it at the end. Uh oh. But if I read between the lines of your write-up, maybe the fact that my patch was added to an existing site is the problem -- that I need to recreate all the top level nodes to get them on the same footing and YES... that did it!

This is working well for me -- curious to get some more feedback on it.

I just deployed it on a site with more nodes and parent/child relationships.

It works, but there's a hitch. It seems that the first time that a node is saved with it's Recreated Menu checkbox checked, it gets moved to the bottom of the menu. I put the node back in the intended order in the Children tab and then edited the node again, once again recreating the menu. This time the node's menu item stays where it was! And the third time, too.

So then I went to start this process with all of the node's siblings -- but those didn't get thrown to the bottom of the menu -- interesting -- so it appears that you only have to go through the above process once per generation?

So, I think there is a data issue get gets cleared up? If this was a new site, adding nodes for the first time, I suspect I'd never see the issue? Anything to add to this, garretg?

Thanks for testing, Capellic.

Indeed, if you are trying my patch on existing node hierarchy items, you might see some wonky behaviors at first that you wouldn't see if you started fresh.

You can see exactly what is happening for a given parent node with the sql queries I included... (although I just noticed that you may have to alter one of the queries to change 'page' to whatever content type(s) you are putting in the hierarchy.)

I might be able to write a cleanup routine that locates and automatically fixes out-of-sync hierarchy levels... but until that's done, the fastest way to bring NH and the drupal menus back in sync is to use the CHILDREN tab for each parent node. Just click on CHILDREN, and move any child up/down in the peer order, then move it back.

After you do that, you can re-issue the sql queries and confirm that the NH and drupal sequences are in sync.

Okay here's another query that might be helpful for clean work...
select parent,node.title from nodehierarchy join node on nodehierarchy.nid=node.nid where node.type='page' and order_by=0

On my site, this query finds any parent nodes with out-of-sync hierarchies. It works because, with my patches, NH will (almost) always set the order_by column to a clean sequence of integers, starting at 1.

10 days without weirdness.. that's as good as stable when it comes to this problem. Can we get this rolled into a 1.4 release?

For me, what I really needed to do was make sure the ordering within the Node Hierarchy was the same as the ordering I wanted in Drupal's menuing system. Then, when I updated the parent node, it didn't change the order of the menu at all. I wouldn't have figured it out without garretg's detailed thoughts and comments, though.

Thanks everyone for your hard work on this. I've committed this patch with some minor code style cleanup. I also added back the -11 to the create weight. I'll take this out if it really does seem to be causing issues, but I've always left this in there because even though it is no longer needed, removing it will reorder new menu items compared to preexisting ones. That's probably what's causing the reordering issue described in #57.

If there's a desire to remove this for the sake of simplicity and consistency, then I'd like to add an update hook to adjust previously synched data so that people who update aren't surprised next time they save a node.

Thanks again all.

Seems like I may be experiencing this problem. I just updated to drupal 6.19 and node hierarchy 6.x-2.x-dev (2010-Aug-27). I can not change the order of children on my primary parent, but can on my 2nd parent. I can not add new children to my primary parent, but can on my 2nd parent. When I save, my new children loose their primary parent and the 2nd parent becomes the primary parent.

I think this started about the time I upgraded to drupal 6.19.

Please don't add to an issue related to a different problem of a different version of the module - especially when you already have another issue open. I understand that your problem is happening, but Multiparent didn't exist in 6.x-1.x, which is what your already-open issue is about. If you feel that this issue is related in some very specific way, please note that in that issue. And please, please, don't add to other issues without noting that you've already opened something for the problem you're describing.
#895828: Can't resort children for primary parent
Further progress on your issue will be in your issue queue.