In an Open Source Content Management System like Drupal, the wide range of contributed modules often leads to multiple solutions and approaches being available to build a feature for a site. With this flexibility, rarely is there a single "best" solution to a given problem. In this series, the Mediacurrent team will cover some of the common features that our clients often request, and what tools we like to select for the job.
With a panel available to debate, what better place to start our series than with Panels? This contributed module allows for flexible layout and control of content on a Drupal site. But not everyone is a fan. The Mediacurrent team reflects this, with several strong opinions both for and against the use of this module. Mediacurrent debates:
1. What are some examples of when you would choose to use Panels?
Jay Callicott: I really like using the page manager's "node template" panel as an alternative to node.tpl because you can alter the output to pull in field values, embed views, etc from the UI. With selection rules you can make a node template variant apply to multiple node types, which I have used on multiple sites. Also these node template variants are exportable to Features. Embedding views, adding custom code, etc can be done within the .tpl for that node type, but embedding views and sharing layouts is not as elegant. It can get messy. With context you don't really have a way to "overtake" the node layout to my knowledge. Display Suite is the other major alternative to the "node template" panel but I like the Panels version better. Also, now with the in-place editor it you can drag and drop elements on the page.
Although Context is often an alternative to Panels, I like to use them together. That is because Context deals with regions, whereas Panels just hijacks the content area. Context is great for block placement and setting theme variables. Context or panels could be used for a distinct, dynamic page -- like a list page or "section" page. With Context you can't override arguments you are passing to a view, but you can work around some of these limitations.
The downside of using Context & Panels is that you have two UI's to deal with, and if you have to train a client to use both it can be confusing. Both have some handy drag and drop ability. For instance with Context you have the "inline context editor" which lets you drag and drop blocks into regions. Panels also has an inline edit tool.
I could get by with a Context-only approach particularly if I have a flexible theme like Fusion that lets me create on-the-fly layouts more easily. It would be much more difficult to find a suitable replacement for layout on node pages. I think node.tpl just won't cut it for me.
Now, what is often mentioned in this debate is that Panels has performance issues. I think this is a red herring, all modules add some overhead. I haven't noticed any kind of signifcant issue with Panels performance any more than I have with Views or Context. Panels has been around a while so maybe this issue came around early on, but I just haven't seen it in my experience. I am usually caching the full page anyways, so that hasn't been an issue for me.
In conclusion, I wish there was just maybe one layout tool for consistency. In the meantime, I still really like Context for what I use it for and Panels for distinct layouts.
Brent Ratliff: I agree 100 percent. That's my favorite use case. You can also cache per pane in those variants and still use field tpl's or Display Suite build modes in the Panels.
I still use Context to set the block settings in the rails, footers, etc. Panels lets you use the regions or not per Page.
2. When is Panels not recommended as a good solution?
Brent Ratliff: When you like to waste time.
Seriously though, I'll think about it. A lot of the reasons I used to think were performance related and have pretty much been disproven.
Jay Callicott: The big drawback for me again is that you have 2 distinct UI's mixed together, so that would be a reason you wouldn't use Panels. If you can do what you want with node detail pages via just CSS, then maybe you could get by with just context. If you have a 960.gs theme you can create layouts on-the-fly without necessarily needing Panels' layout builder. But for me, I end up using context and panels on every site I build. And even though I don't like having 2 in-place UI's, editors aren't usually using those tools anyways, so for me as the developer, I like the inline context editor and the in-place editor Panels has for moving blocks around. For people who don't like the Panels interface, you should really try out the in-place editor. It is very slick.
It's hard to argue that Panels is too confusing for the end client because a) Context isn't super easy either b) For node templates, Panels is still preferrable to .tpl editing which definitely requires a developer/themer c) The in-place editor can be enabled for editors that can handle a more involved UI and d) Even if you hide it from the site admin/editor, it is still a very handy tool for developers/themers. Clients often want something moved up or down on the page. Smaller adjustments like this are trivial in a Panels interface.
Andrew Thornton: I suppose the reason I am not a fan of Panels is that you can achieve the same results with less workload on the server in terms of a CSS solution and reduced number of database queries to render the page.
If we are looking at very large scale deployments, I would want to shave off as much overhead on every page load as possible. Even reducing it by 1 database query per page would have a significant impact over thousands of pages delivered.
After saying that, I don't have any hard data to back it up, but it would make for an interesting benchmark test over a large volume of traffic.
Chris Hales: I think it's easy to say Panels is confusing. We have had several panic attacks from clients over Panels issues because of misconfigured settings.
My main issue with Panels is how it's often used in areas where it just isn't appropriate. "Appropriate" is of course subjective. The only times that I would use Panels for a project is if it would save significant time with the specific use case and almost always that use case would be related to the client needing the ability to change the layout or positioning of page elements. Even then, the client really needs someone on staff that is knowledgeable in Drupal administration to manage modules with such massive and sprawling UI's.
In many of the projects I've worked on, Panels has been used as an easy/quick solution to a problem or use case that could be solved with minimum effort from a coding perspective.
Example: Panels was installed by another agency on a site we now support for a single simplistic page that could have been a block or some basic custom code.
Like Andy was getting at, there is also the issue of code bloat. On a site that is all anonymous traffic where everything can be cached, it could be said that using Panels doesn't matter so much, but most of the time that isn't the case. When you are dealing with high/mixed traffic sites where every query hit counts, the memory footprint must be taken into consideration.
Brent Ratliff: The benchmarks that were perfomed by sdboyer show that the impact is insignificant when compared to PHPTemplate techniques. The key is to export as much as possible to code and turn off the UI. The ability to cache certain page elements and leave others dynamic increases performance for logged-in users. In addition, some shops are reporting performance increases by using Panels Everywhere and skipping the theme entirely. I think you will see this in Drupal 8 core. It is a myth that Panels is a huge performance behemoth. It's only a wrapper around Ctools, which is enabled on every site anyway for Views. What Jay is talking about -- using Page Manager for all node templates -- there are no performance hits that I know of if reading from code.
3. Caching and exporting to code are cited above as answers to the performance questions. Can anyone cite from any direct comparisons that have been made to speak to the "code bloat" questions?
Andrew Thornton: I don't think panels are exceptionally bloated in terms of performance, I see them as an additional query on page load that can be removed if done through CSS. I am not even talking about using PHP templates to produce the same effect. Old Fashioned Markup and CSS to produce the layout.
If it was a small site and the user needed the ability to create these kind of layouts, then I would recomend Panels. If the site was large with regular traffic spikes, I would never recommend it. Each query saved makes a difference under heavy workloads. When you look at sites with insane traffic, such as ebay, amazon, twitter ... they all take the approach of using any technique to reduce workload over very high volumes. If you could reduce the page load by even one query, that's a gain.
I do get a little tired of people complaining of speed on Drupal sites on under a heavy workload where they throw tons of money at the hosting environment to speed the site up, and then load the site down with hundreds of modules, many of which can be done natively and save on resources on the server.
This might be a good item for benchmarking, Chris and I have been working on benchmark scenarios and testing. Might be worth comparing different options and put them through their paces and get some measurable stats for each scenario.
Brent Ratliff: Yeah, I think we need to benchmark ourselves instead of going on hearsay.
Chris Hales: I was thinking the same thing but we need a candidate site or would have to build test site to try it out.
4. OK, if any of the participants want to do some followup benchmark testing, we can report results in a future post. Meanwhile, I am curious if the members of our Design and Theming team have any input on Panels?
David Bassendine: I was initially skeptical of adding another complex UI, but now I think that Panels continues the great Drupal tradition of putting more control in the hands of site builders (and potentially, but not necessarily, clients), whilst freeing up developers to work on more complex tasks.
The most compelling use case, as Jay has said, is to do away with the laborious task of writing markup and complex conditional logic for templates, and pull this out into a more accessible UI. A beneficial side-effect of this is layout markup is handled directly by Drupal and is better standardised across builds. Templating can still be done, but at a more granular (ie. field-based) level, which targets developer effort to where it is really needed. Whilst there may be more code overall, the amount and duplication of custom code (templates, preprocess logic) is cut considerably. In the long run, this makes sites easier to maintain for developers and less costly for clients.
Using Panels also allows for a more agile development process. Once in place, we can move things around and mash up content in ways that aren't dependent on or blocked by the traditional development cycle (discovery-design-build etc.). I think this change in thinking (whilst not always desirable) is still filtering through. We're still in the midst of figuring out how this changes the way the web is built. But in the end, I think it's a positive trend to see more control over the content on the web put in the hands of its users, and Panels is a step along that path. Training and more intuitive UIs (e.g. in-place editing) will help to speed up the process.
Of course, Panels is a layer on top of the core content display layer (or potentially Display Suite), and no it won't always be an appropriate or necessary addition. But, for those cases which leave you reaching for a .tpl.php, I would use Panels instead and give your site's users the gift of flexibility and maintainability in the long run. In those cases, the performance hit (assuming it's moderate) is worth it.
Most of the points here have already been put above in different ways, but I just thought I'd chip in my two cents. Hope it's useful, and I think this is a great format -- look forward to seeing the end result.
Andrew Riley: My counter argument (this is ignoring the obvious benefits of being able to do it all in Drupal without code) is more complexity. This adds another layer on an already complex system. Need to find out how a page was assembled? Was it in as part of the node.tpl.php or the page.tpl.php or the node-nodetype.tpl.php, a theme hook_preprocess a module hook pre_process, did context or blocks arrange it there or was it done in Panels? The Drupal theming system was already complex, Panels adds on another layer to the complexity. Even now as a person who has been using Drupal for years, when I approach a new site it takes me a little while to figure out the how and (hopefully) why things were done. Having 84 different ways to do things isn't always a good thing.
Kendall Totten: I think that Panels can be a timesaver and are easy from a design perspective. You can quickly create the layout you want, throw in custom css classes throughout, and easily pick up nodes, views, and blocks. This would definitley take me a lot longer from the backend if I had to do it all by hand.
I'll also say that it makes it easier to reuse node content, but that can be good and bad. If a client goes in to edit one node, they may forget this node is being used in four other panels. But it does allow them to make changes.
Panels also allows you to save and reuse template layouts which can be a timesaver. However, I also think this is a good time to point out that the Delta module can allow you to reuse template layouts, but it's more for the site regions than inside the node. This would not be something clients would use, but more so for themers. Big timesaver, but I have no idea how it affects performance.
Delta Module = Creates a front-end UI for custom PAGE templates
Panels Module = Creates a front-end UI for custom NODE templates
Jay Callicott: My counter counter argument: On sites where I use Panels node templates, I use all Panels, no node specific tpls. So it is clear since you have the "Panel" tab and no node tpl's at all in the theme layer that Panels is handling output for those sites. I agree that you want consistency, I would say either use Panels for node template or use all .tpl's. I personally like to have as few .tpl's and template.php code as possible in my theme layer. On sites where I have had control over the theme from the start, we have a very light theme layer with no view- or node- tpls, which I tend to like because otherwise themes can be difficult to manage.
Kendall Totten: I agree with "the fewer template files, the better."
Andrew Riley: I agree, either go all Panels or none with a site. I'm really not a big fan of sites that use Panels for one node type or page.