Take Total Control of Node Layouts with Panels, Skinr, and Template Files

The Drupal 6 theme layer gives site builders increased control of markup to customize the look and feel of their sites. Previously in Drupal, it was difficult to override system & module markup to get a truly unique design. Thanks to an improved theming system in Drupal 6, themes can now add variables, templates, and functions to completely control markup in the theme layer. Drupal 7 looks like it will offer even more control to themers. In addition, themes get the last crack at markup through overrides to gain complete control of the design. However, greater flexibility comes with a learning curve and requires some coding if done within the template system. The following page is an example of a content type layout that was implemented with Panels 3 instead of the standard PHPTemplate system (.tpl.php files). Sure, This would have just required a node-contenttype.tpl.php file in the theme, but this layout is theme independent, doesn't require server access, and can be easily changed by a client through a U/I once the project is handed off. In addition, it allows complicated theming and customizations for sitebuilders who are comfortable with simple <?php print $foo; ?> statements but not arguments or more complicated variables, arrays, and objects from imagecache and contrib modules.

The Display Suite API and the Node Displays module offer similar functionality to the Panels 3 node variants used in this example and both should be considered during the architecting of your site. Both Panels 3 and Display Suite offer the ability to control content type layout through the U/I. For a comparison of the two methods take a look at http://drupal.org/node/719244. The Display Suite Node Displays module is essentially a drop in replacement for the content type Display Fields settings and is very user friendly. It has commonly used default regions and allows the addition of markup such as heading tags. Panels 3 is more powerful but generally more difficult to learn. For most projects, I use Panels 3 node variants due to it's ability to pass arguments to embedded views and the ease in which Skinr styles can be applied through the U/I.  Panels can also be created for user profiles, node edit forms, and almost any other template controlled layout, including custom landing pages with unique layouts.  Display Suite can affect some of these as well through it's increasing addition of modules that utilize it's API.  Several layouts and styles are prepackaged with Panels 3 and others can be added.  For a great explanation on creating custom Panels styles, take a look at this great tutorial. Custom styles requiring markup can also be added to the theme while CSS attributes can be added through the U/I. In future versions of Skinr that can effect markup, Panels styles won't need to necessarily be added to the theme. 

To get an idea of how node variants work in Panels 3, take a look at the U/I which was enabled via admin/build/pages and accessed via admin/build/pages/edit/node_view.  Here the Element tab is a node template variant that will be used whenever a node of type Element is viewed.  We can create different variants for each content type or apply variants to multiple content types or numerous other conditions such as user role, etc.  A recipe for setting up these variants is available at http://drupal.org/node/661656.  Panels offers many options when editing templates or creating custom pages including context, visibility rules, and layout.  Not to get confused by Panels context settings, Panels also works great with the Context module, which has a different purpose. Here is a look at the backend variant that controls our Element node type layout.

Also to note, Panels 3 allows users to combine both traditional template theming along with it's U/I based system.  For example, if a sitebuilder doesn't want to create a plugin style for markup, template files can still be used for CCK fields, blocks, and views.  It may be easier to make fine grained markup changes this way that an end user won't need to change.  The U/I can then be used to add blocks, tweak the layout, etc through the U/I without direct access to the server, and without the need for any coding.  Below is a look at one of our embedded views that takes the arguments from the panel to ensure the right products are displayed from the nodequeue featured products.  The nodequeue, testimonials is set up the same way.  Panels allows for a multitude of argument options which can get quite robust in application, something that Display Suite is not yet able to do.

The future of Drupal theming and customization seems to be moving this direction with Panels and Display Suite. In my personal tests, neither method adds significant overhead in page load times.  Panels really excels when utilizing per pane caching methods, which is a nice advantage over Display Suite.  These are options to consider when deciding on the needs of your application.  Hopefully, this explanation simplifies what can seem overwhelming at first glance.