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.
in hook_menu():
$items['tagadelic/chunk/%tagadelic_vocs'] = array(
'title' => 'Tags',
'page callback' => 'tagadelic_page_chunk',
'page arguments' => array(2),
'access callback' => 'user_access',
'access arguments' => array('access content'),
'type' => MENU_SUGGESTED_ITEM,
);
however, when visiting admin/build/menu-customize/navigation those suggested items do not show.
I am not sure how this is supposed to be done in D6.
Comment | File | Size | Author |
---|---|---|---|
#9 | tagadelic283198.patch | 1.35 KB | vladimir.dolgopolov |
Comments
Comment #1
beginner CreditAttribution: beginner commentedFor comparison purposes, this is how it was done in D5:
Comment #2
beginner CreditAttribution: beginner commentedI had the same problem with directory.module.
The solution is to completely restore most of the D5 code which, in this case, is completely valid for D6.
Don't use the wildcard loader.
Here is the valid D6 code for directory.module:
Comment #3
Crell CreditAttribution: Crell commentedDid you actually create a tagadelic_vocs_load() function? The menu system kinda needs that if you're going to declare a menu hook that way. Although you probably want vocabulary_load() instead (which may or may not exist yet; not sure off hand).
A foreach loop inside a D6 menu handler is 99% of the time the WRONG way to do it.
Comment #4
beginner CreditAttribution: beginner commentedI noticed this bug with my own module (directory.module). I knew that tagadelic has a similar menu structure and that's why I checked it out.
I was using core taxonomy_vocabulary_load() function (used with the wildcard). The code worked fine as a callback. The problem is that there is no menu item ready to be enabled, like it is supposed to do.
This is the code I had just after upgrading to D6:
As I said, it worked nice as a MENU_CALLBACK, but did not fulfill its function as MENU_SUGGESTED_ITEM.
The HEAD version of directory.module uses the code in #2, which works as intended.
So, if the foreach loop is wrong, how do I get MENU_SUGGESTED_ITEM without it?
tagadelic has exactly the same problem.
Comment #5
Anonymous (not verified) CreditAttribution: Anonymous commentedsubscribing
Comment #6
beginner CreditAttribution: beginner commentedHere is the official way to fix this particular bug.
Thanks to karoly for the feedback.
Comment #7
vladimir.dolgopolov CreditAttribution: vladimir.dolgopolov commentedSorry but I didn't quite get what to do with MENU_SUGGESTED_ITEM and a wildcard loader here.
Comment #8
Bèr Kessels CreditAttribution: Bèr Kessels commentedInteresting. I did not test tagadelic on 6 myself, because I havo no 6 sites yet. It may have skipped past the people who reviewed the upgrades, though.
Lets solve this fast!
Comment #9
vladimir.dolgopolov CreditAttribution: vladimir.dolgopolov commentedHere is the patch.
It enabled menu items like in D5, but using menu_link_maintain() function.
Not sure it it a good solution so the menu item enabled by default.
But menu_link_maintain() does not include a mechanism to enable/disable a link.
Comment #10
vladimir.dolgopolov CreditAttribution: vladimir.dolgopolov commentedoops, forgot to change status.
Comment #11
Bèr Kessels CreditAttribution: Bèr Kessels commentedI am not very enthusiastic about the solution with menu_link_maintain(). AFAIK we should be able to fix this within the hook_menu very simple.
Comment #12
kurosevic CreditAttribution: kurosevic commentedhopefully this one can be explained to me. I'm upgrading a module, and a function in it is getting flagged for its use of the foreach loop, but i dont really understand whats happening in the function, so i'm not sure how to approach getting rid of the foreach.
Comment #13
Bèr Kessels CreditAttribution: Bèr Kessels commentedClosing "needs work" that has been open for a long time, without anyone working on it.
Comment #14
Bèr Kessels CreditAttribution: Bèr Kessels commented