Last spring, I've read a Drupal theming book and was amazed by how things like the search and menu features for themes need special settings and theming while their parallel implementation exist as blocks. I was also deep in improving input formats (which was since then taken on by others) and did a comparison of what is not input format enabled in Drupal. That uncovered even more parallel implementations of things which should basically be blocks.
At Acquia, we are (among other cool things) hard at work to improve the user experience for Drupal 7 and as part of that effort, I am focusing on regions and blocks so that page building can be more unified then ever. You should know where to look to position your content, disable items on the page, set up custom text for pages, etc.
Help settings
I started off with the help settings. Drupal themes have a $help variable and that help text is usually generated by one or more modules. There are two independent user provided settings for help however. One can put admin provided help on top of the user registration and the contact pages. These are implemented as custom settings which add this help to the page in custom ways.
I realized that by making the $help item a region, we can gain certain cool features:
- You could add custom help to any page you want. Cut out the two one-off settings and let the admin put custom help on any page they want.
- Use your favorite input format to enter the text with your favorite WYSIWYG editor for it (or without that obviously).
- The admin could completely disable display of help. Display of help could even be disabled for higher roles (site editors), for whom help might be in the way. Different custom help could be provided for different roles.
- Admins could provide users with user customization possibility for the help display. This is already supported by Drupal for any block.
- Custom set help text could be displayed on more then one page (eg. in a site area).
All this without coding, loosing two custom settings and making the help area a region. Pretty cool, heh? Check out the patch which needs a reroll here: http://drupal.org/node/240873
Content region
In Drupal, the main page content is output by appending the blocks put into the content region in this order. There is no way to put stuff above the main page content by default. Many themes worked around this in Drupal 5 and 6 by adding a content_top and a content_bottom region instead, so you can put stuff above and below the main page content. I believe "top" and "bottom" or "above" and "below" are keywords we handle inside the regions system. We move stuff around inside one region to order them. So I suggested we should have one region for content and make the "main page content" a regular looking block instead.
There are obviously some improvements needed to ensure that all themes can accommodate this block and that people cannot easily turn it off. These are being discussed. Patch needing review at http://drupal.org/node/428744
Site mission
This case provided the title hint for the blog post. Mission statement is a setting in Drupal at least in the past half decade. It is configurable on a plain textarea on the site settings page (no input format selection) and is hardwired in themes to show on the front page of the site. Or not at all if the theme customization options have it unchecked.
If we go a bit farther, we see we have a way to put text into a region of the website on one specific page here. Wow, sounds like a highly simplified version of what blocks can do ripped of all the flexibility (even input format selection).
Having mission as a region would allow us cool things like:
- We can have a mission statement displayed on more then the front page (e.g also on the company team page).
- We can have the mission statement only displayed somewhere else, but not on the front page (eg. only on the company team page).
- We can set whatever input format we want so we can even display complex maps for example.
- We can put more then one block into that region, so dynamic data can be output there via module defined blocks.
This all sounds too good so obviously there are some small drawbacks as well. Discuss in the issue queue: http://drupal.org/node/428800
Even more blocks, even more regions?
If you look at the site and theme settings, a few remaining items pop into your face, which will need attention once we have the above covered:
- The footer message. This should just be one block among the others in the footer. No reason to make it special whatsoever.
- Special search feature of themes. This is just a search block themed differently. Sites using this most often not use the regular search block provided by search module. As shown in Mark's and Leisa's video on themes, having a search setting on themes, while search module is not enabled, so you cannot even enable it is disconcerting. If the theme has a special place for the search block, it can expose a search region, where people can put their search block, and that would be themed specially in that region. All block visibility and other settings would apply to this one nicely and it would only ever show up once search module is enabled. Plus it would allow to put alternate search boxes into that region. Blocks exposed by ApacheSolr or any other search module.
- Special main and secondary menu display of themes. Again, these are *already blocks*. Themes can just theme them differently when they are in their designated regions. Again, less theme settings, more visibility control, being able to swap menus in sections of the sites via other menu blocks, and so on.
I hope I managed to find some people who agree that special settings in site settings and themes should finally go and regions and blocks should take over the stage. They are already well developed and have all the features we need to implement the custom stuff we remove, but at the same time allow for amazingly more. Please help on the above three improvements and then we can move on to even more goodness.
Ps. Many people suggested that relying more on blocks is not good now that blocks module is optional in Drupal 7. Things like Panels are supposed to be able to take over the UI and set the layout for the page in more versatile ways, hence blocks module became optional. I believe that this does not mean that we should keep custom one-off settings around and broken theme settings alive. Also, Panels exposes all the blocks for the page layout setup, so people can just as well use them to set up their page.
Everything's a Block!
I love it! Having everything as a block provides so much more flexibility in placing content on a page. And there's another HUGE benefit:
Block Caching.
Virtually everything on a page could be cached (except for things that should not be cached, like login name or user information) This could vastly speed up Drupal on shared accounts. Block caching is a far more powerful and flexible way of caching than Boost, and allows the developer to use his knowledge of his own system to control the amount and instances of caching.
Along with this paradigm, we should concentrate on eliminating redundant and unnecessary queries on page display.
I agree on the move toward blocks but...
I think the way blocks currently works is a bit of a mess. I think something like the way context handles blocks or even some work jeff noyes did on the blocks admin... http://www.jeffnoyes.com/content/drupal-7-usability-improvements-part-i… would make it so much more user friendly!
work on Drupal 7 blocks UI
Well, there is substantial thinking around how blocks organization should be done in Drupal 7. If it is done like Mark and Leisa explains in http://www.youtube.com/watch?v=l2KrK2LeRBA then having as many pieces of the page as blocks makes total sense, since then you can just move them around without being tied to certain hard-positioned elements.
Autoloading Regions
This really make me think about autoloading regions. Why build a region with it's blocks if you are not going to use them all.
So, instead of print $region_name you could do something like print $region->name and build the region when it's called. We could expand on our usage of regions and not have to worry so much about the performance hits.
Plus, we could expand the usage of regions to node templates, views templates, etc.
I liked this enough I added it to the issues queue at http://drupal.org/node/428986
the performance arguments
Well, that the current system does not perform the best (always renders all regions) does not mean we should not improve regions *and* their performance. By pushing blocks optional and staring at Panels instead, we just neglect our core site building system, while in fact, we should improve it closer to Panels level, so we achieve Panels in core :)
I brought up this more regions and more blocks suggestion last spring on the development list: http://lists.drupal.org/pipermail/development/2008-February/thread.html… Among other things, people suggested to have a function call instead of a variable for themes, so the function call would gather and render blocks for that region. That is "autoloading" in a procedural sense. However it is implemented, we need a way to not generate what we don't use obviously, so I completely agree that this needs to be done.
Portlets and J2EE Portals
Interesting idea especially considering that this is now a proven approach to problems Drupal tries to address. J2EE Portals consider everything a "block" called portlet.
Albeit portlets have a distinguised controller code and work in separation from each other the rendering idea is the same as Gábor explains.
Hope it goes through and we can take a step yet again for a leaner Drupal core!
Down with Theme Settings!
I completely agree with you, Gábor! The standard settings on Theme configuration page are annoyingly vague and mostly redundant. If you want Search in your theme, enable the module and add the block. User pictures? There's already a toggle for that on the user settings, so why do we need a double toggle on the theme settings?
We'll need to tackle each of them individually and leave the Theme Settings page for custom theme settings (theme settings api)
Blocks Lite?
I was just thinking about this, I'm writing some custom modules where I want to output content into different regions. It's often just a short string, and it seemed overkill to go write an entire hook_block, setting title to blank, removing the <div class="block">... theming, adjusting it in the admin interface... What I wanted was something like:
drupal_print_to_region($region, $html, $weight=0)
Which would create a simple block on-the-fly and push it into the region. So I very much like the direction of simplifying regions and having everything as blocks, but then let's have a lightweight way of generating one-off blocks.
hook_page_alter()
Drupal 7 allows you to alter the page array, which after blocks module run its own alter_page, also includes all the regions. You can easily add in your own "lightweight blocks" to that array there. All solved in Drupal 7 already.
Same here
Incidentally, I think I have partially touched the same train of thought in Site Information as Blocks, so I definitely, obviously +1 on it. : )
As someone who has themed
As someone who has themed over 15 different Drupal 6.x sites in the last 5 months, I wholeheartedly agree with Gabor on this one. In Genesis AND Zen, I turn off all "pseudo" blocks in the theme layer and use real blocks if and when I need them.
This is also a sticking point with our designers. Once I train them on the blocks system, they get confused when they enable primary links and then they have a duplicate.
Josh
I'm a little late on getting
I'm a little late on getting up to speed on this, but wanted to see if I understand correctly: Regions should be used for content that should not be repositioned by the user, and blocks should be used for content that can be. That's only part of what you talked about, but I wanted to make sure that that was a principle I can distill from this.
Thanks!
Chris
depends
In Drupal 7 there is already support for hidden regions, so you can set up regions with program-generated blocks, which the user will never see on the UI. In Drupal 6 however, all blocks in all regions can be seen and repositioned on the blocks admin UI.