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.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Jon Pugh’s picture

Title: Panels contexts from Spaces » spaces_panels.module: Full Spaces/Panels Integration (Patch!)
Version: 6.x-3.0-beta3 » 6.x-3.0-beta6
Assigned: Unassigned » Jon Pugh
FileSize
7.52 KB

Here'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.

Jon Pugh’s picture

Version: 6.x-3.0-beta6 » 6.x-3.0-beta4

Crudd... just realized this was built for beta4... updated patch coming soon, hopefully....

davidburns’s picture

Version: 6.x-3.0-beta4 » 6.x-3.0
Status: Needs review » Active

Setting 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

davidburns’s picture

Status: Active » Needs review
FileSize
6.4 KB

Here's an updated version as a zip file.

johngriffin’s picture

Thanks 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.

Majdi’s picture

subscribe

Nigel Cunningham’s picture

Subscribing, because I'm about to try the module in #4 out.

SocialNicheGuru’s picture

This is AWESOME concept.

I was just asking about this on IRC.

I will try this out.

SocialNicheGuru’s picture

I 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.

SocialNicheGuru’s picture

I 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.

SocialNicheGuru’s picture

I get this on admin/reports/status

Panels operating in Legacy mode	
Panels is operating in Legacy mode due to the following issues:
Panels 3.6 made changes to the rendering order in a way that affects certain style plugins. The above modules implement style plugins, but have not indicated their compatibility with this new system. See http://drupal.org/node/###FIXME for information on how to update style plugins to the new system.
spaces_panels - Style plugins
webankit’s picture

+1

HumanTex’s picture

+1

gmclelland’s picture

Just 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.

SocialNicheGuru’s picture

I 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.

SocialNicheGuru’s picture

can this be ported to 7.x too?