Needs work
Project:
Taxonomy display
Version:
7.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
17 Aug 2011 at 10:27 UTC
Updated:
20 Mar 2012 at 20:29 UTC
Jump to comment: Most recent file
Comments
Comment #1
codycraven commentedrickvug,
I can see this being useful functionality. If you could come up with a patch to add it I'd be happy to review it. Otherwise this will get prioritized behind #1170146: Setting where the associated content appears.
Comment #2
codycraven commentedrickvug, after mulling over this more I think it would be best suited as a separate module.
What I will do is leave this thread open and evaluate what a separate module would require to re-build the taxonomy system to support multiple terms. I'll then, if necessary, add hooks to support multiple taxonomy terms in patches.
The main reason that I do not want to build this in to the main module is because I personally will not use the functionality and I don't really see a use-case for it for most sites. So it will become a feature that I will be maintaining for eternity that I'm not passionate about, which means it will be prone to neglect and will prevent me from focusing on adding support for taxonomy display with other modules.
Comment #3
rickvug commented@codycraven I appreciate the honesty and understand your position. There's a good chance that I'll need to have this functionality in a sprint or two. When there's actual code there I'll take a look at creating a new/forked version of this module or providing a patch here just in case there's a change of heart. Will update when there's more information.
Comment #4
codycraven commentedrickvug, sounds good. If you need any additional hooks/plugins just let me know.
If the code ends up being fairly minimalist I'll review it to see if whether it would be a hassle to maintain over time and if not I'll gladly include it.
Comment #5
codycraven commentedComment #6
rickvug commentedIt turned out that we needed this functionality for the project (6 months later!). Attached is that patch that I'm using now. It is more of a hack than I would like it to be because I tried to maintain backward compatibility for all other plugins aside from views. The issue comes down to display plugins being built for a term object vs. an array of term ids. All vocabulary display switching is done on the first term.
Let me know what you think about committing either a patch either with backwards compatibility or an API change to passing term ids to plugins. If either option is off the table I'll either run this patch as a one off for my project or look into an alternate solution. Thanks!
Comment #7
codycraven commentedFrom a quick glance at the code I overall like the work you have initiated. I think I'll rewrite it to use a custom hook_load() from the taxonomy menu (instead of using just %). That will alleviate some of the work in the other functions.
Also, I'm not positive about the titles being imploded as a comma separated list, I may need to think about how we could make that configurable (and overriddable in code) by the end user.
I think we'll also need to limit the terms loaded to all residing with in the same vocabulary also. That way the presentation will always match what is expected for each configured vocabulary.
Comment #8
rickvug commentedHaving a custom load function that would take care of (potentially) converting a string of tids to an array of tids and then passing off to taxonomy_term_load_multiple sounds like a good idea and would eliminate some duplicate code. I also agree that a comma separated list for the titles is ugly. Configuration would be best. In some cases you may want "Foo, Bar & Baz" and in other cases "Foo about Bar", and so on.
Where I disagree is that all terms should be within the same vocabulary. What we have is two vocabularies, Article Type (terms: "Article", "News", "Interview") and Category (terms: "Security", "Storage", "Server"). We want to see all Interviews about Security or News about Storage and so on. Perhaps as a rule the View selection, Breadcrumb pattern and title pattern could always be based off of the lead term?
Comment #9
codycraven commentedThat makes total sense.
I'm almost wondering if there is a better way to handle this issue rather than providing multiple terms in the arg(2) position. Say for example we add a handler for arg(3), thus the primary display chosen would be the arg(2) provided while arg(3) could be used for refining the articles displayed in the associated content.
Note: arg(3) may be handled better as a GET parameter for SEO friendly URLs...
This would allow the site to be developed to only display expected output rather than allowing users to provide whatever TIDs they desire. So in a UI you could say for vocabulary Foo that you only want to allow additional refining from vocabulary Bar, but not Baz nor Foo (through checkboxes). You could then also provide which formatting should occur with multiple terms for the title displayed.
What do you think?
Comment #10
codycraven commentedChanging status to needs work. Would really like input on comment #9 before proceeding.
Comment #11
rickvug commented@codycraven Sorry for the delay in responding. I'm no longer working on the project that this functionality was required for so I'm afraid I don't have work time to dedicate to the issue.
My initial reaction is against adding another argument. It is possible to have more than two term arguments. In this case, would the menu item be something like taxonomy/term/1/2+3? That would be strange. taxonomy/term/1+2+3 matches up with Drupal core's previous behaviour. It also supported taxonomy/term/1,2,3 for OR instead of AND. I'm not sure if Views also tries to do the same. Looking at the differences in the function taxonomy_term_page() is interesting and gives a better idea of how to pull this off. Compare D6 to D7. I'd suspect that trying to closely mimic the Drupal 6 code is good way forward.