Drupal core allow only links in menu.
Sometimes we need special item and those modules do that:
* http://drupal.org/project/menu_firstchild
* http://drupal.org/project/menu_item_container
* http://drupal.org/project/menu_views
* http://drupal.org/project/special_menu_items
They almost all work in the same and have to fight the same bugs. Why not create an API module than can take care of making special menu entry more easier?
The API:
- A way to create token like "<mytoken>" usable in the link field
- Eventually those token can take params like "<mytoken:param1:param2>
- Each token has a associated function than return a link or text and even html
I certainly miss some points... so please add your idea.
Comment | File | Size | Author |
---|
Comments
Comment #1
gagarine CreditAttribution: gagarine commentedI'm more and more convince it's the way to go... and not really motivated to fix stuff I know are going to break. So let's raise the priority.
Comment #2
DuaelFrI think it is a great idea excepted for your last point because special_menu_items is good example that you may not always return a link.
You may publish this to the Core issues list to have more feedback and to hope this being integrated.
Comment #2.0
DuaelFrUpdated issue summary.
Comment #3
gagarine CreditAttribution: gagarine commentedI change the description. thanks.
Comment #3.0
gagarine CreditAttribution: gagarine commentedUpdated issue summary.
Comment #4
gagarine CreditAttribution: gagarine commentedlet's move that to core.. See #1543750: Allow menu items without path
Comment #5
tim.plunkettEither a normal task or a major feature request. But this shouldn't count toward thresholds.
Comment #5.0
tim.plunketttypo
Comment #6
markhalliwell+1 for this. I really think the menu system should really have an API for determining what "type" the menu item is. I kind of accomplished this (works, but still feels very "hackish" to me) in the 2.x branch of the menu_views module by throwing a radio toggle so users could more accurately see what they were actually saving: a link or a view. I think the first step would to create an API that provides a hooks like:
hook_menu_item_types()
andhook_menu_item_render()
that each module could utilize.Note: This is a radio currently, but given the possibility of multiple item types we may want to turn this into a select input.
Comment #7
markhalliwellI think it would also benefit us if we stop think about modifying the link path to "catch" things like
<mymodule>
(like so many of us have done) and instead think of a broader scope: item types with individualized forms. The menu module should have a menu item type of "link" which would of then of course have it's own "link_path" form item. We should get away from altering the form altogether if possible. Another thing, we should probably keep in mind how the menu module interacts with nodes and improve that as well... that was a headache to try and alter.Comment #8
markhalliwellAlso to keep in mind #916388: Convert menu links into entities
Comment #9
steinmb CreditAttribution: steinmb commentedNo code here and would req. UX change. Move this to D9?
Comment #10
markhalliwellAgreed
Comment #10.0
markhalliwellAdded menu_views module.
Comment #11
catchMenu items are plugins now.