19

I'm trying to figure out what the best practices are for page layouts in Drupal. Many pages have several different elements on them like main content, a header image, etc. I'm not looking at creating a 'basic page' or anything similar (ie one node for the whole page).

Is it good to use panels for every page and them drop blocks into them? I could drop views, possibly a node, a contact form, etc...

1
  • "Is it good to use panels for every page" Panels has little to no additional performance load. Sometimes its even quicker because panels can be cached.
    – iStryker
    Jul 16, 2011 at 13:14

4 Answers 4

11

Panels is a great module, but it can also be complex and it can take a while before you completely understand it. If you're interested in using panels for every page, the Panels Everywhere module is an interesting project.

Another great project that provides more flexible layouts is Display Suite.

Although people tend to use either Panels or DS, they are not competitors. They can be even used together as you can read on the blog of the author/maintainer of DS: Using panels on view modes in Drupal 7.

1
  • 5
    Don't forget about Context and Omega (Omega Tools)
    – user842
    Jun 30, 2011 at 21:21
2

Views and panels are a good possibility but with the use of a great framework as 960gs!

0

Yes, panels gives you layouts into which you can drop elements.

Panelizer is the most straightforward panels module that simply adds a panel to your pre-existing nodes. (Node Panels is deprecated, but this fact is not widely pointed out.)

So, use the regular node system, but "panelize" nodes if or when you need to.

0

If you are looking to reuse the layout for more then one page, then Display suite with a bunch of fields seems like the best choice.

If you want individual layouts per page, then Panels might be the right thing.


If you want the latter, but are afraid of Panels (as I am), then there is something else you can try. (from https://drupal.stackexchange.com/a/90744/2974)

Modules:

How?

  • Create a node type "frontpage".
  • Add a multiple-value block reference field with "Multiple Selects list" widget.
  • Set up some bean types to allow different kinds of fancy boxes that can be placed on the frontpage.
  • Use blockreference within a bean for nested layouts.
  • One of the bean types could have a multiple-value entityreference to e.g. reference a bunch of products (and have them sortable). I generally prefer this over nodequeue.
  • Use Display suite to define how each bean and the frontpage itself should be displayed.
  • Use Display suite custom field templates to have decorated boxes around each bean/block in the blockreference, or each product, etc. Check hook_ds_field_theme_functions_info(). This stuff is powerful and awesome!
  • Tell the client / content editor to use the contextual links to edit individual beans.
  • In addition you can have Views blocks to be used in the block reference.
  • Inline entity form might be useful, but I have not actually tried it in this combination. This is homework :)

The strategy is that everything that is unique to one page should be a block (or bean instance). We can afford that because those blocks don't pollute any theme regions.

This should give you some material to play with ..
More detailed questions should be discussed in dedicated stackexchange questions, since this is quite broad.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.