How I Learned to Stop Worrying and Love the Block
I hated the block system. There I said it. Many of you probably felt the same way. I've used everything I can think of to get around the block system and have built sites every different way imaginable. Recently though, I've had a revelation. The block system, while not perfect, actually is pretty good.
Lets start at the very beginning though. Originally I started out using the core modules that came with Drupal and placed blocks on pages which were usually nodes. This became kludgy very quickly as there became more and more nodes and blocks. The visibility rules for those blocks were usually really nasty php code that would totally hose the site if a syntax error occurred. Not only that but doing more complex layouts got difficult in a hurry as they required modifying the theme to add regions and then put those blocks in the region. Often times clients would want to have a page with a paragraph on top and then a two column set of images/text below. There was no easy way to do this. Either hard code some html and css in the node or edit the theme, add a two regions below the main region and add the css to make the columns line up. The latter was no good because to edit the page contents there would be 1 node and 2 blocks containing the content. Clients were confused.
Then along came panels. Ah, panels. Panels has some very ardent supporters out there (I'm looking at you, EclipseGc) and I'm sure to hear from them because of this. Panels solves the problem of the different layout styles and allows you to have the different columns on the website. Several problems start showing up though. First, the panels interface is daunting. As in way more daunting than views. Views has many options to choose from but it is basically one page with lots of options. Panels has a myriad of wizards and pages that are specifically designed to confuse newbies (ok, slight exaggeration here). Secondly, if you go panels, you have to go panels ALL THE WAY. Mixing panels and non panel pages is an exercise in frustration both from a usability standpoint (How do I change the block on this page? Oh, is it a panels page or not?) and a theming perspective (Why aren't the columns on this page the same width as the rest of the site? Oh, it's a panels page). In the end, we end up with client and themer confusion again.
We also have views which create pages of lists. Often times the client wants to put text on the top of the page. Then they ask how to change that text. Oh crap. First, edit the view. Ignore all the millions of confusing options and find the tiny one in the middle called "Views Header." Oh nevermind. I'll do it. Again, client confusion.
Another entrant came along called the context module. Context was the most awesome thing since sliced bread. You could specify conditions and reactions for just about anything. Granular control without programming. We were in heaven. Then we delivered the site to the client. Same old problems started occurring only possibly worse. How do I place a block on a page? Uh, go to contexts and add a context. See, you want to set up your conditions for when it is visible and then add a reaction for blocks... Oh nevermind, I'll do it. Then, they ask why a block is on a specific page and how to get rid of it. Crap, which context is placing the block there? Time to bust out the admin module again and start hunting through contexts. This leads to everyone confusion.
Oftentimes we'll get wireframes and comps for a site and start building. For each page on the comp we'll pick the type of module to build the page that most closely fits the comp. If the page is simple text and images we'll use nodes. If we see a list of things we'll use views. If we see column data on a page we'll use panels. To place blocks we'll use context. Then we deliver to the client. As stated above, this is where things get messy. Clients don't understand views, panels or context. They don't understand why on one page they can click edit and start changing text but on another they have to edit the view and on another they have to navigate through panels. I've heard plenty of frustrated phone calls about how to add or remove blocks through context as well.
The thing I found again and again with clients is that in the end they just wanted a simple way to manage their blocks. Make it consistent and simple regardless of whether or not it was elegant. I'd build these amazing and complex systems and it confused them. They didn't mind entering 25 lines of node pages for block visibility so long as they could figure it out. This led me to a revelation.
The blocks system actually does work.
Why had I been doing everything I could to avoid it all these years? I'm not entirely sure but as I started playing around with Blocks in Drupal 7 things seem to just work. Yeah there is still room for improvement but it more or less works.
One of the things I've constantly run up against was that the blocks page gets very cluttered quickly. Often there are dozens of blocks in a region, each with different visibility settings. To help improve the situation I recently wrote the block_visibility module. It adds a column on the block admin page that shows the visibility for that block. This helps the situation considerably.
While looking around for other modules I found the viewreference module. At that point I had a revelation. Why not make (almost) every page on the site a node? Clients would be happy because every page would have an edit tab at the top where they could edit the page. By using viewreference I could attach a view at the bottom of the page. Then as I was building I realized that not everything I needed to attach was a view. Often clients want quicktabs or some other block to attach to a node. This is when I found the blockreference module. It is very similar to viewreference. It defines a field where you can attach a block to a node. When the node page renders the block is wherever the field is set.
As I set about building the site everything just worked. All the pages were the same page content type. The content type had two additional fields, a view reference and a block reference. If either one was set then the page would have some additional more complex information below. All blocks were set with the block system so the client could figure out how and where to set things. Since all the pages were nodes, it was fairly simple to figure out.
So far this has been such a huge success in simplifying the administration of the site that I'm planning on doing very similar things with other sites as much as I can. There will still be a few cases where a views page is appropriate but overall I really like how it works.
What's funny about this is basically I've gone back to using nodes and blocks they way they were originally intended. This is probably a testament to how much Drupal 7 was improved.
