PHP filter not working
mariuss - March 14, 2009 - 09:19
| Project: | Taxonomy Redirect |
| Version: | 6.x-1.3 |
| Component: | Code |
| Category: | bug report |
| Priority: | critical |
| Assigned: | Unassigned |
| Status: | closed |
Jump to:
Description
The PHP filter does not work for anonymous users.
Could not figure why, the implementation seems to do the right thing. But it is not happening for sure, for anonymous users the new term URL ends up being the raw PHP code (it is not evaluated).
#1
Hi mariuss,
When I have seen this problem it is related to the users tables in the database (It should not be a taxonomy redirect issue).
Try the solution here - http://drupal.org/node/264132#comment-897990
Making sure you have the two database entries in that post should fix your problem.
Let me know if this fixes your problem.
#2
The users 0 entry is there. The users_roles for this user is not there, and I don't think any drupal site has that by default.
Also, I do have pages that use the PHP Filter and anonymous users can view those pages just fine.
I will try inserting he users_roles row and test it like that, but that will be in a few days.
Thanks.
#3
I am having the same problem, and inserting those roles didn't help. Any other ideas? When logged out, the link shows the full php code including <?php, its embarressing.
#4
As a temp fix I found I could just evaluate custom code and return the result around line 431. So basically just add your code there instead of in the taxonomy php code field. This would only work if all your redirects are the same.
<?php
//return taxonomy_redirect_default_term_path($term, $path, $separator, $remove_text); royce_mod made my own php code here
$your_code="<?php \$url='http://uberattire.com/fastsearch/*/".$term->tid."?';
foreach(\$_GET as \$name => \$value) {
if(\$name!=='q'){
\$url.=\$name .'='. \$value.'&';
}
};
return \$url;
?\>";//delete this backslash, its just for the drupal code appearance
return drupal_eval($your_code);// replace the "taxonomy_redirect_default_term_path with this
?>
#5
I've found something that works for me, but again, it's somewhat hackish.
I think the problem is situated in the
taxonomy_redirect_get_php_filter()function, which uses filter_formats (http://api.drupal.org/api/function/filter_formats/5). For anonymous users, this function only returns the "Filtered HTML" filter, and no PHP filter. Therefore,taxonomy_redirect_get_php_filter()returns the default 0 value.For me, everything works fine when I change the default "0" in line 220 into "2", which is the filter code for PHP (you might want to check if this is 2 for you too in the filter_formats table in your database). Ofcourse, you don't need the rest in the function anymore after that, but it doesn't hurt either, so I left it.
Beware that I'm not a Drupal expert, so while it seems to be a safe hack to me, you might want to check it a bit further yourself first. The advantage over divinevette's fix is that you can still define multiple redirects...
#6
It seems strange to me that filter_formats() would be called here, since that's designed to return only filters that the end user can use when entering content. In this case, the user isn't entering code, it's all stuff that's happening behind the scenes. This problem does not just affect Anonymous users, it affects authenticated users who (rightly) don't have permission to enter PHP code in text areas.
So, it seems that the correct fix for this would be to create a custom function that does essentially what filter_formats() does, but without the added permission checks. I couldn't really find a suitable function in filters.module, but I didn't spend too much time looking.
doing it this way would have the same end result as hardwiring the filter id, but since that number can change from installation to installation (we're 5 for PHP code), it should be abstracted. If i have time i'll try to put together a patch.
#7
I wouldn't even use the PHP filter of the checks from that.
Instead, see what Views module does for PHP input in headers and footers or argument code.
See also #606864: give the PHP code variables.
#8
#606864: give the PHP code variables has nothing to do with this issue.
This one needs fixing asap though so I will get to is shortly.
Patches will make the process faster as usual.
#9
jefke33 is right. The problem is that filter_formats() only returns filters that the current user can use. I've created a temporary fix for the 6.x version by duplicating the filter_formats() function in 6.x, naming it taxonomy_redirect_filter_formats(), and changing the $all variable to be TRUE. This way all filter formats are returned, regardless of access permissions. I then changed all references to filter_formats() to my new function. This approach would work just as well in 5.x. Definitely a huge but that needs to be resolved ASAP by the maintainer. This was so easy to fix, I can't believe it's remained unresolved for so long.
#10
I have committed a fix for this to the 6.x-1.x branch
#11
Fix committed to 5.x-1.x branch
#12
Automatically closed -- issue fixed for 2 weeks with no activity.