Comparison of Layout editors

You are viewing a wiki page. You are welcome to join the group and then edit it. Be bold!

Posted by catch on October 14, 2008 at 3:39pm
Last updated by ezra-g on Wed, 2012-05-02 14:13

Drupal sites and distributions have various needs for block placement and layout solutions. This wiki page aims to capture key needs and how each of the leading solutions addresses them. While the focus is on Drupal 7 versions, some observations may apply to Drupal 6 as well.

Aims:

Enable site designers and Drupal distribution authors to understand the relative merits of different solutions and so make informed choices.
Promote development of standards e.g. Kit so that components built for different distributions achieve at least minimal interoperability.

The main solutions noted are not necessarily mutually exclusive--a given site or distribution may have good reasons for combining two or more solutions.

Need/functionality	Context	Display Suite	Panels
Exportable: settings can be individually exported, imported, overridden, and reverted through the UI.	Exportable via Ctools	Exportable via Entity API (?).	Exportable via Ctools
Features support: can be added to features	Features support via Ctools	Features support via Entity API (?)	Features support via Ctools
Lay out entity bundles (e.g., node types) in multiple view modes.	Can be used to enhance layouts for existing view modes.	View modes is the organizing principle of Display suite.	Can be used to enhance layouts for existing view modes.
Intuitive UI for layout	Context editor (bundled with Context module) provides drag and drop in place editor.	(?)	Highly refined in place editor.
Enable multiple layouts:	By default is limited to a theme's defined regions. Can be enhanced with additional layouts defined at the theme level, either as theme-provided layouts available to the Context layouts module (a sub-module that ships with Context) or through the use of configurable theme settings via the Delta module as implemented in the Omega base theme. There is also a proof of concept module, Context panels layouts, that aims to provide context layouts at the module rather than theme level.	Provides multiple layouts. Also supports Panels-style layouts.	Provides multiple layouts.
Enable custom, user-defined pages	Context can be used with Context node to produce custom pages.	?	As well as overriding existing pages, e.g., entity pages like full node displays, Panels can be used to create custom pages.
Allow different Features to each specify elements (blocks, etc.) to be displayed in a particular layout such that, e.g., home page content is the sum of blocks supplied by several optional modules.	The ability to produce composite layouts from multiple sources is a key feature of Context.	Since field display information is stored with field definitions in Features,	Panels displays tend to be monolithic--they are created and exported as a whole. The ability for a given feature to conditionally enhance another feature's panels page would typically rely on using a `hook_alter()` implementation or a solution like Features override, which allows exporting of component overrides to a new feature. However, a given feature could provide mini-panels that could be placed via e.g. context. Exists as a feature request to Panels.
Pass contextual data to blocks: e.g., pass a custom argument to a block view display.	Contextual data can be passed to blocks via use of the Views boxes module.	Views content panes can be displayed in display suite view modes. TBD: can contextual data be passed?	Panels pages include a context that is configurably passed to views content panes.
Support for adding multiple types of data to layouts, e.g., node fields.	No - Blocks only.	Supports display of CTools content types (fields, blocks, etc.).	Supports display of CTools content types (fields, blocks, etc.).
Support for adding custom elements to layouts.	Custom data can be displayed via use of the Boxes module (or one of several similar solutions for code-based blocks).	Supports custom fields that can be added to and configured for the layouts of specific entity bundle view modes.	Supports custom panes.
Provide default layout and content on a per entity (eg node-type, user) basis.	No.	No.	Yes, via the Panelizer module.
Ability to lock content in a particular part of the layout (eg, so that more permissioned users can place an ad block and not have it removed by content editors).	No.	No.	Yes, via a permission to edit locked panes.

Comments

I like the composite module

Posted by pkej on January 30, 2009 at 3:45am

My comments to the list:

Panels is more powerful and flexible in one way, but see number 4 and 5.
Composite layout is simpler, in a user friendly way. What is a context in Panels? Why can I add stuff into a panel which doesn't show up or is meaningless in a node context?
I prefer composite layout for quick work
Not quite the same as panels. Panels lets you create, for want of a better word, a template for a content type layout. Composite lets you change the layout of each indivdual node of the content type. Much more flexible on that level. I might be mistaken, but since panels isn't production ready, I haven't played with it since november, and I'm referring to the most modern one, the Panels 2 version.
Yes, and no, again composite allows you to move the fields in each individual node, not just for a content type.

My list of pros:

It is production ready for 6.x
It is quite simple
I can create a page, and then later convert it to composite if I need more stuff in it.
It is very, very easy to select blocks for inclusion on the composite page.
It works flawlessly with i18n; I haven't tried out panels in such a setting. The front page of http://beta.samipath.com use one node which is a composite layout. It has two views embedded as blocks. If you change the language the content will change. There is no content for the finnish front page, but that is due to some features missing from i18n 6.x-1.0 which seems to miss a patch which was marked as fixed earlier (i18n content negotation handler for views).

There are stuff which Panels is much better at, changing the layout of all nodes in a content type, just to mention one.

I would love a handler for views which allowed to create zones like in panels/composite, instead of just the table/node/etc versions.

My experience has been different

Posted by sk_mamp_nb on March 9, 2009 at 1:40am

In some cases Composite is good and in some case Panels is good. I don't quite agree with pkej on:

Not quite the same as panels. Panels lets you create, for want of a better word, a template for a content type layout. Composite lets you change the layout of each indivdual node of the content type.

Well the Pages option on Panels (3) is incredibly more powerful and well structured. It gives the option to create new task handlers for Node edit/ view etc. whereby one could easily change the layout of the node for a specific content type. Wow! It is something. Again the contexts in Panels are very helpful in providing the conditions under which a page/block would get values. Very good indeed.

So I would say, Panels can do everything that Composite does and more. But certainly the UI of Composite is easier at least initially.

Looks like one major difference right now...

Posted by sethcohn on May 21, 2009 at 2:52pm

Panels allows new layouts per content type, Composite allows new layouts per node within that content type (a default can set, but individual nodes can be layouted differently if desired)

I don't think Panels currently allows this, if it does, I can't figure out how to do that. On a page panel, yes, but not on the node itself.

If you want to have a single content type (say blog), but allow different posts to have a choice of layout, Composite looks like the way to go... for now.