Closed (outdated)
Project:
Drupal core
Version:
7.x-dev
Component:
base system
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
7 May 2008 at 10:05 UTC
Updated:
21 Apr 2022 at 20:17 UTC
Jump to comment: Most recent
Following on from http://drupal.org/node/196758 I think it'd be useful to be able to group links in hook_link - so you could group edit/delete links on nodes, group nodequeue links, group administrative vs. visitor links or whatever. Probably the default behaviour would be ordering, but with the possibility to split things out in themes (similar to taxonomy now). Not looked at implementation yet but starting this so that other issue can stay on track.
Comments
Comment #1
moshe weitzman commentedThis is the sort of thing we get when we use drupal_render() to emit links. we usually call our groupings #type=fieldset but we need not do that here. Requires some thought.
Comment #2
David_Rothstein commentedYeah, I just took a look at how taxonomy splits its links off, and it seems like a little bit of a mess... We would probably need to come up with a more general method and then rewrite the taxonomy stuff to use that. Maybe not so simple.
Definitely it makes sense to just separate the links out and leave the display aspects to themes, but do you think modules should be able to return some information about these link categories in order to assist with this process? Maybe a "human-readable" name for the category (and possibly a "weight")? It would look real nice if you could have this for the links:
Filed under: term1 | term2 | term3
Other formats: printer-friendly version
Make changes: edit | delete | unpublish
Of course it would be up to themes whether to display the category names, but it might be nice to get them in the metadata, not sure...
Comment #3
catchJust to note I haven't looked at how taxonomy does it, was just an example - doing it right here and then fixing taxonomy sounds like a plan.
Human readable names and weights might be useful, but we also need to avoid the mess which is contrib packages at admin/build/modules - so core should provide some sensible defaults and we should somehow discourage contrib making their own.
Comment #4
David_Rothstein commentedBasically the way it works is that taxonomy_link() is not a "normal" implementation of hook_link(); there are hardcoded calls to it from other places in the code. So yeah, unfortunately it's not a solution that can be generalized directly.
One nice thing about it though is that it allows node.tpl.php files to get a separate $terms variable and those are pulled out from the main links. I guess this is something we would want to preserve: allowing themes to access the whole list of links but also easily pull out parts of them so they can be put on different parts of the page (or at least we need to preserve the current behavior that lets that happen with taxonomy, at any rate). I'm not sure how to best do this.
Also, I agree, contrib modules should definitely be discouraged from making link groups except in extreme cases. Maybe just have hook_link_group() be a separate hook that is only used to define a group? The documentation for that could encourage people not to use it unless they really need it. Within hook_link(), you could assign a link to an existing group (e.g., the ones provided by Drupal core) if you want to, but if you try to assign one that doesn't exist then it just gets treated as uncategorized... something like that?
Comment #5
catchSo this seems like a candidate for standardisation per: http://lists.drupal.org/pipermail/development/2008-May/029897.html and hook_block()
I took a look at taxonomy_link() and it's not nice having it special cased in the theme system like that, would be good to fix it here.
Comment #6
moshe weitzman commented#339929: Move node links into $node->content
Comment #7
moshe weitzman commentedDidn't mean to change title
Comment #8
David_Rothstein commentedLooks like a really great patch (and I added some comments there), but I think a better status here would be "postponed" rather than "duplicate". The other patch goes a long way down the road to making this work and is basically a prerequisite for it, but it doesn't fully implement everything discussed in this issue.
Comment #9
catchNow it's duplicate :)
Comment #10
David_Rothstein commentedI think it's only a duplicate if you interpret the title very very strictly.... :)
The groups now exist (thanks to the other issue), but unless I'm mistaken, themes don't yet have a very clean way of displaying them, since template_preprocess_node() is still pulling out taxonomy $terms as a special case and bunching all the rest together into the $links variable. Plus, the groups that core is using by default are organized (almost?) entirely by module, which might not always be the grouping that makes sense.
I think there's a lot more that could be done here? -- it would be really neat if the core themes could output HTML that looked a bit like comment #2 above, in my opinion. It's not something that I'd probably have time to work on any time soon, unfortunately, but maybe someone else will...
Comment #11
catchI was thinking about this yesterday and had pretty much the same thoughts. I also don't have immediate plans to work on this, but would be pretty nice, and #2 remains a good example of what this could be used for.
Comment #12
stephencamilo commentedComment #13
hestenetReset issue status.