Allow paths other than node/% (or other 'override' paths)

I have the same issue; it doesn't matter if I change the panel access from anonymous to authorized or all.

Yep - same here. Except I can only access it with admin, regardless of what is set.

Not only that, but the panels don't seem to be saving properly. If I tick various access levels on the panel setting and save, they don't come back saved, they come back empty. (Maybe this is a different bug, though, because it's happening with panel content too.)

Specialized router rebuild failure IS a very important clue, although I'm having difficulty figuring out how it could be related to...

OH WAIT! hahaha, i got it.

I had never anticipated that people would want to place arguments requiring the use of a loader somewhere OTHER than the place that they natively appear in the menu system. So, our menu system relies on the assumption that if you're doing node displays, you're doing them at node/%, because it merges in existing data that we know will already be stored at node/% and uses that to fill out the remainder of panels' own only-partially-defined menu item.

The access denied is coming up b/c there need to be explicit access checks on that path, but there's no access check defined on wildcard paths because, again, I'd been assuming that you'd only be overriding existing paths. Really no reason for that assumption.

What is weird, though, is that the specialized router rebuild is failing. I'll also roll in some changes which fix the behavior, and but will also expand that watchdog message, because right now it doesn't give any other info than a plain string. I'll need to know WHICH path is causing a failure to have a sense of how to fix this...

Subscribed

I have exactly the same problem. Please help anyone.

@netgenius - you are getting me right, but the sample code you've put there is producing bad results for probably a different, although somewhat related reason. Basically, when I wrote the original menu handling code, I wrote it with the assumption that people were going to be using wildcard-based paths purely and exclusively as overrides - that means that I wasn't really taking into account the possibility of something after the argument path, either. So basically, it's not inheriting some of the data it needs to properly - and because of the changes with access callbacks in 6.2, it's defaulting to restrictive.

I'm working on it.

I'm sorry, I really can't at this point - I'm really pressed for time at the moment, so it's best I spend time on fixing the problem rather than coming up with a good explanation. If you want to track the changes I make in CVS, keep an eye on panels_page/panels_page.menu.inc.

any news here?
I have this problem and it's really bad since i need to use arguments :(

@gattoplano - although support for non-override argument paths is clearly something that's important to provide, this issue does NOT mean that arguments aren't working at all. The most common cases - which are overrides - are working just fine.

...and now, hopefully, all the other ones will be too. I've just finished up a hefty refactoring that should take care of the argument woes. It's likely not completely solved - the thing is getting _very_ much more complex - but it should be quite a bit more challenging now to make it go boom. I'm marking this fixed; please reopen if you still see the problem in alpha2.

i am still facing the same problem!
http://drupal.org/node/320227
pls mark it as duplicate.

@himtuna - no you're not, that's a different problem. Also, anyone can mark issues as duplicates - and the devs very much appreciate when other people have the courtesy to do so and save us some time :)

Changing the title so that people can locate this more easily, as the underlying issue really isn't obvious from the title :)

The issue persists still in Alpha2 and also in the latest dev package (as of today), but only for "anonymous" users.

subscribed

subscribed too

Have some news since your last message ?

I've same error for same case.

thx

JC.

http://drupal.org/node/376312 possible duplicate?

On my system, this is solved for 6.x-2.x, but is still reproducible for 6.x-3.x alpha2. I suggest changing the version.

There is absolutely no way that this report applies to 6.x-3.x. It doesn't even have panel pages module.

merlinofchaos,

You're right, there is nothing like panel pages in in 6.x-3.x. Nevertheless, whenever I try to open a panel page that overrides node/% I get the mentioned error in 6.x-3.x (panels3 + views2) even if I am logged in (previously, this only applied for anonymous users in 6.x-2.x). Anyway, I leave the decision up to you. If you approve, I might open a bug report for 3.x. Thanks for the development and good work.

You're right, there is nothing like panel pages in in 6.x-3.x

Nevertheless, whenever I try to open a panel page that

Is this like when you try to use your non-existing third arm and it doesn't work?

Hi,
If someone experiences Access denied errors on %term (and maybe %user) panel pages,
ensure you have no View (Administer->Site building->Views) sharing the same path.

Hi, Thanks for this great remark!
I experienced the same situation.
But how can I now make a taxonomy term override panel using the taxonomy/term/% path view in a pane?
The panel should have the information from the taxonomy/term view and I do not see how this is possible by changing the path from the view...but the access denied is gone now!

greetings,
Martijn

subscribe

Hi,
I don't understand well what you were talking about.
I assume you've managed to sort out things well, but for others...

The access denied errors happen when you create a Panels Page, with an argument in its path, and this exact path is already occupied by a Views Page.

For example, you have made a view page located at taxonomy/term/%.
And later, you want to add some spice, so you want to make a panels page of it.
You then create your panels page, located at taxonomy/term/%.
You add contexts or/and relationships to your page.

And your panels page become unreachable.

You have only two choices :
1. Change your views path. For example, you can change it to taxonomy/term/%/normal
2. Make a block view with the same settings as your page view, then remove your page view, and use the block view in your Panels page.

Panels 2 is no longer available and is unsupported. Marking all Panels 2 issues won't fix.