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.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

gagarine’s picture

Priority: Normal » Major

I'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.

DuaelFr’s picture

I 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.

DuaelFr’s picture

Project: Special menu items » Drupal core
Issue summary: View changes

Updated issue summary.

gagarine’s picture

Project: Drupal core » Special menu items

I change the description. thanks.

gagarine’s picture

Project: Special menu items » Drupal core
Issue summary: View changes

Updated issue summary.

gagarine’s picture

Version: 7.x-1.x-dev » 8.x-dev
Component: Code » menu system

let's move that to core.. See #1543750: Allow menu items without path

tim.plunkett’s picture

Category: task » feature

Either a normal task or a major feature request. But this shouldn't count toward thresholds.

tim.plunkett’s picture

Issue summary: View changes

typo

markhalliwell’s picture

Title: Create a generic and extendable Special menu items API » Create a Menu Item Type API
FileSize
13.69 KB

+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() and hook_menu_item_render() that each module could utilize.

Menu Item Type
Note: This is a radio currently, but given the possibility of multiple item types we may want to turn this into a select input.

markhalliwell’s picture

I 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.

markhalliwell’s picture

steinmb’s picture

Priority: Major » Normal

No code here and would req. UX change. Move this to D9?

markhalliwell’s picture

Version: 8.x-dev » 9.x-dev

Agreed

markhalliwell’s picture

Issue summary: View changes

Added menu_views module.

catch’s picture

Issue summary: View changes
Status: Active » Closed (works as designed)

Menu items are plugins now.

Version: 9.x-dev » 9.0.x-dev

The 9.0.x branch will open for development soon, and the placeholder 9.x branch should no longer be used. Only issues that require a new major version should be filed against 9.0.x (for example, removing deprecated code or updating dependency major versions). New developments and disruptive changes that are allowed in a minor version should be filed against 8.9.x, and significant new features will be moved to 9.1.x at committer discretion. For more information see the Allowed changes during the Drupal 8 and 9 release cycles and the Drupal 9.0.0 release plan.