Closed (fixed)
Project:
Taxonomy Redirect
Version:
6.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
14 Mar 2009 at 09:01 UTC
Updated:
25 Feb 2011 at 14:39 UTC
Jump to comment: Most recent file
Comments
Comment #1
agileware commentedI have added it to the enter path description and the readme. I also made a couple of other updates to the readme as it was a little out of date.
These changes should be in the dev version sometime today and in the next release.
Comment #3
doublejosh commented$tid seems to have no value for me?!
Comment #4
friolator commentedI'm using the latest dev release, and $tid is coming up blank every time.
Comment #5
friolator commentedComment #6
friolator commentedJust to clarify what I'm seeing:
We're using taxonomy redirect to change a path from taxonomy/term/[TID] via a custom module of our own that handles some rewriting of URLs and paths. I've ruled out our module, which works correctly if I hardwire a tid in the php editor in the taxonomy redirect admin page. That is, if I pass our function a valid tid such as "497" it works perfectly. If I pass it the variable $tid, it comes up blank. So in tracing this back, I located what I think is the code in the module, at line 506:
I changed that to:
...and it had no effect. The value of $term->tid is not empty, though. sending that out to watchdog from within taxonomy_redirect.module shows that line 506 has the correct value for $term->tid, it's just not getting picked up by the $tid in our PHP.
In the PHP evaluation textarea, here's our code:
cd_misc_generate_link() is a function that creates a link or a path. the watchdog call returns nothing. Again, this works perfectly if we hardwire a $stuff[id] value, but not if we use $tid, so the problem is somewhere in the taxonomy redirect module. I've tried following the code, but i'm not familiar enough with the PHP filter to know exactly what's going on.
Comment #7
friolator commentedOk, figured this out. The problem seems to be that at line 515, the wrong string is being passed to check_markup():
should be:
Patch attached, rolled against the latest dev build.
Comment #8
agileware commentedMarked #606864: give the PHP code variables as a duplicate of this issue
Comment #9
agileware commentedCommitted fix in #7.
Thanks for the patch friolator.
Comment #10
friolator commentedcool!
Comment #12
alanom commentedAny chance of resolved, tested bug fixes like this being migrated into the stable/recommended release? A year on and this is still broken in the (2008) 6.1.3 stable release.