panels_views isn't picking up the correct "view type" settings when using "block" - it just takes it from page.
I have a view which just generates a block, using the "table view", with the title and comment count of posts, and a taxonomy term name argument. Page view settings have never been touched.
To begin the process of setting up my views for "panels_views" so I can switch off the legacy module, I enabled this view and set it to use the "block" style. However it shows up as a full node display instead.
I edited my view, and change the page settings from the default "full nodes" to table. This fixed it for me, and is true whether "provide page" is checked or not - whatever setting I have in page completely overrides what I have in block.
It's easy for me to use page views with no blocks instead - this is a very old bad habit I picked up with Panels 1/blockcache before I used arguments within panels. But still seems to be odd behaviour, and not right if you have a view that's generating both.
Comments
Comment #1
merlinofchaos commentedThat is definitely wrong behavior; I immediately suspect that it is not using the correct view type and passing through the wrong value.
Comment #2
catchUpping status since there's no way to pick manually in the panels form either now - so it makes using the "block" view impossible using panels_views as far as I can see.
Comment #3
merlinofchaos commentedYou can still use the panels legacy views module which replicates the old views.inc functionality. I tried not to strand people while we worked out the kinks of the new module =)
Comment #4
catchYes panels_legacy_views is very handy, thank you - a cross-link for anyone who doesn't know what it is: http://drupal.org/node/205590
Comment #5
merlinofchaos commentedThe most recent patch here includes a fix for this: http://drupal.org/node/205567
Comment #6
merlinofchaos commentedHm. Not really fair to call this a dup
Comment #7
catchWell, it's kinda a dup. Might as well leave it open but mark it as such when the other one's committed. (thanks wim in absentia)
Comment #8
catchPatched with http://drupal.org/node/205567#comment-676600 - all working for me now.
Comment #9
merlinofchaos commentedThe referenced patch is now committed to dev.
Comment #10
Anonymous (not verified) commentedAutomatically closed -- issue fixed for two weeks with no activity.