Download & Extend

Clone also the menu entry

Project:Node clone
Version:6.x-1.x-dev
Component:Code
Category:feature request
Priority:normal
Assigned:Unassigned
Status:closed (fixed)

Issue Summary

Hi,

it would be nice if a cloned node would get a "clone of " menu entry that was below the same parent menu as the original node.

cu,
Frank

Comments

#1

Status:active» postponed

Hmm, this might not be so hard for 6.x, but I'm really not sure this is a widely desired feature.

#2

Status:postponed» needs review

Hi,

we need that on our site, so I've made menu cloning a configurable option. You can activate "Clone menu entry" at the settings page for the clone module. The patch is conservative in that the option defaults to "off".

Maybe someone else finds it useful :-) It's against 6.x-1.0-beta2.

cu,
Frank

AttachmentSize
clone_menu.patch 2.25 KB

#3

This could even be done a little more simply, though the code looks basically fine.

#4

Just chiming in to say I definitely want this feature, and I hope you'll include the patch in the next release.

Thanks!

Kristi

#5

Given the number of times I clone a menu (one for authenticated users and one for anonymous users) anything that would make that job easier would be a great help. If this feature will make light of this I too would use it.

#6

Any chance you can make this patch for the latest version of the Node Clone module?

#7

Not sure what you mean. The patch applies to the 1.0 and the latest -dev version?

#8

I could not apply the patch. I must check my setup further before I make any comments. Thanks for the getting back to me.

#9

It should be applied in the node_clone/ directory with "patch -p0 < clone_menu.patch"

#10

Bug fix. The menu entry didn't get the module-field set causing problems when re-editing a cloned node.

AttachmentSize
clone_menu_v2.patch 2.24 KB

#11

Forgot to remove two fields from the cloned menu, causing the new menu entry to overwrite the old one (because it the same mlid).

AttachmentSize
clone_menu_v3.patch 2.37 KB

#12

Status:needs review» needs work

Please conform to Drupal standard code style.

#13

AttachmentSize
clone_menu_v4.patch 2.37 KB

#14

see: http://drupal.org/coding-standards

e.g.:

$new_menu['has_children']=0;

You might also want to use: http://drupal.org/project/coder

#15

I'm sorry :-( I AM using the coder module and it didn't return any more warnings for my _v4 version, so I relied on this. My version might be outdated, I will check, and try to work on it manually otherwise...

#16

Ok, coder indeed doesn't find the "x=y" problem, using the latest dev from Jan 21. I was just relying on this, my fault!

I've checked against the coding standards weg page and corrected some indents, the assignments etc. I hope everything is correct now. I'm really sorry about this!

AttachmentSize
clone_menu_v5.patch 2.25 KB

#17

I've re-worked the patch and changed the direction of the menu creation, i.e., I start with a default menu object and fill in only those values that you can enter in the form. I hope this will be more "future-safe" than cloning the existing menu item and resetting those settings that I'm currently aware of. Those "hidden" settings might change more often.

AttachmentSize
clone_menu_v6.patch 2.22 KB

#18

Version:6.x-1.0-beta1» 6.x-1.0
Status:needs work» reviewed & tested by the community

Patch in comment #17 worked great for me. RTBC!

#19

Version:6.x-1.0» 6.x-1.x-dev
Status:reviewed & tested by the community» needs work

Seems like it needs work - for example, you are not unsetting the mlid.

#20

Status:needs work» needs review

Ah, I see - the mlid is 0. Still, menu_link_save() sets all the defaults, so I think we can skip the extra prepare call.

also, terminology is a bit confused - we are cloning the menu link.

AttachmentSize
249668-clone-menu-link-20.patch 3.11 KB

#21

need to add the new variable to hook_uninstall

#22

Status:needs review» fixed

committing this patch.

AttachmentSize
249668-clone-menu-link-22.patch 4.3 KB

#23

Status:fixed» closed (fixed)

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

#24

Status:closed (fixed)» needs work

Hi,

sorry for reopening such an old fix, but I've to admit that I didn't test your patch well enough. At the first glance it seems the menu is cloned correctly because in the edit form the menu entry is visible right after the clone (on the initial edit of the node).

But when you re-edit the cloned page after saving it, the menu entry is no longer shown in the node edit form. It is still a available in the menu edit form, but it has only "edit" and no "delete" link available.

The reason is the "module" column. With the current code, the column is empty for a cloned menu entry. For a newly created node it has the value "menu". Now when I debugged that I remember that I stumbled on this issue long time ago when I wrote the patch. I didn't want to write

$node->menu['module'] = "menu";
because I thought "what if the value ever changes, or there are some other things that must be set?". Therefore I called
node_invoke_nodeapi($node, 'prepare');
trusting that it would set all things like the module column to the correct values :-)

Setting the module column to "menu" manually for a cloned menu entry makes it deletable in the menu edit form and also shows it again in the node edit form. Thus, we must either set

$link['menu_name']="menu";
in your patch, or call the nodeapi prepare code.

cu,
Frank

#25

Status:needs work» fixed

Just saw that you fixed this in 1.3 by

$link['module'] = $old_link['module'];

I was still using -1.2 so I missed the fix :-)

#26

Status:fixed» closed (fixed)

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

nobody click here