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.
