Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.I'm looking for the following functionality that could potentially be very useful to others as well: panelizer variants.
My use-case: we'd like to provide a different panel containing node content based on whether the user is authenticated or not.
If you select 'allow panel choice' you currently get the option of creating different variants with different access setting under Panelizer. I'd also like to be able to specify a fall-back: if the access-check fails on each variant, use the next variant. Like how regular Panel variants work now.
And, in fact, In one case I don't want to allow users to select the panel per-entity (which is the reason for the current variant functionality), so it would be nice if that's settable within this screen in the case that you do have multiple variants working in that way, but don't want users to be able to choose.
In each case we could use Panels to do this, but want the benefits of Panelizer wrt node-type and individual panelized entities.
Comments
Comment #0.0
Renee S commentedUpdated issue summary.
Comment #0.1
Renee S commentedclarify, update
Comment #0.2
Renee S commentedUpdated issue summary.
Comment #0.3
Renee S commentedUpdated issue summary.
Comment #0.4
Renee S commentedUpdated issue summary.
Comment #1
Renee S commentedClarify title
Comment #2
damienmckennaLooking at it more closely, you sort-of can already do some of this using the Access settings for each Panelizer default.
Comment #3
Renee S commentedYeah, sort of! But if for example I set access settings on a panelize default then it asks for login credentials -- desired behaviour is to have it fall back to the next variant on the list.
Comment #4
damienmckennaAh, yes, I see the issue.
@merlinofchaos: What do you think?
Comment #5
merlinofchaos commentedI think the simplest way to achieve this is to use view modes, and then use an alter hook to switch the view mode appropriately: http://api.drupal.org/api/drupal/modules!system!system.api.php/function/...
It requires a little bit of code, but that code is only a few lines, most likely, and probably easier to maintain than variants in any case.
Comment #6
merlinofchaos commentedYou could also potentially do it without code, actually. You could put it all on the node_view variant. Now, in an ideal world, you could use the Panelizer task handler to just display the appropriate panel, but it doesn't actually contain a setting to choose the view mode; it only supports the 'page manager' view mode. However, a patch to do that wouldn't be that hard (it isn't super simple because those particular plugins are difficult to code) but would probably be a fun couple of days for someone and it has uses in other areas. So I'd definitely entertain the patch.
Comment #7
merlinofchaos commentedNote that even without the panelizer task handler re-coded, you could use a single region panel and the normal node view pane. You get a little extra markup that way and a panel you don't really need (though you can make a markup-less layout and use the no markup pane style and eliminate most of it).
Comment #8
Renee S commentedCool, thanks - I'll explore these and see what we can do, and contribute back what I discover :)
Comment #8.0
Renee S commentedUpdated issue summary.
Comment #9
b-prod commentedMarked #2084137: Access rules have no effect in list of available displays as a duplicate.
I set this issue as a bug report because the access rules are not saved correctly in a panel variant. There is also a feature request under this issue, which relies on fixing the bug above.
Bug fix: The given patch create a new function
panelizer_ctools_access_get_objects_from_args()that processes the arguments ofctools_accesscallbacks as expected. So the access configuration is correctly saved on submit.Feature request: The patch also deals with the fallback behavior through access check. This is done in the
PanelizerEntityDefault::hook_entity_load()method.Comment #10
b-prod commentedComment #11
b-prod commentedThis patch only applies on the current 7.x-3.1 version, for those who do not want to use the DEV version of Panelizer (use -p7 parameter for patch, because I didn't use the Panelizer GIT repository).
I didn't specify that, but the #1978122-9: Allow Panelizer variants with fall-back to another variant if access requirements fail patch applies to the DEV version only.
Comment #13
sk33lz commentedI was unable to apply the last 2 patches against 7.x-3.x-dev or 7.x-3.1, so I re-rolled the latest patch against the latest panelizer-7.x-3.x-dev. Patch applies cleanly against 7.x-3.x-dev. Tested with variants with different user roles and visibility rules on individual panes. Fixes my issue.
Comment #14
b-prod commented@sk33lz: thanks. I left this issue because it seems asleep since a very long time, although the patch seems to work fine :-(
Comment #15
hanneshh commentedIve tried to patch the dev version of panelizer as well as the current 3.1 version and can't get the access conditions to work.
Has anyone actually gotten the patch to work and if so, which panelizer and patch version did you use?
Comment #16
Jorrit commentedI've updated the patch to be able to apply it to 7.x-3.x cleanly.
Comment #18
Jorrit commentedWeird that unit tests for patch 12 work, but not for patch 16.
Comment #19
Jorrit commentedI made two changes:
1. The default panel will always be tested for access first.
2. revision and entity id will be initialized with 0, otherwise other parts of the code think it is an entity specific override and overriding fails.
Comment #20
Jorrit commentedIk have to retract this patch because it caused problems at our site. We are going to try something else so I won't improve the patch.