menu/menu.admin.inc lets users add or move node menu links to unavailable menus.

Hello anrikun,
This is the normal behaviour.
In the content-type form, if you select the option "provide a menu link", it just means that when you create a new content (for instance page), you are able to add a link in the selected menu.
It doesn't mean that nobody can put a link in another menu to this content.

Moreover, when you use the administrator account, you don't see this, but to proceed the first step you need the "create Page content" permission, whereas to accomplish the step 3, you need the permission "Administer menus and menu items"

Not reproducible in Core. The steps to reproduce aren't even possible without the Menu Admin per Menu module.

@tim.plunkett
Yes that is reproducible in core...
Let me sum up the steps:
1. Create a content type called Page (for instance) and check only Main menu as Available menus.
2. Add a new Page content and provide a menu link. You will notice that Parent item only list Main menu items as options, which is the expected behavior.
3. Navigate to admin/structure/menu/manage/main-menu to list Main menu items and edit the link you just added at 2.
4. Change the parent link for "management"
=>you can check that the link has been removed from main menu and added in the menu management = normal behaviour for me
5. Edit the node and without changing anything click on "save"
=> the link in "main menu" appears again and disappears from the management menu: I agree with anrikun that this behaviour is quite surprising but I very embarrassed for the solution...

My apologies, I must have gotten lost between the OP and the steps in #5.

The menu drop-down restriction is an interface setting for usability, it's not a permission, so this isn't a security issue. It is however an annoying bug so leaving at 'major'. I have a feeling there's an older issue about this, couldn't find it, but while looking I found #949712: When Editing a Basic Page that has a Menu Item on a custom menu, it defaults to being on Main Menu - and deletes a menu item. which was duplicate.

It would be good to update the test so it actually fails without the patch.

I love Drupal 7 so far but this problem is impossible to live with.
As main administrator, I last updated Drupal 7 core on Jan 29th (drupal-7.x-dev)
Every time I update a single word in the body and save, the page disappears from my menu and appears in the secondary links menu.
The only way to move it back is via admin/structure/menu.
This creates endless hassle.
Is there something I do not understand?

Apologies. I found my answer here:

http://drupal.org/node/957784
#4 Posted by marcingy on November 12, 2010 at 10:46pm
Priority: major » normal
No it doesn't the issue is caused by the fact that you have created a new menu and then have not defined this menu as being available for the content type under admin/structure/types/manage/xxx. This results in the menu item being associated with main menu as that is the only menu option that has been available.

I simply had not made all relevant menus available in the content type.

subscribe

subscribe

@anrikun
Just tested the patch from #23 against latest -dev
When trying to change a page (only allowed in main menu) to have the management menu as its parent through the menu administration page, get a notice: "The Management menu cannot contain links to the path 'node/12'."

While this seems better than the original behavior, I still think it would be more user-friendly for non-options not to appear in the parent select in the first place.

The patch prevents a node from being put into a disallowed menu, so it fixes the validation problem.

--- modules/menu/menu.admin.inc	2010-10-20 09:40:59.000000000 +0200
+++ modules/menu/menu.admin.inc	2011-01-21 16:41:08.000000000 +0100
@@ -385,6 +385,19 @@ function menu_edit_item_validate($form, 
   if (!trim($item['link_path']) || !drupal_valid_path($item['link_path'], TRUE)) {
     form_set_error('link_path', t("The path '@link_path' is either invalid or you do not have access to it.", array('@link_path' => $item['link_path'])));
   }
+  elseif (preg_match('/^node\/(\d+)/', trim($item['link_path']), $matches)) {
+    $type = db_query("SELECT type FROM {node} WHERE nid = :nid", array(':nid' => $matches[1]))->fetchField();
+    if ($type) {
+      $type_menus = variable_get('menu_options_'. $type, array('main-menu' => 'main-menu'));
+      list($menu_name, $plid) = explode(':', $item['parent']);
+      if (!in_array($menu_name, $type_menus)) {
+        form_set_error('parent', t("The %menu_title menu cannot contain links to the path '@link_path'.", array(
+          '%menu_title' => substr($form['parent']['#options'][$menu_name .':0'], 1, -1),
+          '@link_path' => $item['link_path'],
+        )));
+      }
+    }
+  }

Let me reiterate webchick's comment from another issue (#955848-23: When editing an existing node with a link, the link itself is listed in "Parent item": menu_parent_options needs some rewriting) -- I'm not sure this level of coupling between menu and node is going to fly.

Also, the usability of the patch needs some work.

While this seems better than the original behavior, I still think it would be more user-friendly for non-options not to appear in the parent select in the first place.

Also, the error message is totally obscure. "The Development menu cannot contain links to the path 'node/9'."

It would at least be a little more transparent if it read something like

The @menu_title menu cannot contains nodes of type @type.

Lastly, is this even a bug? As an admin, I might want to manually move certain pages to certain menus, but then not make it easy for a generic user to do so on the node form.

Powered by Dreditor.