Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
I created a node type with no "available menu" so it can't have a menu item. Then if you add or edit a node of this type the menu attributes form is shown in a broken way.
Expected result: menu_attributes should not alter form for node type having no available menu.
This issue may be responsible for this #1093498: 'Menu item attributes' appear suddenly & unwantedly
( possibly related to either i18n or nodeformcols module as they were installed when having this issue, I need to investigate a bit further )
Comment | File | Size | Author |
---|---|---|---|
#15 | menu_attributes-no_menu_set_fix-1128510-15.patch | 643 bytes | SeeWatson |
#10 | menu atriibutes.png | 74.45 KB | dwalker51 |
#8 | menu_attributes_access_check.patch | 763 bytes | Bartezz |
#5 | menu_attributes_access_check.patch | 768 bytes | Bartezz |
#2 | menu_attributes_access_check.patch | 776 bytes | Bartezz |
Comments
Comment #1
Dave ReidI 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.
Comment #2
Bartezz CreditAttribution: Bartezz commentedSimilar issue in D6... the $form['menu'] is somehow set even though there is no menu enabled for this cck. Devel dsm outputs this;
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
Comment #3
Bartezz CreditAttribution: Bartezz commentedOops forgot to change status!
Comment #5
Bartezz CreditAttribution: Bartezz commentedLet's try again! why can't all these *Nix, Win, Mac line endings just get along :)
Comment #6
Bartezz CreditAttribution: Bartezz commentedCRAP, sorry, forgot again!
Comment #8
Bartezz CreditAttribution: Bartezz commentedDarn line endings... let's check this one!
Comment #10
dwalker51 CreditAttribution: dwalker51 commentedI 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
Comment #11
dalberts69 CreditAttribution: dalberts69 commentedI no longer get this same issue when the content type has no available menus marked by changing line 144 of menu_attributes.module
Comment #12
jberg1 CreditAttribution: jberg1 commentedThanks, that worked for me.
Comment #13
idflood CreditAttribution: idflood commentedI tried to replicate the issue I posted in #0 with i18n and nodeformcols. With drupal 7.15 and current release of all modules the issue is gone, now everything works as expected.
Comment #14
SeeWatson CreditAttribution: SeeWatson commentedRan 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.
Comment #15
SeeWatson CreditAttribution: SeeWatson commentedHere's the patch from #14.
Comment #16
joelpittetMoving to needs review and the right version so people know the correct status (sorry for not seeing this earlier)