Having the possibility to create a Panels context from a space is sometimes very useful. Here is a first patch that makes it possible to create a context from a taxonomy space.
Ideally the context should be defined by an argument to the panels (as context usually are brought in hard coded). But this isn't really possible as all spaces isn't always accessible directly from the URL. Also, the menu path taxonomy/term/%term can't take additional named arguments if it shall behave as expected. So, by design, we have to "fake" the Panels context so Panels thinks it's available as replacement tokens and input arguments etc. Otherwise it won't. I don't think this won't be a problem in the reality, as all the values are available when the Panel will be executed in the space.
After a short review, I'll implement the user and possibly OG support too.
Comment | File | Size | Author |
---|---|---|---|
#4 | spaces_panels.zip | 6.4 KB | davidburns |
#1 | spaces_panels.patch | 7.52 KB | Jon Pugh |
spaces-panels-1.patch | 3.32 KB | dixon_ |
Comments
Comment #1
Jon PughHere's a mega patch, an entirely new submodule: spaces_panels.module
Basically its full Panels integration, allowing for Panels to be used in the creation of full-fledged OpenAtrium features:
- Context: Adds "Space: OG Node Context" or "Space: User Context" to load current space's user or group node content. TODO: Taxonomy
- Access Plugin: Adds "Space: Feature Access" selection rule. Use this to have access control on Panels with menu items that you want controlled with the Features/Spaces UI. Same functionality of the Views access plugin, used to build Open Atrium
Needs Work:
- The two context plugins should load themselves automatically if they exist, just like the "Logged in User" context that is always present. This patch will not recognize your Spaces unless you manually add the one of the new "Space: xxx Context" contexts. I am looking into how to do this.
- Taxonomy Space Context.
Been doing some amazing things with this setup... "Context Exists" access checks are great, if its in a group, show one variant, if its in a user-space, show another.
This is much more powerful when you check out the other patch I just loaded, which makes users have their own path and space available, just like a group. This means, /blog can be /groupname/blog or /username/blog, using panels or views. Pretty fantastic.
Thanks!!!
P.S. still getting used to making patches with Git, if there's anything wrong let me know and I'll try to fix it.
Comment #2
Jon PughCrudd... just realized this was built for beta4... updated patch coming soon, hopefully....
Comment #3
davidburnsSetting back to active. This is something I'd be interested in and am attempting to update the patch to work with 6.x-3.0
Comment #4
davidburnsHere's an updated version as a zip file.
Comment #5
johngriffin CreditAttribution: johngriffin commentedThanks for this, it's working for me to set access permissions on a panel based on Spaces: Feature Access. However, I'm seeing the following error messages:
The plugin definition of spaces is missing the title singular key. [error]
The plugin definition of spaces is missing the title plural key. [error]
The plugin definition of spaces is missing the title singular proper key. [error]
The plugin definition of spaces is missing the title plural proper key. [error]
The plugin definition of spaces is missing the schema key.
Comment #6
Majdi CreditAttribution: Majdi commentedsubscribe
Comment #7
Nigel CunninghamSubscribing, because I'm about to try the module in #4 out.
Comment #8
SocialNicheGuru CreditAttribution: SocialNicheGuru commentedThis is AWESOME concept.
I was just asking about this on IRC.
I will try this out.
Comment #9
SocialNicheGuru CreditAttribution: SocialNicheGuru commentedI see the same thing as in #5.
I can select the "Spaces: OG Node context" as a selection type for my panel.
It has no effect. The panel page is not accessible.
Edit:
I can use this module and og_panels to get an OG_conext for the group node and pull in description.
Comment #10
SocialNicheGuru CreditAttribution: SocialNicheGuru commentedI am placing errors for the zip file in #4 here
I select Spaces: Feature Access as a context and get:
warning: Missing argument 2 for spaces_feature_access_settings(), called in /openatrium/modules/contrib/ctools/includes/context-admin.inc on line 632 and defined in /spaces_panels/plugins/access/spaces.inc on line 22.
warning: Missing argument 3 for spaces_feature_access_settings(), called in /modules/contrib/ctools/includes/context-admin.inc on line 632 and defined in /spaces_panels/plugins/access/spaces.inc on line 22.
Comment #11
SocialNicheGuru CreditAttribution: SocialNicheGuru commentedI get this on admin/reports/status
Comment #12
webankit CreditAttribution: webankit commented+1
Comment #13
HumanTex CreditAttribution: HumanTex commented+1
Comment #14
gmclelland CreditAttribution: gmclelland commentedJust curious, does this allow for per space customizations to the panel page? I'm not talking about creating variants per space. I was hoping I could use Panels to build the default panels pages for a feature, but still allow the user to override those pages per space. Ex. choose different layouts per space
Spaces Dashboard does this with Contexts. You create the default context to display the boxes and any overrides are specific to that space.
Anyways, Spaces + Panels + Panels IPE would be awesome. Plus it would give end users a consistent editing user interface to work with.
Comment #15
SocialNicheGuru CreditAttribution: SocialNicheGuru commentedI used panels for the content are only.
context handled all the other regions.
So define your different layouts via context and just allow panels to handle the content region.
Comment #16
SocialNicheGuru CreditAttribution: SocialNicheGuru commentedcan this be ported to 7.x too?