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

> do you happen to be using Revision Moderation (or something similar

No, it's a pretty vanilla and so far static "corporate brochure" site, pathauto and path redirect, Menu Trim (I think I mentioned), and some admin modules - Admin menu/dropdown, Devel, DB admin.

Next time I'm working on the hierarchy I'll play with it some more, apologize in advance if I just missed a caching issue. . .

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:

to:

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:

A bit farther down, I see this:

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:

to:

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

to:

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:

I removed that and replace it with:

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...

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. :(

Automatically closed -- issue fixed for 2 weeks with no activity.

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?