[development] Fixing themes and regions

[Evan Leeson]

On Aug 17, 2006, at 5:30 PM, Neil Drumm wrote:

> Nedjo Rogers wrote:
>> I know that there's work ongoing to improve theme handling of  
>> regions. But I'm behind on the status of this work. Is any of it  
>> for 4.8/5.0?
>
> I see two big challenges in block administration:
>
>
> 1. The number of regions is getting larger
>
> Block regions are defined by the needs of page templates. Multiple  
> themes can be enabled and have at least one page template each.  
> More page templates can be defined by path [1]. There continue to  
> be a lot of blocks.
>
> This trend is already straining the existing user interface.  
> Placing a block in multiple regions will probably be wanted in the  
> future.
>
> The UI is currently block-driven, you see every block and decide  
> where it needs to go. I think this needs to be reversed to be  
> region-driven. You see every region and decide what needs to go in it.

WordPress widgets uses an excellent  ajaxian UI where you drag and  
drop widgets (blocks) into columns that represent regions so you can  
see how they will show up and can re-order them by drag and drop.  
Given most Drupal Themes arrange blocks vertically inside regions,  
this would seem to be applicable as well, though a horizontal region  
should be representable the same way. Then you click on that block in  
the GUI to bring up other block configuration options like block  
title, contents, etc.

Drag and drop might remove the need for setting weights the way we do  
it now.

In this case I would suggest the blocks be arranged by region as you  
suggest, but also by template. I tend to use multiple page templates,  
so a tab in the block administration interface for each template in a  
theme would be useful as well. each tab would give you another visual  
representation of the block arrangement.

Permissions-based display of a lot of blocks (i.e. in an OG install)  
would make this kind of interface a challenge in a high N block  
environment, but I must say, I love the way Wordpress Widgets does  
it.  In the case of a lot of blocks, you could allow the user to  
scale the GUI so blocks are smaller, and then they magnify on mouse- 
over like the icons in the Mac OS X Dock. And then we could solve all  
the pain and suffering the world and end war forever.  :-)

I'm jumping in in the middle here so I hope I'm not redundant. Please  
ignore if so.

evan

>
> The first step might be getting rid of the disabled block listing  
> and instead putting an add block function in every region along  
> with database and architecture changes to allow a block to appear  
> twice. The rest would be finding good ways to arrange the regions  
> in a way that works.
>
>
> 2. It is (still) hard to tell when a block will show
>
> Whether a block will show or not is a combination of
> - The theme is being used
> - The page template being used
> - The overall block configuration (including throttle)
> - Logic in the module generating the block
> - Various settings on the block's configuration page
> - Users' settings
>
> The various types of rules I could identify from module logic and  
> user settings include
> - Permissions (module) and roles (setting)
> - Does any content exist (module)
> - Node type (module and/or setting)
> - Page path (module and/or setting)
> - Users' setting (setting)
> - PHP code (setting)
>
> One improvement could be improving the visibility of the module  
> logic by listing the rules next to the user-created rules. Since  
> many of the rule types can be user-generated and/or module- 
> generated, integrating these in API (instead of simply putting  
> another thing on the block API to put out a string describing when  
> the module intends to show a block) would be a good gain.
>
>
>
> [1] While defining page templates by path is great for custom  
> themeing, it limits the ability to redistribute themes since paths  
> will change from site to site. It would be nice to have a UI to  
> pick which page template is on which page.
>
> -- 
> Neil Drumm
> http://delocalizedham.com/