Menu attributes displayed even if all menus are disabled for a content type

I can't duplicate this with a core install and the latest menu_attributes code. I posted this in #1093498: 'Menu item attributes' appear suddenly & unwantedly:

"Menu attributes only adds elements inside of $form['menu'] if the $form['menu'] element exists - which it does not when there are no menus available for a content type. So I don't see how there's any problem from the menu_attributes side of the code."

Therefore, I'm marking this as a duplicate of #1093498: 'Menu item attributes' appear suddenly & unwantedly.

Similar issue in D6... the $form['menu'] is somehow set even though there is no menu enabled for this cck. Devel dsm outputs this;

menu (Array, 5 elements)
link_title (Array, 1 element)
#default_value (String, 0 characters )
weight (Array, 1 element)
#default_value (Integer) 0
parent (Array, 1 element)
#default_value (String, 15 characters ) primary-links:0
options (Array, 3 elements)
#tree (Boolean) TRUE
#weight (Integer) 50
attributes (Array, 13 elements)
description (Array, 5 elements)
#type (String, 8 characters ) textarea
#title (String, 11 characters ) Description
#default_value (String, 0 characters )
#rows (Integer) 1
#description (String, 57 characters ) The description displayed when hovering over a ...

I've tried to debug, first disabled http://drupal.org/project/ctm which allows one to enabled/disable a menu per cck. Dis/enabling this module had no effect. I disabled and enabled other menu influencing modules and in my particular case disabling menu translation (part of i18n) resolved this issue. Somehow this module sets the $form['menu'] variable, yet there is no input field generated as this is prevented by CTM.

Maybe it's better not to just check existence of $form['menu'] but to check if $form['menu']['#access'] == TRUE; before adding the elements? This makes it more compatible with other modules and is also a better check IMO.

Please review my patch against 6.x-2.0-beta1

Cheers

Oops forgot to change status!

Let's try again! why can't all these *Nix, Win, Mac line endings just get along :)

CRAP, sorry, forgot again!

Darn line endings... let's check this one!

I am getting the same, enabling at least one menu in the 'Menu Settings' of the content type and everything was working as it should and the fields disappeared from my content type..this only happen as admin, the users did not see the fields appear

I no longer get this same issue when the content type has no available menus marked by changing line 144 of menu_attributes.module

if (isset($form['menu']['enabled'])) {

Thanks, that worked for me.

Ran into this issue today in 7.x-1.0-rc2.

The logic to determine whether to display the links on the node form is:

isset($form['menu']['link'])

For some reason, though I have no menus configured to be used with my a specific content type, the $form['menu'] array has the following values:

Array ( [link] => Array ( [weight] => Array ( [#type] => hidden ) ) )

I'm not sure what's setting that, but it's causing the menu attributes form items to show up in the wrong place, pretty much identical to the photo provided in #10. I updated to 7.x-1.x-dev, but the issue still was not resolved.

After reading this thread, I found that the solution in #11 worked for me, though testing for $form['menu']['enabled'] specifically seems like a somewhat arbitrary check, as that is not a variable indicating whether a menu is enabled, but instead is simply the section of the multidimensional $form array used to build the "Provide a menu link" button. You could just as easily check for $form['menu']['#type'] or $form['menu']['#title'] since those are also set if you enable a menu.

That said, I don't see any reason either of those is better than ['enabled'], so I went ahead and created a patch for 7.x-1.x-dev. If you're using 7.x-1.0-rc2, just do what #11 says.

Here's the patch from #14.

Moving to needs review and the right version so people know the correct status (sorry for not seeing this earlier)