Problem/Motivation

We need to chose a page building tool for Commons.

In general, some popular solutions for arranging the layout of content on a page include:

  • Context
  • Panels
  • Displaysuite

The Comparison of layout editors page on groups.drupal.org includes information on each of these options but could use review and enhancement to serve as a guide here.

Proposed resolution

Current proposed solution by Commons maintainer ezra-g is Panels, see comments below.

Remaining tasks

(reviews needed, tests to be written or run, documentation to be written, etc.)

Original report by ezra-g

We need to chose a page building tool for Commons.

In general, some popular solutions for arranging the layout of content on a page include:

- Context
- Panels
- Displaysuite

I propose that Commons 3.x use Panels as the page layout tool. Some benefits to using Panels:

- It has a large install base of Drupal 7 sites (around 110k total sites) and is actively maintained both by merlinofchaos and a community of contributors
- As the result of a wave of recent improvements, Panels provides a high level of user-friendly configurability for content-editors and non-technical users via Panelizer, the In-Place-Editor and more
- By providing alternative page layouts, it lets Commons meet feature requests like #1305906: Commons needs a 3 column theme without modifying the theme.

Currently Commons uses the Context system and ships with 56 default contexts:

grep -r 'context->name' *
commons_blog/commons_blog.context.inc:  $context->name = 'content-blog-page';
commons_blog/commons_blog.context.inc:  $context->name = 'group-blog-node';
commons_blog/commons_blog.context.inc:  $context->name = 'group-tab-blogs';
commons_core/commons_core.context.inc:  $context->name = 'bookmarks';
commons_core/commons_core.context.inc:  $context->name = 'global';
commons_core/commons_core.context.inc:  $context->name = 'group-context';
commons_core/commons_core.context.inc:  $context->name = 'group-home';
commons_core/commons_core.context.inc:  $context->name = 'group-listing';
commons_core/commons_core.context.inc:  $context->name = 'group-listing-mine';
commons_core/commons_core.context.inc:  $context->name = 'notices';
commons_core/commons_core.context.inc.orig:  $context->name = 'bookmarks';
commons_core/commons_core.context.inc.orig:  $context->name = 'global';
commons_core/commons_core.context.inc.orig:  $context->name = 'group-context';
commons_core/commons_core.context.inc.orig:  $context->name = 'group-home';
commons_core/commons_core.context.inc.orig:  $context->name = 'group-listing';
commons_core/commons_core.context.inc.orig:  $context->name = 'group-listing-mine';
commons_core/commons_core.context.inc.orig:  $context->name = 'notices';
commons_discussion/commons_discussion.context.inc:  $context->name = 'content-discussion-page';
commons_discussion/commons_discussion.context.inc:  $context->name = 'group-discussion-node';
commons_discussion/commons_discussion.context.inc:  $context->name = 'group-tab-discussions';
commons_document/commons_document.context.inc:  $context->name = 'content-document-page';
commons_document/commons_document.context.inc:  $context->name = 'group-document-node';
commons_document/commons_document.context.inc:  $context->name = 'group-tab-documents';
commons_event/commons_event.context.inc:  $context->name = 'content-event-calendar';
commons_event/commons_event.context.inc:  $context->name = 'content-event-page';
commons_event/commons_event.context.inc:  $context->name = 'group-event-node';
commons_event/commons_event.context.inc:  $context->name = 'group-home-events';
commons_event/commons_event.context.inc:  $context->name = 'group-tab-events';
commons_event/commons_event.context.inc:  $context->name = 'group-tab-events-calendar';
commons_event/commons_event.context.inc:  $context->name = 'profile-me-events';
commons_group_aggregator/commons_group_aggregator.context.inc:  $context->name = 'aggregator-group';
commons_home/commons_home.context.inc:  $context->name = 'home';
commons_home/commons_home.context.inc:  $context->name = 'home_anon';
commons_invite/commons_invite.context.inc:  $context->name = 'profile-me-invite';
commons_poll/commons_poll.context.inc:  $context->name = 'content-poll-page';
commons_poll/commons_poll.context.inc:  $context->name = 'group-home-poll';
commons_poll/commons_poll.context.inc:  $context->name = 'group-poll-node';
commons_poll/commons_poll.context.inc:  $context->name = 'group-tab-polls';
commons_profile/commons_profile.context.inc:  $context->name = 'profile-about-me';
commons_profile/commons_profile.context.inc:  $context->name = 'profile-about-other';
commons_profile/commons_profile.context.inc:  $context->name = 'profile-me';
commons_profile/commons_profile.context.inc:  $context->name = 'profile-other';
commons_profile/commons_profile.context.inc:  $context->name = 'profile-track';
commons_profile/commons_profile.context.inc:  $context->name = 'user-browser';
commons_reputation/commons_reputation.context.inc:  $context->name = 'activity-stream-most_active_users';
commons_reputation/commons_reputation.context.inc:  $context->name = 'user-browser-most_active_users';
commons_shoutbox/commons_shoutbox.context.inc:  $context->name = 'group-home-shoutbox';
commons_shoutbox/commons_shoutbox.context.inc:  $context->name = 'shoutbox-group';
commons_status_streams/commons_status_streams.context.inc:  $context->name = 'activity';
commons_status_streams/commons_status_streams.context.inc:  $context->name = 'group-home-status-box';
commons_status_streams/commons_status_streams.context.inc:  $context->name = 'profile-me-status-box';
commons_status_streams/commons_status_streams.context.inc:  $context->name = 'profile-other-status-box';
commons_subgroups/commons_subgroups.context.inc:  $context->name = 'group-home-tree';
commons_wiki/commons_wiki.context.inc:  $context->name = 'content-wiki-page';
commons_wiki/commons_wiki.context.inc:  $context->name = 'group-tab-wikis';
commons_wiki/commons_wiki.context.inc:  $context->name = 'group-wiki-node';

This makes customizing a specific page of the site more difficult for site builders and anyone who is not a savvy Drupalist. Frankly, having this many contexts can make customizing a page challenging even for a savvy Druapalist ;).

With Panels, the user could instead use the in-place-editor to modify a single landing page, which feels like a better fit for Commons' goal of being easy to use for both site builders and non-technical users.

Comments

iribarne’s picture

iribarne commented

IMHO, Panels has come a long way and it can give more control to the user, which is great for community sites.

izkreny’s picture

izkreny commented

Albeit I don't have experience with Panels, from what I have read, I like it more than Context - let's panelize Commons! ;)

About Display suite, I used it and liked it very much, there is new version (7.x-2.x) rolling out, and if we are not able to do things with Panels that you can easily do with DS, I would totally like to include it in Commons, with Panels, of course. ;) But, if Panels (w/ accompanied modules) can solve all scenarios, that would be great - one module to rule them all. :)

nedjo’s picture

nedjo
he/him/his
Primary language English
commented

I've redrafted the Comparison of layout editors page on groups.drupal.org. I suggest we focus first on enhancing that page, then draw some conclusions here.

Selecting the best layout and block placement solutions for use with a distribution is a question I've wrestled with. A key need specific to features is the ability for each enabled feature to add its content to a page layout. I use and like both Panels and Display Suite; but this ability to have a page that is a composite of elements from whichever of multiple features happen to be enabled, none of which is a dependency, is something I continue to look to Context for. I'm interested to hear others' experiences.

Gerben Zaagsma’s picture

Gerben Zaagsma commented

I am currently starting to build a Commons community website after having used Panels for another website. I find Panels much more flexible to use, and much more powerful, than Contexts (not being tied to regions, being able to put any content in a panel, etc.). So please let's go with Panels!

Best,
Gerben

ezra-g’s picture

ezra-g commented
Status: Active » Needs review

Thanks, @nedjo - It's great to have that comparison!

I made some enhancements to the comparison wiki and filed an issue in the Panels queue for one area that needs clarification.

My sense is that this comparison supports the proposal to use Panels as the main page building tool because of the refined in-place-editor, its tight integration with Views, flexibility (ability to add various types of content beyond blocks to a page, and the ability to provide content/layout defaults.

I'll leave this issue open for some time longer to allow folks to comment, but my sense is that we should move forward with the plan to build on Panels as the main page building tool.

IceCreamYou2’s picture

IceCreamYou2 commented

As I recall, one of the main reasons for dropping Panels from Commons (1.6?) was the fact that it slowed the page down by something ridiculous, like 30% or more. It's worth testing that again before moving forward.

I had also drawn up plans to build a "Panels Light" solution, but that obviously never happened.

ezra-g’s picture

ezra-g commented

As I recall, one of the main reasons for dropping Panels from Commons (1.6?) was the fact that it slowed the page down by something ridiculous, like 30% or more. It's worth testing that again before moving forward.

The removal of Panels predates my involvement in Commons. However, I think some profiling could be a good idea since we're certainly not suffering from an overabundance of performance data in this area ;).

It's true there are a lot of areas in Commons where basic, low hanging fruit optimization hasn't historically been done. Eg #1272620: Remove unnecessary distinct from views, add caching to Views blocks. I believe that removing Skinr also significantly decreased page load time, but both that change and the decision to swap Panels for Context predate the use of the Drupal.org issue queue, so it's hard to say definitively.

It seems like Context and Panels are the two most likely candidates. I propose we profile a basic page containing with some Views and a node built with each solution and compare the results.

For the page contents, I propose using:

[edited to remove redundant blocks]

- A "Recent content in your groups" block
- A "List of your groups" block
- A node in the page -- Would Context even let us place a node directly in the page without first getting it into a block somehow?

ezra-g’s picture

ezra-g commented

Would Context even let us place a node directly in the page without first getting it into a block somehow?

Well we still have the main $content area ;). We could also make a Views block to place the node.

nedjo’s picture

nedjo
he/him/his
Primary language English
commented

See Using Context Field, Boxes and Views Boxes for layout control for a explanation of what Phase2 is doing with context for layout control in their distros. It's from Sept. of last year, so details may have changed.

nedjo’s picture

nedjo
he/him/his
Primary language English
commented

Roughly parallel issue on Open Outreach: #1331150: Decide Open Outreach page layout approach for e.g. home page and section pages.

izkreny’s picture

izkreny commented

Interesting issue / discussion / project that could be also relevant: #1564856: Improve drag-and-drop content layout tools

aramollis’s picture

aramollis commented

In the same terms I ask for OpenAtrium... Is Panopoly a good option for Commons 3.x buliding page tool?

I also asked here: http://groups.drupal.org/node/227248#comment-756563

R.J. Steinert’s picture

R.J. Steinert commented

I think the real issue here is contextual configuration management. Spaces+Context handles this in Open Atrium and Panels handles in it's own context handling (from what I understand). Spaces and Context handle this beautifully in Open Atrium and I've always opted for OA over Commons because of the lack of contextual config in Commons (unless I'm missing something). I'm interested to know if the context management in Panels works as well. It's just hard for me to get excited about Panels when it works on top of Drupal as opposed to right next to it like Spaces and Context does. Granted, it's totally pretty and works well from what I can tell. But what about making a group type that has specific blocks exposed to it for placement in Panels? Is this possible in Panels? Perhaps Spaces+Panels could be a win? If so, then what does Panels do better than the Dashboard feature in Open Atrium? I'm under the impression that Panels works really well for people who want to build a new site with Panels but is it fit for the kind of distribution that is Commons?

ezra-g’s picture

ezra-g commented

Spaces and Context handle this beautifully in Open Atrium and I've always opted for OA over Commons because of the lack of contextual config in Commons (unless I'm missing something)

Commons has used the Context module since the 1.6 release in June of 2011 as far as I can tell from the release notes (this predates my time working on the project). So, I'm not sure what lack of contextual config you're referring to. Perhaps you weren't aware that Commons uses Context.module?

But what about making a group type that has specific blocks exposed to it for placement in Panels?

This is absolutely possible with Panels and made easier for non-technical folks by the Panelizer project.

Modules like OG_Panels also help to make make per-group landing easier for non-technical users.
OG_Panels is being upgraded to Drupal 7 as part of the 2012 Google Summer of Code.

I'm under the impression that Panels works really well for people who want to build a new site with Panels but is it fit for the kind of distribution that is Commons?

Commons is used both by people creating new sites and, as the projects shifts towards a more flexible architecture, folks who are extending new sites.

I agree that one weakness of Panels from the standpoint of building a distribution is #1557842: Allow Feature module exports to add Panes to Existing Panels, but this seems to be far outweighed by the other benefits mentioned in this thread, including Panels' extremely wide adoption.

ezra-g’s picture

ezra-g commented

I setup 2 site environments as described in #7 with identical block content and layouts, one powered by Panels and one by Context module and asked msonnabaum to do some preliminary profilling. With that level of examination, there wasn't enough data to definitively make an assessment in part because there wasn't much if any overhead.

The Spark project has decided to use Panels as the basis for its functionality. In order to align with Spark, along with the other benefits of using Panels described in this thread, I think we should move forward with this proposal pending any new compelling objections in the next few days.

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
commented

Yeah, it's unclear at this point whether Spark is going to do any implementation work the layouts aspects of things or whether we will just copy and paste huge chunks of code from Panopoly, but one thing we've definitely decided on is using Panels for the basis of any layout-related stuff. Because:

a) It maps more closely to the direction D8 is headed.
b) It's the only way to ensure a consistent layout experience between "page-level" and "content-level" layouts.
c) There's a lot of work already done there on useful UX tools, and any remaining rough edges (e.g. the actual page manager tool itself) that get sanded down only help lots of other people + D8 at the same time.

R.J. Steinert’s picture

R.J. Steinert commented

@ezra-g The way I put that was confusing, I was referring specifically to the combination of the Spaces module and Context module for handling contextual block placement as opposed to just using the context module. In particular, I think the Spaces module is a nice way of handling real context. Declare the space instance and now every time you are using variable_get() and variable_set() you are working strictly in that space instance (eg. a specific group which triggers the OG Space type). The reason I say it handles it "beautifully" is because it limits the amount of functions you have to use to set context specific variables. I haven't been following the WSCCI initiative so perhaps this is a moot point because it's solved in D8, in which case we're just talking about what tool we want to use for block placement as opposed to how we want to handle context.

@webchick Those are some compelling points. I get B, that is nice. Is there a thread somewhere that talks about A "It maps more closely to the direction D8 is headed"?

crimsondryad’s picture

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

There hasn't been any additional discussion on this topic for a month and there several compelling reasons to use Panels, including that it's more of the D8 direction. It's what I'd prefer too, so marking RTBC with Panels as the winner.

ezra-g’s picture

ezra-g commented
Status: Reviewed & tested by the community » Fixed

Based on the discussion above, this is fixed.

Status: Fixed » Closed (fixed)

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

juan_g’s picture

juan_g commented

R.J. Steinert wrote:

Spaces and Context handle this beautifully in Open Atrium and I've always opted for OA over Commons because of the lack of contextual config in Commons (unless I'm missing something).

Spaces is not included in Commons (Context is, at least for Drupal 6, as mentioned by ezra-g), using instead OG Features as an alternative to Spaces in the D6 version. They say: "OG Features was developed for Commons with the idea to have per-group functionality without the use of Spaces; and to be done as simply as possible." (#1196422: When to use og_features instead of og_spaces?)

OG Features has just been ported yesterday to D7: #1251630: D7 port of OG_Features

juan_g’s picture

juan_g commented
Issue summary: View changes

Add summary.