I'm using the taxonomy terms associated with project in a somewhat unusual way, and when I do so the links to my taxonomy terms on the project overview page are bad. The taxonomy term links on the individual project pages, however, are fine.
Let me explain in more detail.
I have 2 vocabulary terms which both have 'Project' as the only type of node they are associated with. For example:
Project Type (vocabulary term created by project.module)
-Windows
-Macintosh
Project Category (vocabulary that I created)
-Graphics
-Utilities
-Developer
The more standard way to organize these terms would be like this:
Project Type (vocabulary term created by project.module)
-Windows
-Graphics
-Utilities
-Developer
-Macintosh
-Graphics
-Utilities
-Developer
The downside of doing it like this (the standard way) is that then I have 2 terms with different parents, and so I can't look at all projects that are Utilities at one time (I would have to view windows or macintosh separately).
So, when using taxonomy organized in the way shown in the first example, when I go to my projects overview page at /project/windows, the links to my terms look like this:
/project//category/1 (note the double slashes) which is an invalid link.
This patch provides a new option in /admin/project/project-settings called "Path to use for taxonomy terms". The default setting is to keep things as project.module currently implements them--that is, using the project_term_path() function. The other option is to use the taxonomy_term_path() function which sets the path to the page for the given taxonomy term.
The setting name/description are probably not ideal. If you're interested in this path, I can change those to something if you have a better idea.
I've tested this patch and it works fine on my installation.
AC
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | project_overview_taxonomy.patch.txt | 1.41 KB | dww |
| #3 | project_term_path_1.txt | 515 bytes | aclight |
| project_term_path_0.txt | 1.53 KB | aclight |
Comments
Comment #1
dwwi certainly believe your bug report, but i don't quite understand what's actually going wrong. ;) if you just have 1 tier of taxonomy terms in the project.module-provided vocabulary, none of the links should be broken. certainly, you're not going to get the built-in functionality of the "Browse by category" stuff, or the funky UI on the project edit forms. but, project.module and all the taxonomy terms should work just fine for the project-specified vocabulary terms.
is the problem that it's being over-ambitious, and assuming that *all* taxonomy terms associated with a project node belong to the project-specific vocabulary? if so, that's a crappy bug. luckily, the fix is trivial: when looping over the terms, we just have to compare each term's vid (vocabulary id) with _project_get_vid(), and conditionally use taxonomy_term_path($term) or project_term_path($term) depending on the vid. looking more closely, that seems to be exactly the problem. so, we don't need the new setting at all (which absolves us of the problem of figuring out the right text for the UI), we just need to be a little smarter as we populate
$project->termsnear the end ofproject_page_overview().make sense? can i leave it in your able hands to re-roll a patch for this new approach and confirm that fixes the problems you're having on your site? while we're at it, we should audit project* for other places we call project_term_path() and make sure we don't have the same bug anywhere else.
thanks,
-derek
Comment #2
aclight commentedYou've got it--the problem is that project.module is being over ambitious. Taxonomy terms that aren't under the "project types" vocabulary have bad links.
Your solution sounds like a better option. I will try to take a look this weekend (or maybe sooner) and try to fix the problem that way. Assuming I do, I'll re-roll the patch and post it.
AC
Comment #3
aclight commentedok..just kidding about the weekend. That was a very easy patch to make. I didn't find
project_term_pathanywhere else in the project* module (I looked at theproject_releasetoo). This patch works as expected on my site, and both terms outside of the main project $vid and those within are linked to appropriately.AC
Comment #4
dwwthis is a bug:
$project->vid == $vidyour patch is always calling taxonomy_term_path(), never project_term_path().
however, your patch still works since taxonomy_term_path() itself invokes project_term_path() if appropriate (see the docs for hook_term_path()). ;) so, even simpler would be to just always call taxonomy_term_path() there, and let it do the magic.
but, i've got an even better approach... stay tuned for a new patch, coming right up...
Comment #5
dwwproject.module never seems to have been fully ported to the 4.6.x core API. ;) it's re-implementing a bunch of its own taxonomy stuff that core handles itself. this tendency for project to do its own thing with taxonomy all over the place is the source of the bug here, but it also means we're a) duplicating code and b) not getting consistent functionality with the rest of how Drupal handles taxonomies. for example, everywhere else on the site, if a taxonomy term has a description, a link to that term shows the description in a mouse-over link title attribute. not so on the links on the project overview. :(
so, here's a new approach: use the core taxonomy API for this stuff, instead of re-doing the work ourselves (incorrectly). ;)
tested locally and it's working great, even with term descriptions. would just like to hear that it's still working as expected on your site, too. if that's the case, please mark this RTBC and it'll go in this afternoon.
thanks!
-derek
Comment #6
aclight commentedGood idea. This works as expected on my site.
AC
Comment #7
dwwcommitted to HEAD. backported and committed to DRUPAL-4-7--2 and DRUPAL-4-7.
Comment #8
(not verified) commented