[development] Fixing themes and regions
ber at webschuur.com
Wed Aug 23 12:10:46 UTC 2006
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
- 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!).
More information about the development