5 reasons why not to use panels (and 4 reasons to use them)
Drupal’s block system is far from ideal. It was designed back in the threecolumn-era, was improved to work beyond three-columns-content-in-middle layouts, but is still unsuited for more complex layouts.
If you want real complex layouts, you will have to turn to Panels, or Panels2. Or so they say.
A client of mine, a large Dutch media company uses Drupal for all its new sites -about four, five each month-, and untill today used panels in these sites.
After some discussion, with quite some panels experience, we chose to drop them entirely in future projects; below are the thoughts and reasonings behind this choice.
- Panels take you far away from Drupals core concept of blocks and regions, its page-handling, content-display and even its router system (the menu system).
The way of architecturing your site, using panels, is so fundamentally different from Drupal core, that panels module has to redo almost all the core page-building, core navigation, core argument-handling and core pageflow handling. This can never be a good thing; rebuilding the mayority of core concepts in a single (set of) module(s). I’ll get back on this later. - Panels takes the layouting and design entirey to the interface. In theory, this may be handy for Bob Blogger who wants to play with his design, but has no CSS or HTML knowlede. In practice this is also not the case. Back on this later too.
With panels lying on the interface level, one can hardly program on top of it. Sure, with the proper knowlegde you can develop modules specially for panels, or create panels-specific CSS, but nearly all the work is done in the UI; most of the layout variables live in the database, and, obviously, the code for panels are a huge lot more complex then a simple region with some CSS and a theme override. If you approach Drupal as a CMF, a framework, to develop your site with, you don’t want the core structure of that site to sit in the Database (because that is where a UI stores its settings). You want your structure to live in your code: the place to build your workflows, interrelations between various content-items, and the behaviour of all your content. The samme goes for the layout: panels stores this in the database too, to some extend it still lives in the theme layer, but the mayority of layouting is done in the UI. Storing your layout in the database breaks with all rules of MVC. This can never be a good thing. And it is not. More on that later. - Partly because panels has to re-do a large part of Drupals core behaviour, it is extremely cluttered. Not only the tagsoup is way too complex for the average CCS-ing, the ideas and concepts of “contexts”, “argument-handling”, “panes” and so forth are way too complex and hard to grok. As soon as you get yourself into grey areas in Drupal such as wizards or relations (grey in Core, that is) panels make this even harder, not simpler. Panels tries to do far too much -it has to-, but in doing so, it shoots past its target: making block-handling better and easier.
- Panels often come with the promise that “our editors can then build their own pages, and move around content”. The cannot. Unless they truly understand context, various flavors of arguments, passing around variables, numerous views-settings and so forth. There is really hardly a site I worked with in panels where a block could be move from page A to page C without changing contexts, breaking workflows and often breaking an entire site. And then I am the developer. There is no distinction in interface for me or the editor; they get all the power, responsibility and complexity. Not that Drupal core blocks interfaces are friendly, but at least they have a long history, are well known and a big lot simpler.
- When construction work is done in the interface, this interface must work at all thime. Always. Under any circumstance, including with partly broken elements in your site. Panels works with a nifty javascripted interface, to drag and drop and emulate popups and so forth. This really improves usability quite a lot, in fact! But it makes debugging and developing a site a lot harder, sometimes alsmost impossible. For example a block that -for some reason- has a javascript error (say, it shows a gmap with an invalid API key), panels break completely! The interface breaks so badly that there is really no way to disable the block that breaks it all. You need to poke around in the database, and toggle some values there to get your interface back. Panels may be usefull in a situation where you really don’t develop anything, and all the components you use are known to work flawless and stable, but on a site under-development, it breaks really often and requires quite some work to fix things again.
In short, panels tries to solve three mayour shortcomings in Drupal’s core block handling, but instead of just solving these shortcomings, it comes with such an enormous bunch of extras and doing-things-different, that it shoots past its targets:
- Blocks can go in only one region. A login-block placed on the frontpage in the “branding” region can never be placed anywhere else, even if your followup-pages don’t render that “branding”, or rather show the login-block in the sidebar-region.
- Blocks have only one place (a weight) in that one region, no matter what page you are on. You cannot give blocks on other pages another order.
- You can switch blocks on and off with various systems, such as path-patterns, or simple permission toggles like ‘show only to admins’. You can even provide PHP code to toggle a block. But this is either too hard to maintain (imagine maintaining that huge list of paths where a block should show up on a site that changes its navigation every month). It is too complex to grok (you can really not tell that editor to change the regular expression in your PHP-code everytime she adds a new section to a site) or it is too simple (show only to users in role ‘editor’, who have not yet visited page X).
- All regions are loaded entirely, whether or not a page needs them or not. Say your frontpage has 12 regions and all other pages at most 4. then for each and every page the 12 are loaded and processed. Drupal finds out that in 8 of them there is nothing to show (blocks toggle to OFF for all the page but the frontpage) and hence don’t show up. But the processing time and overhead is completely wasted. There is no way to toggle on or off an entire region.
My point is, that to solve above issues, you can, most of the time, choose far simpler and more effective measures then panels. I won’t go into them all too deep, but I have solved each and every. And now, my client gets a few new modules to solve most of them for once and for all. Those are simple modules, without interfaces, javascript or layouts-in-databases.
We build our layouts with CSS. Our workflows, relations and information-structures using code. And leave the finetuning for the default core interfaces. And maybe in future a module to allow editors to move around blocks and nothing more. On top of regions and blocks.
That way we leave the V of the MVC where it belongs: in the Theme layer, and the C in Drupals modules. And with that, have managable, simple to understand CSS, theme overrides and code. And we flatten our learning curve again, which may sound strange: since Panels looks like it makes layouting a lot easier.
There is some much
There is some much misinformation in this post it is pointless to even refute it. I’ll just urge future visitors to this page to be skeptical about the declarations made here.
If there are so many can you
If there are so many can you at least point out the most important misinformation?
I mean, sdboyer did a very good job, pointing out his vision and where he thinks I am wrong. I did my best to come up with some conceptual ideas and thoughts and thoughts behind them.
Without saying what is wrong, future visitors best turn to sourcs that actually come up with reasoning and that give some background.
I would be more then happy to learn yours.
If all you’re trying to
If all you’re trying to accomplish are the four items you’ve listed. Then custom PHP/Panels Lite might serve your purpose.
Panels2 offers the same pros (hugely powerful and flexible) and cons (steep grok curve) as Drupal itself. It certainly belongs in any Drupallers arsenal, and not just relagated to Joe Bloggs’ Drupal projects. The way it will be applied and implemented is sure to surprise us all.
I should start by saying
I should start by saying that there are some useful points here. There are.
Most of this post, however, is just patently untrue. I find it difficult to believe that there’s “quite some panels experience” contributing to this analysis. Perhaps that experience is with working via the UI - and given your emphasis throughout that Panels does most everything through the UI, I think there’s a good chance of a correlation - but this really is a pretty gross misrepresentation.
As an initial note - there’s nothing I can do to address statements like “…is so fundamentally different from Drupal core…” as we just get off into subjectivity there. I’ll try to stick with just the facts. Also, it’s important to note that many of these criticisms seem to be directed towards Panels Pages - which is not Panels. Panels itself is an engine that provides a lot of component pieces and an enormous API.
Point 1
It’s hard to respond to any of the points here, as they’re really of a more subjective judgment-based nature. However, you do list several items that Panels ‘redoes:’ page building, argument handling, navigation, pageflow.
Page building: This is the one point I agree on. Panels assembles content together and prepares it for the presentation layer on the fly - which does not necessarily mean from the db - in a way that no existing framework within drupal does. And that’s a legitimate need - pretty much any complex site is going to need to pull in individual pieces of data from different locations. When you don’t do it with Panels, you do it right in there in your own code (maybe in the theme, maybe in a custom module) - which has its pros and cons, similar to the ones discussed http://drupal.org/node/242311 about Views.
Argument handling: This is wrong. In fact, I’ve just (nearly) finished the D6 port of the panels page menu system, which is the subsystem that enables path overrides (things like node/%); with the way the new menu system works, it’s now quite easy to see. If we did ‘redo’ core argument handling, then the first thing that would mean is taking over the loader functions corresponding to those arguments - aka, taking the path node/%node_load and overriding it with a panels loader. In fact, I initially assumed it was necessary, but was very pleased to discover it wasn’t necessary at all. Panels does not replace a SINGLE loader function - which means that it’s always the same core (or other contrib) mechanism fetching data at any given URL. Panels simply puts a small wrapper around that data for its own internal use - effectively nothing more than the sort of structured array you’d have to use if you were hand-coding a module that pulled together content from various directions.
Navigation: I don’t even understand what this would be in reference to. Panels have to touch the navigational system at all. It CAN, but it doesn’t have to.
Pageflow: I don’t understand what this is in reference to…I’m conceptually lumping it with page building, which I assume is different.
Point 2
Panels does take layouting and design entirely to the interface. In fact, there’s a legitimate line of thinking that says it doesn’t take design to the interface at all, and takes layout to the interface only at the most meta of levels. Earl has already addressed this to an extent, and there are other more important inaccuracies to address here, so I’ll reduce this point to the following: there is not a single line of render-time html that the Panels engine itself insists upon. The construction of your layout - including the css ‘tagsoup’ - is done by layout and style plugins. The former govern the overall arrangement of areas on the page, and the latter govern what html, if any, should wrap each individual item on the page. When you’re using the DND interface, you’re really just arranging items within an html output framework that you have complete control over.
Earl already mentioned it, but it’s worth mentioning again. It is inaccurate to say that “most of the layout variables live in the database.” That’s only true if you’re using a ‘Flexible’ layout - which as Earl said, is not something either of us recommend for serious production servers for a number of reasons. It’s just a handy tool.
Along those lines: “obviously, the code for panels are a huge lot more complex then a simple region with some CSS and a theme override.” Really? I don’t think that’s obvious. In fact, I think it’s obvious that this is not the case. Two quick examples of what raw, unadorned output look like in two plugins that ship with Panels:
Onecol layout plugin’s tpl.php (fresh from HEAD): http://drupalbin.com/2893 (since code tags aren’t enabled)
And sure, you could cut that down to a single div if you wanted to. And/or strip out as many of the css tags as you want. We can’t in the packaged distribution because we have to maintain clear inheritance in the event that mini-panels get used. Either way, though, this hardly constitutes “a huge lot more complex.” And the corresponding CSS file contradicts your claim, too:
Onecal layout plugin’s css file: http://drupalbin.com/2895
And, the pane style for blocks: http://drupalbin.com/2894
Please, point me to the code bloat. Also, to address a point you make later - note the call to theme(). Panels doesn’t circumvent the theme system at all - it just calls it at times and in ways that people aren’t as familiar with. The fact is that if you’ve done your site with panels properly, then the only thing that’s stored in the database is the name of a layout. That’s it. Go ahead, look at the contents of your panels_display table in the ‘layout’ column. ‘Layout settings’ are optional, additional items that the plugin creator can add, specific to that layout, which are configurable via the UI. But you’re not obligated to do it.
There’s a larger conceptual point here, too, about structure living in code. As I said, I’ll not debate the merits of one approach over another - I’ll simply say that I think of the panels engine as an abstracted version of precisely that sort of logic that should live in code, and it’s a logic that is comfortable with the ‘Drupal’ way. If there’s a problem with that, then the concepts in http://www.palantir.net/blog/sustainable-markup-how-be-a-themer-drupal apply pretty well.
Most of the really substantial configuration options, though, come down to flipping switches here and there. If the desire suddenly came over me to make Panels completely unintelligible, I could rewrite the whole thing and express most of its major configuration options using a few bitmasks. When it’s possible to do that, it means that your logic does live in code. And of course, keep in mind that pretty much everything that would constitute those bitmasks is data that can be set in code by modules implementing the Panels API - they need not be set via any UI.
Point 3
Another pretty general, subjective statement. The part of it that hints at Panels being a difficult-to-grok module I empathize with, very much - I’ll explain more in #4. But ‘extremely cluttered’ just isn’t very specific, or helpful. I’ve already addressed the theming/CSS issues; as for the guts, there absolutely are aspects of the engine that aren’t nearly as elegant and clear as we’d like them to be. That’s part of why there’ll be a Panels3. The other part of why there’ll be a Panels3 addresses the third possible interpretation of this statement: the UI is complex. Quite complex. And again, with that, I’m on the same page - which is why a lot of Panels3 is going to be about reworking the interface into a more helpful & informative feedback-providing thing. Panels3 will also be about granularizing panels, which leads to your next point.
Point 4
‘Panels often come with the promise that “our editors can then build their own pages, and move around content”.’
Who is promising that? Show me where it is in our documentation, and I’ll take it out right now. Until you do, though, it’s really just slanderous. By making that statement without ascribing it to an explicit source, you imply that the developers are making that claim - and we’re not. We’re quite aware that the Panels interface is not a tool easily used by most users - as the UI exists right now, it’s really a tool for site admins to lay out their sites. To my knowledge, I have never claimed anything like what you say verbally or in writing about the current version of Panels. That, again, is why the granularization in Panels3 is so crucial.
As for the remainder of this point, I think I’m mostly in agreement - to really be able to fully utilize the flexibility inherent in Panels, you need to understand its context subsystem. It’s not true that your editors have to, or even that your editors have to use the Panels interface in order for their entered data to be used in Panels. But it does seem like the root of the problem here is that you don’t really understand how those subsystems work either - and I’m happy to see that as, at least in part, our responsibility, because context is abstract and difficult to grok.
Please also keep in mind that this is coming from someone who first clicked a Panels interface six months ago. I mention that because I’ve gone through pretty much every imaginable learning curve that Panels has to offer, so I know firsthand how hard they are. They suck. I wish they didn’t suck so much. And I do what I can about it as time allows.
Point 5
Try updating to the most recent version of Panels. Or really, just a recent version, as this has been fixed for months. If such breaks occur now, it’s because the author of the plugin wrote it incorrectly. Anyone who’s ever written custom php code into a block knows quite well how much of a pain it can be to fix a block where you’ve got a typo in your php. My own favorite trick for that is using a blank node submission and Previewing the result - if I get a WSOD, no harm no foul, b/c it was just a preview. But there’s no need for that in Panels, now, because unless a content type plugin specifically overrides it, then the render callback (which is the equivalent of the php entry area for blocks) is not fired on the edit screen. But the real question here is - how would broken plugins be Panels’ fault any more than badly written contrib modules are core’s fault?
=======
“In short, panels tries to solve three mayour shortcomings in Drupal’s core block handling, but instead of just solving these shortcomings, it comes with such an enormous bunch of extras and doing-things-different, that it shoots past its targets…”
Nowhere do we state that Panels’ sole purpose is to replace the block system. I’m sorry you got that impression, but you got it on your own. Panels is better thought of a ‘Content Marshaling System’; it retrieves and organizes disparate data in a structured, predictable way, and strives to do so in as pluggable and efficient a way as possible. IMO, such “marshaling” is the flipside of “management”, which is why I don’t mind it when people call Panels a CMS inside a CMS - it marshals the content that’s managed by Drupal, getting exactly what you want, none of what you don’t, and all the while working with the existing flows that drupal defines - not reinventing them.
Sorry, there’s a rather
Sorry, there’s a rather important typo in there, right at the start of Point 2:
Panels does take layouting and design entirely to the interface.
Should be:
Panels doesn’t take layouting and design entirely to the interface.
I have only minimal
I have only minimal knowledge of Panels at the moment, but I agree it is big. My usual solution when I need only a small slice of its functionality is the component module. It’s a quick and simple “pull-based” module to pull content (views, blocks, etc.) into a variable in a template. Position and go. (It’s very useful when combined with emulated preprocess functions.)
That said, you could make all the same arguments about custom code vs. Views. I’ll still pick Views over custom code 99% of the time because when used properly (and only slightly abused, like with component module) it saves me easily 75 hours per project minimum, and if you’re smart about it then it’s no slower than custom code would be.
It’s all a matter of knowing how to use your tools properly.
I don’t have the time or
I don’t have the time or interest to address all of this post entirely. There are a couple of good points in there, and a couple of flat out wrong points in there.
Panels was designed to let you write layouts in code. Just because the ‘flexible’ layout lets you do it in the UI does not mean that it has to be in the UI, it just makes it easy to do it in the UI. If you think it has to be in the UI, it’s because you’re not writing your own layouts. Writing layouts in panels is really, really easy.
Properly used in a production site, you also export all of your panels into a module using the panels export module, and do not actually keep your panels in the database at all. Just like with Views.
To be honest, Panels isn’t anywhere close to where I envisioned it, yet. There’s a lot of things it can do that require a lot more work, a lot more UI work to increase the usability, a lot more in the way of tailored applications. I let Panels Pages get too powerful, and in so doing it made itself a massive UI clutter. But there’s a lot of good lessons that are being learned with Panels, and I honestly feel that the core ideal of Panels is the way to go, and Drupal’s block/region system is fundamentally flawed.
"Panels was designed to let
But that is not how one uses it: you may make a layout, basic HTML, in code, but from there on it is only UI work. Sure, one should spend more time in that HTML (and CSS) part, but the nature of panels is to do all this in the UI. Hell, panels even allows you to type widths and columnsizes in your UI!
So: I assume the fundamental approavh was very right: the way it is used -in the frondend- is IMO wrong. And I cannot see a way to get around that.
Sorry, I do know my CSS, but those panels layouts are by far not as easy as taming a few divs with the content you know will be in it. Your panels layouts, if you do it well, need to cover all kinds of flexible dynamic possibilities: empty panes, large content, small content, images, and what more. It is not so much the technology behind it, it is the way one has to approach such a design. If i design my regions, I keep my HTML simple and highly focused on that very problem I want to solve: nothing more nothing less. That is what makes it easy.
While this is a nice feature to be able to put your stuff in SVN or so, this is not what I meant with "developing in a database" or "developing in code". Again: adjusting your highly focused CSS to e.g. make a column wrap better, is a completely different type of action then dragging+dropping panes around. So it is not so much the ability to have someting in SVN, it is the "way of development" that is different. I mean, in theory I can put chunks of databasedumps in my SVN too, and say: see, I've got it all in code.
This, however is a more fundamental problem with Drupal as a whole. Drupal stores configuration right inbetween its content, making proper release-management and staging a drama. The only way I see this being "fixed" in Drupal is by saying "No: Drupal is not a klicketyclick CMS, it requires you to write (simple) code; it is a CMF". This problem, by the way, is also seen in e.g. Typo3, which has alsmost only views/panels/cck alike building and hardly anything else. I really don't like typo, for that very reason.
Let me point out, that I do think panels has a fabulous concept and some brilliant ideas.
I am sure that it serves the exact need of many Drupaleers out there. And that it does that in a really nice way.
What I described, is a choice we made. We, being a team of four parttime Drupal devs running a team of over 12 fulltime 3rd party Drupal developers. So that is probably an entirely different "world" then where many of the Drupal users are buidling their sites in. We use Drupal entirely as a CMF (e.g. there are hardly any contrib modules that we haven't tweaked, in our SVN).
We all agree in this. But my approach is to name the flaws (see my post) and to solve them.
And I really don't see "not being able to change your layout from within Drupal" as a flaw. Which is what the largest part of panels'(code) does. Maybe this is due to what you describe as "letting it get too powerfull", or as I call it, feature creep, but that is the part that is most in our way.
Solving the fundamental flaws in Drupal's blocks need only three small modules (right now) and solving them, while providing better features (codewise) requires those three modules, but not that small anymore.
I am sure that it serves the
I am sure that it serves the exact need of many Drupaleers out there. And that it does that in a really nice way. What I described, is a choice we made.
But that’s not what the title and introductory paragraph of your post said. I would be much more comfortable with this post if it were couched in that manner, but this post is presented as advice.
I deliberately titled it
I deliberately titled it “5 reasons why not to use panels (and 4 reasons to use them)”. And I deliberately built up the article, so it lists the cons of Drupals core system last, and to point out that Panels solves that after pointing out what is wrong. Or: I keep the best for last.
I deliberately mentioned the kind of development we do. I deliberatly pointed out that this all is only a point if you look at Drupal from a CMF point of view; which we do.
That leaves more then enough space where Panels makes an excelent choice. I will think of some editing to the toneand details of the post, to point that out even more clear.
Interesting post! As I’ve
Interesting post!
As I’ve never used Panels I can’t say anything remotely useful about that. What I do agree on is that the handling of Blocks can be improved. And from my limited experience in programming I’d say this can be done quite well, possibly we can have combinations of Taxonomy and Block logic so that we can say: on Taxonomy term X always present Block Y in region Z with weight n. Or something.
I was thinking the same
I was thinking the same about views. Sometimes I install it just to throw out a couple of simple views listing CCK nodes of the same type. Something that should be easy to do with the menu system saving on memory and loading times. I’d like to see a simpler query builder on core someday…
I call this module my
I call this module my sitename_miniviews.module. and almost all my smaller projects have such a module. Just a module with a menu callback and the queries.
But the hardest part is when the data that you show changes.
“Oh, we looked at it and think that actually printing the name of the author next to the date, is indeed a better idea”. You know that. In views that means getting into your interface and adding a field.With my modules, I often have to spend many times that effort with debugging stupid carthesian products because of another broken JOIN. :)
But yea: in general I am not a fan of all this complex in-site configuration and development: I prefer my far-more-powerfull few lines of PHP.
Have you contributed any /
Have you contributed any / are any public of the modules that overcome the shortcomings with blocks? (Thank you for explaining those sources of frustration so clearly and succinctly!)
The code and modules are not
The code and modules are not mine. But we are trying to establish some ways to contribute our work.
But first and for all we need to test and implement this IRL.
I mean, Panels promised us all that we thought we needed. Only after a few sites and several releases and failed-bugfixes (because of the overly complicated structures) of those sites, did we realise that we had to re-evaluate the choice. Wich leads to the post above.
I don want to make that mistake by presenting some Holy Grail if it hasn’t been put to real use yet.
But as said, even then I am not hte one who decides to release (and maintain!!) such code.
Interesting point of
Interesting point of view.
Personally, I have not got into panels deeply enough to say anything about it. But having had contact with someone who created a problem by using panels that could have been solved without, I agree.
As Panels2 is a very powerful tool, it is still to be checked out what it offers. But one thing is very true: One should only use it, if you cannot do it in a simpler way. It must offer more flexibility than blocks, save time and have good performance, then it wins.
Personally I did not use it yet because I always created regions and put blocks in there, and having fought a bit through Block visibility and being proficient in CSS with lots of usage of CCK and custom content types, I was able to solve about every problem up to now.
Would be interesting what Merlin thinks of the points you make.
Yeah I am avoiding panels,
Yeah I am avoiding panels, too, although I am still relatively new at drupal. I found using/making a theme with many customizable regions + blocks was much preferable to using panels. See for example the roopletheme themes. Unfortunately most of the available themes including the zen template only have a few regions. Drupal should have a default theme that has 12 or so regions and can be easily customized (background images, colors, etc.). Otherwise you end up with 90% of drupal sites all looking pretty much the same.
The only downside is that the blocks administration page gets unwieldy after a while. It would be nice if that page showed a preview or image of the block if possible, making unnecessary to memorize dozens of different block names and what they do.
For the same reason, I have
For the same reason, I have not used panels yet.
The problem with panels that there is an audience target mismatch. Programmers can do without it and for non programmers it is way to complicated.
But, I must say that it is a great piece of work by Merlin!
The only downside is that
This is really a shortcoming in Drupals block system, your solution, of using dozebns of regions is IMO the besst one at the moment.
great post, thanks…! you
great post, thanks…!
you are correct with everything you say here-
what a great source of info.
question…
re: 4. All regions are loaded entirely…
wondering is there an easy way to fix this in drupal 5.x or 6.x-
and to only load the regions that are going to be displayed?
thanks-
vincent, in buffalo
http://basicmagic.net
IT probably is, but it is
IT probably is, but it is not easy. This is because right now Drupals theme system, and especially the region part is entirely pull: the regions pull in the blocks. So untill you load a region and have it pull in blocks, you don;t know if you are going to need it.
“the only one that knows if a region is needed is the region itself”
Good post! Makes me really
Good post! Makes me really think even harder about a possibly more suitable solution for blocks/regions in Drupal. My current solution uses a lot of Drupal’s default functionality for rendering block contents in certain regions and passing contextual information as requested but keep running into unwanted and unnecessary overhead caused by Drupal’s core block system.
Bèr, what you pointed out: “the only one that knows if a region is needed is the region itself” should be taken a little (template) step higher: “the only one that knows if a region is needed is the page template”.
Post new comment