[development] Fixing themes and regions

[Bèr Kessels]

Op dinsdag 22 augustus 2006 18:52, schreef Dries Buytaert:
> So ... what is the summary of this thread, and the required/agreed  
> action points in particular?  Do we need to change something?

Grabbing bits and pieces from the thread, I think the following summarises it 
as a nice list of action-points. 

## Neil Drumm:
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.

## Bèr (me):
Let's investigate what 
should be a block in a region, in core.

* Help (help region)
* Message (messages region)
* Mission (frontpage region, special region)
* Footer (footer region, or sematically more correct "legal" or so).
* Primary/secondary links (navigation region)
* Logo (identity region)

## Nedjo (original post)
2. Pull the theme-block configuration into a separate table, e.g., 
block_theme, with fields module, delta, theme, region
AKA: normalise the database and clean up the tables.
I'm suggesting we normalize the table. We would end up with two tables. One 
is our existing blocks table, minus the 'theme' and 'region' fields. The 
second, block_theme, has the 'theme' and 'region' fields as well as module 
and delta. There are (potentially) many records in block_theme for each 
record in blocks.

## Neil Drumm:
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.


All other suggestions and ideas were either met with scepsis, or are simply 
not clear enough (to me!).

Bèr