If you use the node id arguement context and then change the layout for certain types of node context it will change the default panel, instead of the other context.

Here is a patch to fix this.

CommentFileSizeAuthor
#9 panels_layout.patch683 byteszroger
panels_layout.patch1.03 KBgordon

Comments

samsouk’s picture

samsouk commented

thanks, the patch works for me

I've put a backling on this issue : http://drupal.org/node/230149
and will report back here if I found any problem

niklp’s picture

niklp commented

Will test this today, have marked http://drupal.org/node/230149 as duplicate, seems to be the same thing.

sdboyer’s picture

sdboyer commented
Status: Needs review » Reviewed & tested by the community

Thanks for this, gordon. Appears to work on my sandbox; marking RTBC, I'll check back in on it and commit it a bit later.

niklp’s picture

niklp commented

Aaaaaand w00t say all of us. SDBoyer, this is one of the issues I was going to tap you about when you were free (if you even remember that IRC convo).

Fixed - great! :)

Anonymous’s picture

Anonymous (not verified) commented

I'm having superficial success with this patch, but I confront more difficult problems as described in this issue.

http://drupal.org/node/258055

Anonymous’s picture

Anonymous (not verified) commented

This patch hasn't been committed yet. I tried it again in BETA4 and I still have no love... titles based on arguments don't work, and bizarre things happen all over the place.

Is this issue still active? Is there another issue for the problem that is getting more attention? Different layouts for each type of node argument is just plain broken, innit?

sdboyer’s picture

sdboyer commented

Well, I don't quite know what I was thinking the first time around. This patch isn't the solution to this problem at all. The problem has to do with which display is loaded into $panel_page->display throughout the editing operation, not whether the panels_page_fetch_display() helper functions are storing data back properly. The actual issue is interwoven more deeply in the code, and has to do with $panel_page->display gets loaded in the first place. I don't have time to work on it at this very moment, but I'll come back to it when I can.

sdboyer’s picture

sdboyer commented
Status: Reviewed & tested by the community » Needs work
zroger’s picture

zroger commented
Status: Needs work » Needs review
StatusFileSize
new panels_layout.patch683 bytes

Following up on sam's comment I followed the code back to where $panel_page->display is expected to be loaded.

In panels_page_fetch_display() if no id is passed in (default display) then $panel_page->display gets set. But if an id is passed in then the display is returned, but not added to the $panel_page object. This patch fixes that in the same manner that $panel_page->display is populated when there is no id.

Anonymous’s picture

Anonymous (not verified) commented

I think Roger López has the magic!

zroger’s picture

zroger commented

Anyone willing to review this patch?

sdboyer’s picture

sdboyer commented

Yeah, sorry. Just swamped with other stuff. Checking it now...

sdboyer’s picture

sdboyer commented

Reviewed, working, good, RTBC, aaaaand...commited. Thanks!

sdboyer’s picture

sdboyer commented
Status: Needs review » Fixed
Anonymous’s picture

Anonymous (not verified) commented
Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.