Custom PHP Code fails to get the context argument when logged out (anonymous user)
agrivas - August 23, 2008 - 17:49
| Project: | Panels |
| Version: | 5.x-2.0-rc1a |
| Component: | Panel pages |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | postponed (maintainer needs more info) |
Jump to:
Description
First of all thanks for the great module. Please get it into the core!
My problem is that when I try to get the context argument from custom php code, I get nothing if the current user is the "anonymous user". I have checked the permissions "view all panes" and "access all panel-pages". Note that the page works correctly when I am logged in as Administrator. Here is my code:
$myterms = taxonomy_get_children($context->get_argument());
$block->content .= '<table cellpadding="0" cellspacing="0" border="0" width="100%">';
$block->content .= '<tr>';
$counter = 0;
foreach ($myterms as $myterm)
{
if($counter % 4 == 0) $block->content .= '</tr><tr>';
$block->content .= '<td width="25%">';
$default_term_view = l(t($myterm->name), taxonomy_term_path($myterm));
$block->content .= $default_term_view;
$counter++;
$block->content .= '</td>';
}
$block->content .= '</tr></table>';I am sorry in advance if it is a stupid permissions mistake of mine.
#1
Quick clarification - you 'get nothing' as in, when you try to view that pane as an anonymous user, nothing shows up? Or you 'get nothing' as in you can only edit that pane as an administrator? If it's the second, that's by design; if it's the first, that's harder to say off the top of my head.
#2
I mean the first of course. For a strange reason this piece of code produces correctly the table with the child terms if I am logged in and only the top level terms, even if the argument is different, when logged out. If you try to print out the context argument
$block->content .= $context->get_argument()I get the correct argument when I am logged in and nothing when logged out. Given the argument is missing the rest of the code gives unexpected output (always the top level terms for this specific example).I hope it was helpful. Thanks for your interest!
#3
i had the same issue for authenticated users and had to enable the permission for 'administer filters' to allow the context to be pulled out. might give that a try.
#4
@fluxline: You know that granting the 'admin filters' perm hasserious security implications, right?
So the way I wrote this content type, it's only supposed to be usable (that is, can be added & edited) by users with access to the PHP filter. However, viewing is another matter entirely - that check _should_ be irrelevant. From what fluxline has said, it sounds like that's not actually the way it's working - you need the admin filters perm to even see the output. I'd swear I tested it and found that wasn't the case...but eh.
I don't have time to look into this before Szeged, but I will later.
#5
@agrivas - more importantly though. Why, oh why oh WHY use the custom PHP code pane for this? That code you posted is getting into some relatively complex logic - you wouldn't have to worry about any of this if you just wrote a quick custom content type plugin. The custom PHP code pane is really nothing more than an ugly, dirty hack; simply writing it at all was painful for me. I only did it because the "I just need to see how this works quickly" use case is legitimate - actually using it on a real, live site is a bad idea from several perspectives.
#6
First of all thanks for your replies.
I think I got the answers I need. To sum up there are 2 options:
1. Grant permission for PHP filter to anonymous user (security issues)
2. Write a panels' plugin to do the work (reusable and clean solution)
I am aware of the design issues about using Custom PHP Code and I plan to factor out such tricks. However, I wanted to make this work really quickly for a draft and noticed this behavior. Since this is the way it is designed to work and given that setting the permissions works for testing (I haven't tried it yet), I guess you can consider the issue closed.
#7
@agrivas - I can't even tell you how happy it makes me to hear that :) It's FAR more common for people to complain when I suggest they write a quick content type plugin. You've not only not complained, but you've listed off the reasons that I myself usually give! Actual plugins are SO much more powerful, to say nothing of the potential for inclusion in opcode caching (the custom php code pane uses eval(), nixing opcode caches), and the other points you've already covered. You're one of the few I can stamp as using this "As Intended" - quick test purposes for a draft, for which I 150% support its use :)
So yeah. My pleasure to help =)
#8
i do know it is a security risk and will also do a plugin once i have all the pieces in place . but thanks for the reminder.
#9
Well, I fell in the same trap :)
I 100% believe that content type plugins are better, and for that reason I strongly suggest that a note is added to this custom PHP content type making it clear that this is to be used for development only.