Problem/Motivation

As Symfony is taking over routing, the following systems need a) ways to declare b) some place to store them.

  1. Menu links. These are becoming entities, so it can be scratched.
  2. Local tasks. Earlier discussion was at #484234: Big task cleanup: Remove type and tasks from hook_menu().
  3. Local actions (aka operations on a page, which is just weird)
  4. Contextual links
  5. Access control (although that's a routing system's so this might be scratched.

Proposed resolution

per comment #25:

First

We take hook_menu as it exists now and add a "route" key. That "route" key refers to a route to which that menu link points. The path of the route *overrides* the path that the menu item has. Then we remove the now-duplicated parts of the menu item definition: page_callback, page_arguments, access control, etc.

Then we modify the link build process to pull in the corresponding route and build out the same structure we have now, more or less. This would also partially if not entirely resolve #1845402: Update menu link access checks for new router.

Benefit: We're no longer duplicating route information between hook_menu and routes. hook_menu is now defining just, er, menus.

Risk: This may or may not collide with what's going on in #916388: Convert menu links into entities. Also, hook_menu keying by path while routes key by name *may* result in some weirdness. We'll only know once we start writing.

Second

We rip action links out of hook_menu entirely, using essentially the model from comment #9. To wit, action links become their own object unto themselves that reference to a route they point TO, and to routes they should appear ON. They are then removed from hook_menu entirely. We then build a block that looks at the current route (which may need to be passed as a literal string, not pulled from the request, TBD), grabs the action links that should be on that route, and displays them. Want to change the L&F? It's a block. Enjoy.

Benefit: Action links get separated from hook_menu, where they didn't belong in the first place.

Third

Keep figuring out what to do with Tabs/Tasks, since those are harder. aka, punt for now so we can unblock.

Remaining tasks

#2047633: Move definition of menu links to hook_menu_link_defaults(), decouple key name from path, and make 'parent' explicit

Actually code this thing, then figure out what to do with tasks/tabs.

Completed tasks

#1845402: Update menu link access checks for new router
#1908756: Separate Action Links (MENU_LOCAL_ACTION) from hook_menu()
#1947536: Convert drupal_get_breadcrumb() and drupal_set_breadcrumb() to a service
#1954892: Replace 'theme callback' and hook_custom_theme() with a clean theme negotiation system
#1981644: Figure out how to deal with 'title/title callback'
#2004334: Separate Tabs (MENU_LOCAL_TASK) from hook_menu()
#2023795: REGRESSION: hook_local_actions doesn't use title callback
#2031473: Convert menu local actions to plugins so that we can generate dynamic titles and paths
#2102125: Big Local Task Conversion

User interface changes

Probably none for the immediate patch.

API changes

See above.

Comments

Crell’s picture

As noted in the previous issue, it's probably best if we don't use the name hook_menu() at all in the new setup, whatever it is, to help point out to people that it's different and avoid confusion. It also means it's easier to maintain the BC layer for the time being as we build things to migrate to.

btopro’s picture

From a purely site builder mindset it's very hard to describe to others the difference between Contextual Links and Local Tasks (and local actions for that matter). I get the difference between the three but I'd imagine it's cause I've gotten used to the quirkiness of the idea over the years. If local Tasks / Actions were more well defined in terms of what their jobs are (and terminology to match) then I think you could merge the "actions" into the Contextual links. If you are viewing a node in a view, the contextual link is the gear as in D7. If you are viewing the item itself though, the contextual link is the tabs / "local actions".

Language changes may help somewhat at least in helping define the differences (as per D7/8 api docs):

MENU_LOCAL_ACTION: Local actions are menu items that describe actions on the parent item such as adding a new user or block, and are rendered in the action-links list in your theme.
MENU_LOCAL_TASK: Local tasks are menu items that describe different displays of data, and are generally rendered as tabs.

So Local task's description makes sense but the phrasing does not. If these truly are different displays of the data being rendered then nothing in "local task" implies this. Also critiquing "Local actions", with WSCCI a "rendered in the action-links list in your theme" doesn't really make sense either or have a place if Drupal now just happens to be serving a HTML as a response instead of some other format.

At least thinking of node as it stands:

  • node/1/view - Is the menu default but makes total sense in terms of the scope of menu local task
  • node/1/edit - The task is editing but now (especially with a lot of the work in the edit mode UI / Spark stuff) is this also potentially described as a contextual item / mode. MENU_LOCAL_TASK at the moment (this displays the data in edit mode I guess is the logic).
  • node/1/delete - This is not a "display of the data", this is more of a local action as it would be deleting the parent item yet it currently is MENU_LOCAL_TASK.
  • node/1/revisions/* - This is a display of the object, or at least a series of actions leading towards an action on the object. This at least makes sense as LOCAL TASK given the current description

Menu entity bundles?

So, if menu item is now an entity then to me that sounds like a couple different bundles of menu items. Possibly these are Actions and Displays as different yet equal Bundle types? An Action Bundle could have the current contextual flag so that you can define actions that either are listed and contextual, just listed on the item itself, or not listed (purely a callback)
A Display Bundle would have the ability to either be displayed or not be displayed (or possibly formats to respond to calls against, haven't been keeping close tabs on the progress in WSCCI to know what the details are there)

andypost’s picture

philsward’s picture

So... I have no idea where the best place to post this is, BUT, one thing I believe needs to be addressed is: "What controls the menu links?" What I mean by this is that various modules hijack the menu "routing" (Forgive me if i'm not using the right terminology) and control various menus. For example, you can create a menu link through Views or Panels. Fine and dandy, but if you set the site up, then leave it for 6 months and come back, you have no idea where to look to edit the menu item.

I JUST created a new taxonomy link on one of my sites and I have a menu block showing those specific taxonomy names as menu links. Only... I've looked at views and I've looked at Panels and in the 10 minutes of looking, I can't figure out for the life of me what the heck is controlling them. I know they weren't manually created through the menu because there's no editable path. But when I look at my views, I only have a generic view for the vocabulary, not specific break out view pages for each term. Panels is the same way. Only a single variant template to control the overall vocabulary. So I'm stuck scratching my head trying to trace my steps of where / how I created those menu items.

The "issue" is: "What can be done to make contrib modules manipulating the menu tree, more transparent?" I feel like each contrib has a set of rules they have to play by, but otherwise each contrib can essentially take control of their own menu items, leaving the maintainer with the daunting task of keeping track of "what controls what".

Any thoughts on this?

philsward’s picture

Update: I "think" I figured out my issue... I used to have each view broken out in separate pages for each taxonomy term when I was on D6. In D7, manipulating views I was able to handle everything with the one view vocab page. In theory, each of my links are left over from the "old" format and because I moved the menu links after views created them, they've hung around. I'm guessing if I "reset" each one, they will disappear on me. Again, it's all in good theory but shows how truly cluttered the menu structure can become over time without proper care.

Berdir’s picture

For local tasks, see also #1864066: Simplify hook_menu_local_tasks() and MENU_DEFAULT_LOCAL_TASK usage which simplifies how local tasks are added and altered dynamically and might be a first step towards getting it out of hook_menu() completely.

larowlan’s picture

Some random thoughts.
Breadcrumbs become a service in the DIC and provide a block plugin. Standard enables this feature and places the block in the appropriate region. Ideally breadcrumbs would integrate with the (unfinished) condition plugin system and be Conf entities ala custom breadcrumb module with menu module providing a default plugin based on menu trail. So there is a system of breadcrumb plugins (menu trail and custom ship with core). custom provides condition based context aware system with token support so you could remove the custom code in template preprocess forum and just ship with some default config for that module. You build your breadcrumbs as block instances with the block configure form allowing you to choose the breadcrumb plugin type and configure conditions and tokens if required.
Thoughts?
Apologies for the lack of cohesiveness in this thought dump

Crell’s picture

I'm not sure about all the conditions and tokens bits, but "breadcrumbs are just a block, nothing special" makes total sense to me. That also makes it simple to throw out the core breadcrumbs block and write your own (in contrib). Such a block would need to leverage the request and the "active trail" concept... which is part of the menu links system, IMO, not routing. So we would need API support for taking the active route, determining the active link from that, and then traversing its parentage. (For core, anyway, Contrib, write your own with any logic you want.)

Crell’s picture

We discussed this issue for some time this morning during the WSCCI meeting, trying to draw inspiration from the previous work chx linked to from the issue summary. For handling local tasks and local actions, our tentative proposal is this:

- Both tasks (aka tabs) and actions get split off to their own registration mechanisms (info hook, collection event like routes, etc.). The definition of these reference to a route by machine name, but do not themselves duplicate any data form the route.

- Routes may define "route sets", which are more or less arbitrary tags and classifications that tasks and actions can reference to.

In *pseudo-code only* form, it would look something like this:

$task['node_view'] = array(
  'link' => 'node_view',   // route name that this task links TO
  'parent' => NULL,        // this would be another task's machine name, to indicate this is a sub-tab.
  'title' => 'View',           // Human readable label for the link
  'priority' => 1,            // weight, but the other way around
  'default' => TRUE,      // Make the default tab if possible?
  'taskset' => 'nodes',    // Show on any route that is tagged with this set. Could also specify by name
);

$actions['node_add'] = array(
  'link' => 'node_add',      // route name this action links TO
  'title' => 'Add another', // Human readable label for the link
  'priority' => 1,              // weight, but the other way around
  'on' => array(               // Specific routes by machine name this action appears on. Could also specify sets
   'node_view',
   'node_edit',
  ),
);

In the routing yaml file:

node_view:
  pattern: node/{node}
  options:
    taskset: nodes

node_edit:
  pattern: node/{node}/edit
  options:
    taskset: nodes

Access control would be handled by the referenced route. Display would be handled by a SCOTCH Block, which dips into whatever compiled lists of tasks and actions we have and builds what it needs. Want a different display? Subclass and write your own block. :-)

The main open question, I think, is how do we handle placeholders in those routes? Do we say that the names just have to match, and so the value of {node} in the current request maps to the generated link to the tab? I have no idea...

Feedback welcome.

gilgabar’s picture

Perhaps it is possible to replace local tasks with menu links. A combination of functionality similar to that found in the menu token and menu block modules should cover most of the use cases currently handled by local tasks. Here is an issue to move menu block functionality into core: #474004: Add options to system menu block so primary and secondary menus can be blocks rather than variables.

Crell’s picture

How would menu links (which are becoming entities) handle the logic related to what pages to appear on, access controls, etc.?

gilgabar’s picture

It's not a fully baked idea and those considerations would need to be worked out. Perhaps there isn't a way to work them out in a reasonable time frame, in which case the approach outlined in #9 sounds reasonable.

My motivation for suggesting the idea is based on more than one confused client trying to find out where they can edit their tabs. End users tend to think of local tasks as menu links already, so making them into actual menu links would be one way of solving that problem. Though I suspect it would be no panacea. The menu block type of approach, of displaying sibling and/or child menu links of the menu link for the current page, is not strictly the same as what would be displayed by a more traditional approach to local tasks. But perhaps there are solutions for that too. In any event I thought I would put the idea out there in case someone finds it useful.

Crell’s picture

Thank you for putting it out either way! We need ideas here, both workable and not, to generate discussion. :-)

My concern with a menu link approach for those is that they are, in most cases, dynamic. Taking a strictly menu link approach would mean that N nodes would need N menu link entities, and then we'd need N "edit" link entries, and N "revisions" entries, etc. even though in 99% of cases they would also be identical. That's not going to scale.

I think making user-definable custom local tasks that are specific to a single node is an interesting idea, but it would be a new feature request independent of the need for pattern-based tasks and actions.

btopro’s picture

could local tasks be part of the originating entity that the local tasks are associated to and not menu link entities at all? So that an entities definition includes what it's local tasks?
Psudocode

<?php
  entity_type => 'node',
  tasks => array(
    'edit' => 'node_task_edit',
    'view' => 'node_task_view',
    'delete' => 'node_task_delete'
  ),
  uri_callback => 'node/{nid}',
  primary_key => 'nid'
?>

Anything that wants to provide local tasks for an entity would alter the tasks property of the loaded entity in question and then local task callbacks could have a consistent, implied naming convention (or be defined as above). node_task_view {entity}_task_{operation}. This could help remove the local tasks from the menu callbacks that are defined and provide a UX improvement in terms of how things associated with an item are defined at a code level. Would reduce the 1 to 1 issue of a menu entity per entity because they are part of the schema of the entity itself.

This also could help resolve the difference (ill defined in my mind) between what are commonly called "operations" on drupal forms like the menu management page and local tasks because they are effectively the same thing. Menu item entities can have tasks of edit,view,delete just like anything else that provides these callbacks.

gilgabar’s picture

Re:#13 I agree. The proliferation of menu links in a case like nodes is unworkable. Perhaps there is a different approach that would make that a non-issue. If we consider local tasks as they are currently conceived to actually be solving two separate problems then we can solve each of those problems separately rather than trying to create a common solution. I would characterize the two problems as entity operations and local navigation.

For the first, entity operations, of which the node view/edit/etc links are a good example, I think the argument can be made that local tasks are actually an inappropriate solution. Contextual links are much better as they work consistently with an arbitrary number of entities of different types on a single page. They also don't force designers to account for a set of tabs in every design just to allow a user to edit an entity directly. For the case of the current active entity the toolbar is a much more appropriate and consistent place for entity operations on that entity. That also appears to be consistent with the direction things are going with the in place editing tools already: http://buytaert.net/spark-update-unified-in-place-editing. Also related to this and #14 is #1839516: Introduce entity operation providers.

For the second problem, local navigation, the menu block type of approach seems like it could be a reasonable solution. This primarily covers administrative settings pages that need to display links to related sibling and child pages.

I feel like I may be missing some use cases, or special cases, so please let me know if that is the case.

gilgabar’s picture

Another possibility re: resolving the proliferation of menu links with a menu block type of approach would be to not use that type of approach in all cases (or at all). Using separate menus, each with their own block, it would be up to the block visibility settings (or the d8 equivalent) to control the display of that set of menu links. The dynamic nature of the links themselves could be handled via tokens.

So using the node example there would be a node menu displayed via its own block. It would by default contain menu links for 'View' (/node/[node:nid]) and 'Edit' (/node/[node:nid]/edit). The block would be visible when the path matches '/node/*'.

donquixote’s picture

I would imagine these things as "parameterized menus".
We have views and panel stuff parameterized with contextual data (current entity id, etc). This would be the same just for menus.
This could be a different subsystem than the regular (static) menus, but it could also be based on entities for menu links.

Crell’s picture

Issue tags: +Needs usability review, +WSCCI

gilbabar: That's an interesting observation regarding local nav vs. entity operations. You're right, in practice between local tasks, local actions, and contextual links we have too many overlapping options for developers. (We're also not the first to make that observation.)

Unfortunately we cannot entirely abandon local tasks in favor of contextual menus at this point, because contextual menus require Javascript and we cannot require Javascript just to be able to edit a node. (There's talk of making contextual links added to the DOM tree entirely client-side, too, so we can't even rely on lack of styling to mutate tasks into contextual links.)

A unified entity operation API would definitely help here. Then we could just expose "operations" to the site builder and they can place/style them however they want. Unfortunately we are up against the fact that we've less than a month to get this figured out before the "feature completion" deadline, after which we start losing options in terms of what we can redesign rather than simply port. I don't think we can bank on such a unified API materializing in Drupal 8.

If we are able to fork off entity operations from local navigation, is the model from #9 a reasonable way to handle local navigation? Or does it break down there, since for things like admin pages you probably don't have an obvious "tab set" to define?

btopro’s picture

#9 looks good. A few questions that come to mind though:

  • Will parent be able to be infinitely deep or is this just essentially drilling down an additional level into the parent local task? I know a lot of themes have trouble recognizing the sub-tasks of local tasks from past experience.
  • Has there ever been a menu who's default local task wasn't the 1st item / highest priority? seems a bit silly to have a default flag (especially when others could potentially define multiple defaults).

The parent of parent ? may seem odd but I've seen a contrib modules to add something like node/6/view/gov (anything related to government) but can't go deeper then the one level when node/6/view/gov/senate (just the senate, a member of gov, on node 6). Also as a dev who's added the same View twice to accomplish the "default" local menu task or added multiple menu items for consistency, I can't think of a time when it wasn't the first item I added.

Bojhan’s picture

Not really sure what to give feedback on, we are exploring ways to remove local tasks all together (JS, or no JS) - however that part is far from figured out yet. So for now, we would still need to support all those link options

sun’s picture

Issue tags: +MenuSystemRevamp

For everything related to entities, we should explore #14. That's the main and primary purpose of local tasks + also contextual links. All of them are attached to an entity, and luckily, "entity" can also mean "block" or even "layout" in D8.

Links/Tasks/Operations being attached in that way should work and be available, regardless of the router path or location that an entity appears. The mere existence of %node (or {node}) should make the corresponding links/tasks available.

That's essentially the direction of #1839516: Introduce entity operation providers and #1783964: Allow entity types to provide menu items.

What that does not solve yet are the following areas:

  • Router paths (pages) that are not entities, but which have local tasks. E.g., configuration pages, setting pages, custom pages, etc.

    In these cases, local tasks are actually used as navigational tool and represent a menu link tree hierarchy similar to a menu block, but not displayed as a menu block, but instead as a list of links, constrained to a maximum depth of 2 levels.

    One might be able to argue that these, if anything and at the very least, are still blocks. A content block that appears on a page. And the block plugin/entity could have the links/tasks attached. In other words, wherever the block is output, it has its links/tasks attached. Whether to present them as a list of links/local-tasks or as contextual links dropdown is a pure question of front-end styling. The generated HTML markup is a list.

    Therefore, the tabset/tasks/links could be attached to the block entity, in the same way a tabset would be attached to a node entity.

  • Action links.

    These are a special kind of can of worms. Code-wise, they are currently intermixed into local tasks, but they actually do not have any kind of relation to local tasks. The situation is confusing, because action links were originally bound closer to local tasks. However, their architecture was significantly changed still within D7, when they were introduced. Therefore, the current code, relationship, and binding to local tasks is completely based on a legacy implementation that no longer exists, and when discussing what to do with them, we should ignore that completely. One step towards that is to use appropriate language: "Local tasks" vs. "Action links" (not local).

    Action links are currently bound to arbitrary router paths. They are not related to the local tasks. If there's an entity on that page, then action links are also not (directly) related to that. There are multiple kinds of action link patterns in core right now:

    1. The most common are "Add new Foo" links on a page that lists foo entities. I.e., either a EntityListController, or a Views view. The only "relation" there is that both happen to talk about the same entity type.
    2. Cross-links in the form of "Create content" on a page that lists content types. I.e., a (config) bundle listing page points to the page where new entities can be created, to which the listed bundles belong to. The relation between the two router paths/pages is rather arbitrary.
    3. Related actions in the form of "Install new theme" or "Update modules" on the update status report page as well as the Modules and Appearance pages. There is no technical relation at all here; the relation is purely human-logical and the links are simply tacked onto the pages.

    None of these are really tied to anything concrete under the hood. Action links are rather custom plumbing, with the goal of improving the UX for users that are not aware of the relationship between multiple resource paths.

    In general, the idea for a formal API for declaring cross-reference-links between pages of related functionality, more or less completely detached from the router and menu link tree and local tasks functionalities, as proposed in #397430-28: Implement cross-reference links that refer to logically closely related functions., might be worth to explore as a general replacement for Action links. This API could be implemented by EntityListControllers and Views, so as to automate the action links for those pages.

  • Menu link tree hierarchies and link (re-)parenting processes.

    When removing the entire topics of local-tasks/contextual-links and action links from the equation, then main functionality of primary menu links still remains (aka. MENU_NORMAL_ITEM / MENU_VISIBLE_IN_TREE). This is the primary purpose of hook_menu() and what causes menus and menu link trees to exist. Turning them into entities won't change a single thing.

    The non-router properties of hook_menu() definitions are used to auto-generate corresponding menu links for the defined router paths. There have been proposals in the past to remove the auto-generation of links entirely and require explicit CRUD operations for all menu links. IIRC, that was #653784: Separate out menu links from hook_menu.

    I always disagreed with the explicit CRUD proposal, since it does not provide a solid concept for the question of Who owns a menu link. It only works "now", but as soon as you consider that there's a past and a future, and that things will change over time, and thus, menu links have to be maintained over time, that concept will essentially have to make a hard decision, which reasonably can only go in two ways:

    A) Either all modules own their links and are manually futzing and are actively changing our site's menu links in order to maintain them (i.e., running update.php will require you to perform a full QA of your entire site).

    B) Or modules won't maintain their links at all, since the user owns them (i.e., updating modules potentially results in plenty of 404s due to broken links).

    Both possible ways are considerably worse than what we have now, which is essentially the reason for why I disagree with that idea.

    We could punt on that sub-topic and retain the auto-generation in a hook_menu_links() for now. In that case, I'd think the definitions would look similar to #9; i.e., each link references a router item and declares link properties for it.

    Since tasks/actions/etc and everything else is gone, that would pretty much boil down to very basic properties only:

      $links['user.login'] = array(
        'title' => 'Log in',
        'menu_name' => 'account',
        'weight' => 0,
      );
      $items['node.add'] = array(
        'title' => 'Add content',
        'menu_name' => 'tools',
      );
      $items['node.add_type'] = array(
        'title' => 'Add content of a type',
        'title callback' => 'node_type_get_clean_name',
        'title arguments' => array({node_type}),
        'description callback' => 'node_type_get_description',
        'description arguments' => array({node_type}),
        'menu_name' => 'tools',
      );
    
  • Some other remaining hook_menu() properties.

    All of them are rather strange and shouldn't actually be part of hook_menu() in the first place:

    • theme callback: Rather belongs to the route. (Weird concept to begin with.)
    • theme arguments: Ditto.
    • position: Umph. Has no business at all in menu link definitions.

Please also note that there are a range of existing issues about these topics already. All of them are tagged with MenuSystemRevamp since 2010. Discussion participants here should ideally read those prior discussions, since we'll be running in big circles otherwise. ;)

donquixote’s picture

@sun,
for the part about hook_menu_links(),
how do you want to define the tree hierarchy? Would we not also need a "parent item" setting?
In hook_menu() we used to have an implicit parent based on the path. I found this quite elegant as a default behavior, but this won't work with route names - unless we look up the path in the router table.

sun’s picture

Yes, since the sole purpose of hook_menu_links() is to auto-generate links for router paths, we would totally look up the path in the router item (identified by the array key in the definition).

That's essentially what happens right now under the hood. The current menu system processes the router item aspects of hook_menu() first, builds out the {menu_router} from that, and lastly saves menu links for each definition. Thus, there's a strict 1:1 binding and the router (path) implicitly declares hierarchy.

donquixote’s picture

Nice.
Ok then I would still propose an optional "parent route" setting for override, similar to what is suggested in #1830274: Support a parent_path setting in hook_menu(). / hook_menu_link_alter() should not touch the plid. (please ignore the patches)

Crell’s picture

We discussed this topic further during today's WSCCI meeting, which for a change happened via Google+ Hangout. We came up with a 3-step process to improve the situation, although not resolve it entirely:

First

We take hook_menu as it exists now and add a "route" key. That "route" key refers to a route to which that menu link points. The path of the route *overrides* the path that the menu item has. Then we remove the now-duplicated parts of the menu item definition: page_callback, page_arguments, access control, etc.

Then we modify the link build process to pull in the corresponding route and build out the same structure we have now, more or less. This would also partially if not entirely resolve #1845402: Update menu link access checks for new router.

Benefit: We're no longer duplicating route information between hook_menu and routes. hook_menu is now defining just, er, menus.

Risk: This may or may not collide with what's going on in #916388: Convert menu links into entities. Also, hook_menu keying by path while routes key by name *may* result in some weirdness. We'll only know once we start writing.

Second

We rip action links out of hook_menu entirely, using essentially the model from comment #9. To wit, action links become their own object unto themselves that reference to a route they point TO, and to routes they should appear ON. They are then removed from hook_menu entirely. We then build a block that looks at the current route (which may need to be passed as a literal string, not pulled from the request, TBD), grabs the action links that should be on that route, and displays them. Want to change the L&F? It's a block. Enjoy.

Benefit: Action links get separated from hook_menu, where they didn't belong in the first place.

Third

We re-evaluate what to do with Local Tasks, since those are the Hard(tm) part here. Let's do the above and then see where the dust settles and what time we have left, and if the Entity Operations API happens, and revisit. If we can't do anything, well, at least we've gotten the first two big items taken care of.

This does leave a real possibility of hook_menu surviving into Drupal 8. That would be sub-optimal. However, I think this approach does get us moving and let us build momentum, and once we've ripped out a few more pieces it may be easier to see what to do with the rest.

Because we have a limited amount of time, I'm going to deadline this issue to this Friday 1 February. We can still work on figuring out what to do for part 3 after that, but if we can at least lock down parts 1 and 2 we can move forward and actually get stuff done.

Crell’s picture

Issue summary: View changes

Updated issue summary.

dawehner’s picture

In general having the routes separated from the menu entries seems to make it easier to understand how the system works: Links and Routes are two different systems, so that itself is already a win.

The steps described by crell seems to be good as they are clear route provides relative "small" and separated pieces. +1

donquixote’s picture

So instead of one info hook for different (unrelated) things, we now get several hooks / events.
This means more clarity, but also more typing.

It would be interesting to see how a typical module shapes up, converted to the new APIs.
(even if they are not spec'd out in all detail yet)
I have always been afraid of the "more typing", but it seems everyone else is comfortable with it - fine.

andypost’s picture

Good plan, we have bundles and view modes separated already.
#916388: Convert menu links into entities is related but have no collisions

tim.plunkett’s picture

Issue tags: +VDC

Tagging, Views needs all 5 of the things described in the OP, and with #1904854: Convert Views UI to routes it will provide some nice implicit test coverage :)

tim.plunkett’s picture

Issue summary: View changes

Add proposed interim way forward.

Crell’s picture

Title: Allow modules to register links for menus, breadcrumbs and tabs (if not with hook_menu) » [Meta] Allow modules to register links for menus, breadcrumbs and tabs (if not with hook_menu)

I added links to the issues where this is being worked on to the issue summary. We can use this as a meta issue. Volunteers still needed for the Action Links issue.

larowlan’s picture

dawehner’s picture

dawehner’s picture

Issue summary: View changes

Add links to related issues.

Crell’s picture

Yes, added to the summary.

Crell’s picture

Issue summary: View changes

Add more working issues to the summary.

dawehner’s picture

tim.plunkett’s picture

tim.plunkett’s picture

Issue summary: View changes

added the title issue.

pwolanin’s picture

Issue summary: View changes

add 2004334

pwolanin’s picture

Issue summary: View changes

adding #2023795

tim.plunkett’s picture

yoroy’s picture

I'm going to need some help in understanding where this needs usability review, if any :-)

dawehner’s picture

I can't even imagine how this issue would be related with usability ...

Crell’s picture

Wrong user, I think. :-) But I think we've just about resolved these bits.

Crell’s picture

pwolanin’s picture

Issue summary: View changes

Updated issue summary.

Crell’s picture

Issue summary: View changes
Issue tags: +beta blocker

The issues under this meta are all implicit beta blockers. Peter Wolanin will add additional child issues shortly.

MustangGB’s picture

Issue summary: View changes
dawehner’s picture

Issue summary: View changes
xjm’s picture

Priority: Major » Critical
Status: Active » Fixed

Discussed with @catch, @pwolanin, and @dawehner. This is done except for #2047633: Move definition of menu links to hook_menu_link_defaults(), decouple key name from path, and make 'parent' explicit (independently a critical beta blocker) and possibly #2084421: Phase 2 - Decouple book module schema from menu links (currently a beta target), so marking fixed. Also re-prioritizing based on the DX impact of this.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.