Closed (duplicate)
Project:
Taxonomy Menu
Version:
6.x-1.x-dev
Component:
Code
Priority:
Critical
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
25 Feb 2007 at 23:19 UTC
Updated:
18 Jan 2009 at 11:43 UTC
Jump to comment: Most recent file
Comments
Comment #1
iancawthorne commentedI'm looking for the answer to this question too.
Taxonomy menu creates its own pages eg: http://www.yourdomain.com/taxonomy_menu/1/3
but standard taxonomy uses the path: http://www.yourdomain.com/taxonomy/term/1/3
Views can override the standard taxonomy pages, but I haven't found a way of doing this for the taxonomy menu pages. Surely there must be a way to do this.
Comment #2
sjnorton commentedLikewise, I'd like to be able to change the sort order of node listings generated by Taxonomy Menu without resorting to hacking the taxonomy module directly. The Views module seemed just the thing, but I could find no way to make it affect listings generated via taxonomy_menu. Any help appreciated!
Comment #3
waltWright commentedI am also having a similar issue. I added both Taxonomy Menu and Taxonomy breadcrumb modules. It seems like a very logical expectation that some menu items within the taxonomy menu should be overridden and NOT go to the taxonomy default page. For example, if I define a book, I would want to redirect the menu item (term) to the book root. Instead, we get all of the nodes affiliated with the book (because they all refer to the term). I'm hoping that a view can allow more control, but haven't figured out how to integrate it or if it possible using Taxonomy Menu.
Comment #4
gmayes commentedI too would be very interested in a solution to this.
I'm thinking of configuring the "taxonomy/term" view to my taste, and then editing taxonomy_menu.module so that the URL maps to taxonomy/term/* instead of taxonomy_menu/*. This way I can control the "view" and also have menu links for terms created automatically. The only issue I see (so far) in my cursory testing is that taxonomy/term uses a depth of 0 and taxonomy_menu has an unlimited depth, but hopefully this is an easy fix.
Thoughts?
Comment #5
gmayes commentedSorry all, I gave up. Here's what I tried:
1. Change the "taxonomy_menu/*" $path in taxonomy.module to use "taxonomy/term/*". Unfortunately, taxonomy_menu uses the URL to create the hierarchical menu, so by changing the URL, the hierarchy disappears.
2. Use mod_rewrite to change "taxonomy_menu/*" to "taxonomy/term/*". This works, but the menu collapses after clicking one of the terms. My users (and I) can't live with this behavior.
So it looks like I'm not going to use taxonomy_menu. Instead I'll create menu links by hand.
Comment #6
mdlueck commentedI seem to have happened across this bug from the other direction:
"URL attempting to be modified shows tabs, no other changes"
http://drupal.org/node/169298
It appears various things have been tried, without success.
Comment #7
sutharsan commentedIt requires code to get Taxonomy Menu to work with Views.
Comment #8
mdlueck commentedAny suggestions as to finding this required code?
Comment #9
jadwigo commentedI tried my coding at this and it seems to work reasonably well with the attached patch
the change is only in the displaying of nodes where the original uses
taxonomy_render_nodesand my patch usestheme("view","taxonomy_term"...)the taxonomy_term view should probably be enabled, and may be customized to your needs...
I only tested it with display descendants turend off, so YMMV
Comment #10
bgoines78 commentedMy disclaimer is that I am new to Drupal (less than a week) so I am still trying to learn the system as well as the code. I immediately began working on the taxonomy_menu/pathauto problem and think I may have a better understanding of the taxonomy_menu/views woes. I think that the problem is that taxonomy_menu registers individual callbacks for the url, 'taxonomy_menu/[vocabulary id]' rather than 'taxonomy_menu'. What this means is that, in order to apply a view to taxonomy_menu, you must specify the vocabulary ID in the URL as well. Long story short, if you create a vocabulary named 'Test Vocabulary' and the ID assigned is 8, the URL of your view should be 'taxonomy_menu/8'. Of course, this limits the view to that specific vocabulary, but that actually works in my favor. Since I currently have a modified version of taxonomy_menu installed in my test environment, I cannot test this theory with a clean installation. Could someone confirm if this works? Tested against Drupal 5.x.
Comment #11
mdlueck commentedgoines78: You guessed correctly! ;-) Now I know why I was dragging my feet a bit to test out jadwigo's patch!
Adjusted the URL from: taxonomy_menu to: taxonomy_menu/6 and clicking the taxonomy_menu/6 NOW gives a customized view.
So, onward to test out jadwigo's patch.
Comment #12
jadwigo commentedthe individual
taxonomy_menu/[vid]callbacks are there because taxonomy menu lets you choose which vocabularies to show...my patch does not change any of the menu paths for the taxonomy_menu module - it only changes what happens when you look at a page - now a view is rendered instead of a default taxonomy term page.
Comment #13
mdlueck commentedSounds like you two are saying the same thing, just in different ways.
bgoines78 stated that views will take affect, just that you have to include /[vid] in the URL that views will look for / detect.
It sounds like patch makes it possible to customize the module with views regardless of which /[vid] happens to be being viewed... which is the way the module should work.
Comment #14
bgoines78 commentedI assume the taxonomy_menu module does not define the path, 'taxonomy_menu', because that would create a throw-away menu item. This would make taxonomy_menu work naturally with views using a url of 'taxonomy_menu'. Like I said before, I'm still new to Drupal so I don't have the whole story yet, but wouldn't this patch now make taxonomy_menu dependent on views? I searched the drupal apis and could not find a replacement theme_view function outside of the views module. I have not tested it, but I'm worried that this would produce a blank page (or page with blank content) if the views module were not installed.
Comment #15
mdlueck commentedThanks for pointing that possibility out. Maybe the OP of the patch will comment.
Comment #16
milksamsa commentedI am having the same difficulties.
I really want to automate the generation of the menu, but at the same time I would like to customize the nodes listing with a View or a Panel.
Of course it would be great to keep the generation of friendly pathauto [term]/[title] aliases.
I believe this should be a basic Drupal feature as I believe that a hierarchically clear website tree is a common need...
I'm still wondering why such a thing is still so tricky to achieve and is not in core.
Home it gets fixed soon. I am afraid I won't be able to help as I don't really know how to code PHP.
Comment #17
bgoines78 commentedThat is exactly what I am working on and I think I have it mostly working with the exception of feed aliases without views and any type of feed with views. I checked out the view_rss module, and it appears that it arbitrarily guesses what the feed url should be and assumes something like taxonomy_menu/[vid]/*/*/feed which is a path that is not even defined! I do have a version of taxonomy_menu that correctly creates the feed aliases and they work properly without views, but I have been holding it back until I can get the feed working with views. If you want to check out the replacement taxonomy_menu.module, check this post http://drupal.org/node/41476. Note, if you enable the aliases for taxonomy_menu, it is recommended that you disable the path aliases for Categories by removing all patterns. Currently, the taxonomy_menu module creates some aliases that point to the taxonomy/term URLs.
Comment #18
milksamsa commentedThank you bgoines.
I tried applying your version of Taxonomy_menu module.
I found the Taxonomy Menu path settings under admin/settings/pathauto and used [taxonomy_menu_catpath].
I regenerated the aliases, but when I create a matching alias view (eg. apparel/tshirts), the ovveride won't occur.
I still obtain apparel/tshirts without view customization (the basic term listing page). Where am I wrong?
Comment #19
bgoines78 commentedThe views should still be applied to the base taxonomy_menu/[vid] path, not to the alias. I'm not quite sure if the view should actually override an alias or not. I've only tried views in this limited scenario.
Comment #20
milksamsa commentedUnfortunately, if a view is applied with a page view connected to a url: taxonomy_menu/x/x, the link no longer displays in the menu.
Still looking for a fix. I need to apply a view to taxonomy_menu generated listings... e.
Comment #21
tanoshimi commentedSubscribing. I love the functionality of taxonomy_menu, but I'd really like to be able to combine that with the flexibility of views...
Comment #22
danthalian commentedsubscribing
Comment #23
kingandySubscribing also.
Comment #24
diegohermes commentedSubscribing.
Comment #25
s.daniel commentedSubscribing
Comment #26
bartoki commentedSubscribing. I think the number of people interested in this demonstrates its popularity.
Comment #27
mdlueck commentedI guess we have advanced enough that we can get by just fine without Taxonomy Menu or other taxonomy navigation modules.
Our solution is to create URL aliases to taxonomy queries. Then use those URL aliases while creating a menu manually.
Details about the syntax of taxonomy queries can be found here:
"Taxonomy: A way to organize your content"
http://drupal.org/node/299
and scroll down to: "Using categories in menus"
This solution works with stock Drupal, no contrib modules necessary... and GLAD of that detail!!!!
Comment #28
tanoshimi commentedI think you've summarised the requirements - menu links which alias taxonomy queries - but surely the whole reason why people want a module like this is that they don't want to have to manually create menu links which mirror a taxonomy which they've already created, but to have them automatically created?
I have a site with over 300 terms in a hierarchical taxonomy - I've already spent time adding and arranging all the categories once when I created the vocabulary, so I don't want to have to do it again in my menu structure - or have I misunderstood your post?
taxonomy_menu actually does this very well, except for the fact it creates it's own url menu structure of /taxonomy_menu/1/3/2 rather than using the default taxonomy/term/2 - which means it can't be overridden with taxonomy_redirect and views etc. which I believe is what this thread is calling for.
t.
Comment #29
mdlueck commentedWe are making extensive use out of multi-term queries for our menuing system... things that no contrib module could do.
As well, separating site navigation from taxonomy was also a good thing. You could click on "Platform" first, then "Linux". But others might click on a category of application, then "Linux" to refine that application category to only the Linux apps. Utilizing / leveraging Taxonomy queries lets us have a single "Linux" tag used in countless queries, thus countless menu choices dealing with "Linux" in some way, shape, or form. Taxonomy Menu and all other contrib modules totally ignore the power of multi-term Taxonomy queries.
So, we came full circle... Doing more powerful things and no need for a contrib module.
Comment #30
jadwigo commentedhas anyone actually tried the patch I posted earlier?
I use it to make the taxonomy_menu structure redirect to a view.. and it does work AFAIK
(BTW a critical feature for a contrib module? reassigned the priority)
Comment #31
ferrangil commentedAs said in #28, I also have a large taxonomy and this what I need.
I have redirected each term to its corresponen node, using taxonomy_redirect, so I also want to redirect to each node when I click on the menu.
I applied your patch, jadwigo, but I can't detect any different funcionality or whatever... Any hints?
Comment #32
jadwigo commented@ferrangil - there is no difference, because with my patch the taxonomy_menu page is redirected to the normal taxonomy/term view that you can change.
Using taxonomy_redirect would override that again, and then it won't work again.
Comment #33
summit commentedSubscribing. Noticed there is a taxonomy menu plus now?
http://drupal.org/project/tmp may be integration necessary?
greetings,
Martijn
Comment #34
Spames commentedThis seems to work perfectly for me! -- I can specify the view to use to display the content. Just what I needed! - Thanks
Comment #35
ferrangil commented@ jadwigo - Still trying with your patch, without success. I need to leave the taxonomy_redirect active because when I click the breadcrumb, I want to go to the associated node of that term, instead of going to the term page (which will display the link to the node, so I avoid that stupid click and I go direct to the "content").
With your patch applied, I'm still seeing the link in my menu like ../taxonomy_menu/2/212 or whatever... From your words I understand I should see something like .../taxonomy/120 (where 120 is one term id...).
I opened the taxonomy_menu.module and your changes are in it, so I applied the patch correctly.
What I'm missing? My menu is always pointing to taxonomy_menu....
Thanks!
Comment #36
jadwigo commented@ferrangil: you could try to modify my code to output
instead of
Please note that is not a ready solution and a some programming is required to make it work
Comment #37
ferrangil commentedNo changes.
I'll look at the code to see if I could change something else. I'm still viewing all links as ../taxonomy_menu/.... so my system doesn't use your function..
Odd!
More suggestions?
Thx
Comment #38
brmassa commentedGuys,
im a new maintainer and i just launched the new version of the module. it now has this feature.
regards,
massa
Comment #39
Anonymous (not verified) commentedAutomatically closed -- issue fixed for two weeks with no activity.
Comment #40
Raveler commentedHello guys,
It seems that none of the proposed solutions work with the newest version of Drupal.
To get Taxonomy Menu working at all, you first need to apply the patch mentioned in:
http://drupal.org/node/263766
Also, make sure you use the dev version.
Then, to get views working, I found an easy fix, based on the previously posted solutions (which don't work anymore).
To get it to work, you just need to change the lines 268-270 in taxonomy_menu.inc:
.. to the following line:
This will add the term id as the first argument. Make sure the name of the view is the actual name used by views to identify the view, not the title or the path or anything. If this doesn't work, let me know, I'll look into it. It worked for me though.
Comment #41
vvvi commentedDrupal 6.4 It doesn't work still.
Replasing
.. to
not help.
Any ideas, please.
Regards,
Viktor
Comment #42
vvvi commentedI have done some changes and now it works good. The worked file taxonomy_menu.inc for 6.x-1.x-dev is attached (rename taxonomy_menu.inc_.txt to taxonomy_menu.inc).
In views add arguments:
Taxonomy: Vocabulary ID
Taxonomy: Term ID
Was done next changes:
Firstly applyed patch http://drupal.org/node/263766
Function
was changed to (not only uncommented)
Also function
was changed to
Hope it help.
My best regards,
Viktor
Comment #43
summit commentedHi,
Could this patch also work to get the possibility to use different names for different taxonomy/term depth levels?
I need for every depth level the possibility to get a new url_argument instead of category or taxonomy/term to trigger a different template.
Thanks in advance for your answer!
Greetings,
Martijn
Comment #44
derhasi commentedI improved the code of VVVi and applied it to the current dev. So now views_page() is used. This overrides the tm-page view with the views-view. So you now can set title and breadcrumb with the view's settings.
Attached a .patch on current 6-dev.
Tagged post to Version 6-dev and component: code.
Comment #45
derhasi commentedIt also fixes argument problems, when no $tid is present. ($vid != $tid) does not work because e.g. voc #1 can have a term-id #1.
Comment #46
Afief commentedOkay guys I realize that Views integration is one of the most important things for a Drupal Module, especially a module like Taxonomy Menu.
I'd like to finish some refining of the Menu code before working on Views integration because the way Menus are handled right now creates a serious bottleneck for what can be done(moving Menu items around and still being able to get the right breadcrumb for example.)
Keep polishing that patch because I haven't read the Views API yet and will probably be too lazy to do proper research :-P
Comment #47
summit commentedHi,
Please do not forget Drupal 5 people here
Thanks for considering!
greetings,
Martijn
Comment #48
Afief commentedHey Summit,
Unfortunately I am very inexperienced with Drupal5. Although I read the Drupal Pro Development book(based on Drupal 5) I've never actually written any D5 code and only ever built 3 Drupal5 sites.
I know this is a bad thing in a maintainer, but my first priority will be the D6 version, god knows there are only a few months left before Drupal 7 is scheduled for release.
Of course I'd like leaving the D5 version in an at least working(tm) state(I don't know, is it working? the issue queue suggests it isn't) but I simply don't see there being enough time between fixing the D6 version, my dayjob and the D7 release.
Comment #49
hutch commentedI for one also want to get D5 sorted and I will be keeping a close eye on the development of D6 with the aim of backporting code as Fief tidies things up in D6.
Comment #50
scottrigbyHi derhasi,
The patch in #44 has some failed hunks against the current dev - but I looked in the .rej file and seems this is already in the .inc file - does this mean these changes were already included in the committed to the current dev version?
here's what my command line said:
BTW, the project page says it does already integrate with Views?
Thx for any clarification - since the main reason I want to use this module is for it's Views integration.
Cheers :)
Scott
Comment #51
Afief commentedthe Drupal5 version apparently used to work with Views(not sure if it currently does)
the Drupal6 version definitely does not work with views yet.
Comment #52
soliaris commentedHello,
#42 and #44 works fine with first level of taxonomy hierarchy -> category/vid/tid.
I am using multiple levels of taxonomy hierarchy and would like to have view with arguments. In view configuration I am adding view path like category/%, so for cat/vid/tid - is ok, first argument is vid, second is tid. How about vid/tid/tid - shall I use 3 arguments and argument #3 is actual, for vid/tid/tid/tid - 4 arguments and argument #4 is actual? Is my understanding correct? Secondly - how view will know which argument to use - #2, #3 or #4 if path one time can be vid/tid, another vid/tid/tid or vid/tid/tid/tid...
Best regards,
Soliaris
Comment #53
kingandyFrom my modest experience with taxonomy_menu and views, I seem to recall the VID and the last TID get passed through as arguments - so all you need to do is create a single view with 'Taxonomy: Vocabulary ID' and 'Taxonomy: Term ID' as arguments. The vid/tid/tid/tid notation is purely to establish the menu structure.
Don't specify the arguments in the view's path (eg. category/$arg/$arg) - just give it a path of 'category' and let the arguments sort themselves out.
Comment #54
scottrigbyAfief, what do you think of this solution? http://drupal.org/node/315488#comment-1046168
I'd like to invest energy in a direction that is likely to be maintained - or at least is a viable direction.
Cheers :)
Scott
Comment #55
derhasi commentedAfief and me are working on a total rewrite of the module in the moment. So integration of other modules would be much easier.
Comment #56
summit commentedHi, Derhasi, your remark about the total rewrite asks me the following.
Please keep the category/VID/TID/TID etc.. as one of the options. A site of mine depends on this logic. Thanks in advance for considering this. Just a remark, not intended to hijack this thread.
Greetings, Martijn
Comment #57
derhasi commentedWe will implement a hook, that lets other modules build their own "path generators", so we will become flexible for a lot more tasks;)
Comment #58
karens commentedThere's a working patch at #333145: Views integration for Views integration, so I think this is a duplicate, even though it is older. Apologies if I'm closing this inappropriately.