[drupal-devel] [feature] Enable multiple block regions (not just
"left" and "right" sidebars)
adrian
drupal-devel at drupal.org
Mon Apr 18 21:48:50 UTC 2005
Issue status update for http://drupal.org/node/16216
Project: Drupal
Version: cvs
Component: block.module
Category: feature requests
Priority: normal
Assigned to: Anonymous
Reported by: paragkenia
Updated by: adrian
Status: patch
You would then lose the ability to make a special front page theme for
use with the sections module, for instance.
Also, currently styles exist in the same namespace as themes, and we
would have to make more a distinction of styles vs templates (or
themes), but I do think this could help simplify things.
adrian
Previous comments:
------------------------------------------------------------------------
January 26, 2005 - 12:27 : paragkenia
I read the comparision discussion between *Drupal* and *Mambo*. In
several messages it was outlined that Drupal can place blocks only in
right and left and not flexible to put them on anywhere where one want.
It will be great if this can be changed in upcoming versions.
I am no pro at PHP, so don't know how much time this task will take,
but I think it is very important.
parag
------------------------------------------------------------------------
April 15, 2005 - 03:44 : nedjo
This issue was apparently partially addressed in issue
http://drupal.org/node/19694 [1].
[1] http://drupal.org/node/19694
------------------------------------------------------------------------
April 17, 2005 - 02:24 : nedjo
Attachment: http://drupal.org/files/issues/block-dynamic-regions.patch (8.17 KB)
This much-requested functionality - to have the ability to place blocks
in more than the two predefined regions - was partially addressed in
issue http://drupal.org/node/19694. [2]. But "blocks" are still
limited to the "left" and "right" sidebars (hard-coded in
block.module).
This patch is a first step designed to enable multiple (eventually,
admin-definable) regions for blocks. I've moved the existing "left"
and "right" block regions to a 'region' table (with ids of 0 and 1, as
currently used in themes). Then all references to the regions are
drawn dynamically from the table. This way, if further records are
added, they will appear in the list of available regions for block
placement.
Doing this actually reduces some duplicated code, since it's no longer
necessary to repeat code blocks for each of "left" and "right".
As it stands, the patch doesn't add any new functionality--but I don't
think it breaks anything either. New functionality would need (a) new
regions defined, and (b) changes to themes. A simple first step might
be, e.g., to add a "footer" region and then add a call in the footer
generation to append any blocks assigned to the footer region there.
I'm setting this to patch, but I'm aware that it needs some discussion
and refining before it'll be ready to apply.
[2] http://drupal.org/node/19694.
------------------------------------------------------------------------
April 17, 2005 - 03:05 : nedjo
Attachment: http://drupal.org/files/issues/block_regions.png (5.65 KB)
Here's a screenshot showing the block admin page, with drop-downs for
region placement (the options are dynamically generated based on
defined regions).
------------------------------------------------------------------------
April 17, 2005 - 04:57 : adrian
The biggest problem with this is that you can have multiple themes, and
each of these themes can have different regions available.
Also, the method of defining which regions are available needs to be
standardised. Some of the work that me and Vlado are working on for the
install system would go towards solving that problem (ie: meta
information for modules, themes and styles).
This has been discussed to death, but the general consensus has been
that we _want_ to do this, but we need to solve a few other problems
properly first, the most pertinent being the interface issue. Chris
(factoryjoe) recently did a whole mess of workflows for something
related to this.
------------------------------------------------------------------------
April 17, 2005 - 06:09 : syscrusher
The first paragraph of adrian [3]'s post is a point that occurred to me
also, as I read this thread.
One suggestion would be to separate the definition and configuration of
blocks, on one hand, from the placement of those blocks, on the other
hand.
In other words, Drupal core provides a mechanism defining what blocks
exist, which of these are on by default or off by default and
user-selectable vs. which are forced on for all users, and the
configuration (if applicable) of specialized blocks defined by
particular modules.
Each theme provides a standard hook function that returns an array of
region names and help/description text, e.g., array('left'=>t('This
vertical region is left of the main content area'), 'right'=>t('This
vertical region is right of the main content area'), 'footer'=>t('The
footer is below the left, right, and main content areas of the page')).
The theme part of Drupal core (i.e., theme.module itself, not the
individual themes) provides a standard UI that is displayed within
config of *each theme* (but is one physical code base within
theme.module) that allows the administrator to map blocks defined by
Drupal core into regions defined by the theme, and storing that mapping
as an theme-to-block_ID-to-region_ID (with weight) table in the
database. From there, the actual page rendering is similar to what's
being done now, but there is more of it.
I guess what I'm trying to say is that the key to solving this problem
is breaking it along its degrees of orthogonality, and there are three
-- two in Drupal core and one in the individual theme.
Scott
[3] http://drupal.org//user/1517
------------------------------------------------------------------------
April 17, 2005 - 09:14 : Dries
Scott, is right. The theme should export its available regions. Then
the administrator's task is to assign blocks to regions (not to setup
regions). A theme could have configurable regions, but that internal
to the theme.
To me, the real challenge is the UI and the interaction design.
Configuring blocks could easily become a real pain (while most themes
continue to use 'left' and 'right'.)
Of course, we can implement all the functionality, default everything
to 'left' and 'right', and worry about the UI later. This should be
fairly straightforward to implement and nedjo's patch looks like a
first step in the right direction.
------------------------------------------------------------------------
April 17, 2005 - 23:09 : nedjo
I agree with the suggested approach of themes registering their regions.
I'd see this happening when a particular theme is activiated (or
upgraded). Regions would be an array of names (e.g., 'left', 'right',
'footer'). New records would be created in the region table only for
region names not previously registered.
Some areas I'm not clear on, or that need further work:
Table naming
Should a new table be 'region' or 'regions' (I've used 'region')? I
don't see a convention among existing table names, some of which are
singular and others plural.
Default values
I've kept the existing '0' and '1' ids for regions (left and right,
respectively), for backward compatibility. But this means we can't use
autoincrement for the region id (rid), since autoincrements seem to
begin with 1. Likely we should change to autogenerated ids.
Initial records
Using the INSERT INTO statements as I've done for the initial region
entries is probably counterproductive, since sooner or later they'll
have to be dynamically generated. I was hoping this could be a
preliminary patch, with the main work coming later, but likely we need
to solve region registration by themes before this patch is applied. I
don't have a good idea of how region registration by themes would be
implemented (a hook on theme activation?), and invite suggestions or
implementations.
Theme system changes
Besides region registration, the other change I'm seeing that would be
needed in the theme system is loading blocks by region name, rather
than region id. This is because the ids currently used ('0' and '1')
in theory might be diffferent on a particular install.
------------------------------------------------------------------------
April 17, 2005 - 23:18 : syscrusher
Instead of having themes "register" their regions, why not just add a
theme API hook called them_regions() that returns an associative array
of $region_name=>t($region_helptext)? This would be in keeping with
other similar API functions, such as those that return what permissions
apply to a module or what node types are defined by a module. Most
themes are going to define only a small number of regions (two being
the typical case now, but I could see five or six in a complex theme),
so returning a constant array will be faster than querying SQL to
obtain an array of rows.
There could be (optionally, at the discretion of whoever builds this
thing) another API hook like theme_region_properties($region_name) that
returns an associative array with detailed info for a given region, such
as extended help text with recommended usage instructions for the
region.
Scott
------------------------------------------------------------------------
April 17, 2005 - 23:19 : syscrusher
s/them_regions/theme_regions/g
------------------------------------------------------------------------
April 18, 2005 - 00:47 : adrian
Because. The most common 'theme' is a phptemplate theme.
And there needs to be a generic method for specifying the regions
available, in a non hook_function format..
Themes get their names from the directory in which they are contained..
when copying the theme to another directory, there must be _no_
modifications necessary to allow normal usage. This is one of the
tenets of the new template system I designed.
You would need a standard way to define meta-information for themes,
that does not need to be modified when copied to a new directory. We
are working on this in the install system work, as you need a way
external of Drupal to define the module dependencies and some other
things.
My approach would be to add a theme.dsc text file to the directory,
which would allow you to specify meta-information. For instance :
----
regions: left, right, footer, center, mountie
author: Johnny McAngstyPants
----
------------------------------------------------------------------------
April 18, 2005 - 04:00 : syscrusher
Adrian wrote:
"
Themes get their names from the directory in which they are contained..
when copying the theme to another directory, there must be _no_
modifications necessary to allow normal usage. This is one of the
tenets of the new template system I designed.
"
A very good point. But region names don't have to be unique across
different themes, so my hook function wouldn't have to be modified. The
suggestion I made for the mapping metadata was three factors: theme ID
or name, region ID or name, and block ID (plus one non-key weight value
to order the blocks within a region, but this is not relevant here).
I'm not familiar enough with PHP template to be able to respond to your
comments on that one, so if you say it's not feasible to work with my
schema, then I'll take your word for it. :-)
Scott
------------------------------------------------------------------------
April 18, 2005 - 04:03 : syscrusher
Oh, wait.....I see now what you mean! It's not the output of the
function that is the problem, but the *name* of the function.
Never mind. I concede your point.
Scott
------------------------------------------------------------------------
April 18, 2005 - 09:44 : Jaza
I'm probably jumping ahead a bit here... but something that this patch
will have to eventually account for, is how to allow regions to be
defined as inline. Allowing a theme to define a region's position as
being anywhere on the edge of the page (i.e. top, left, right, bottom,
corners, etc) is relatively easy. But what about having a region that's
in the middle of a node's body, or somewhere else that's not the edge of
the page?
What I'm thinking of, is eventually allowing the custom region system
to integrate with the CCK. Like I said, I admit that I'm jumping ahead
into the future - the CCK still has a long way to go before it's ready.
But ultimately, it would be cool if a theme could define a region as
being after, say, the "rating" field in nodes of type "movie review".
This would make the region (and the blocks in it) truly inline and in
context with the actual content of the node.
This would be a huge step forward compared to the current block system,
which doesn't allow you to mix the presentation of blocks and nodes at
all. In Drupal ATM, blocks and "the rest of the page" are totally
separate, and really you have no choice but to display them as such.
The result of this is that information in blocks that really should be
displayed as part of a node, gets literally "pushed to the side", and
always seems secondary to the actual content. Often the block has
content that is just as important as the content of the node itself.
Another option (of less merit, IMO - because of the extra maintenance
work, and lack of enforced consistency) would be to have a region
filter. You could then choose where to place an inline region on a
per-node basis, by entering text such as [region:2] (example based on
image_filter syntax) into the node body.
Anyway, just thought I'd throw that idea into the open. I don't expect
it will be implemented any time soon, but it's something to think
about.
Jeremy
------------------------------------------------------------------------
April 18, 2005 - 10:54 : stefan nagtegaal
Attachment: http://drupal.org/files/issues/regions---possibility-1.png (1.29 KB)
Imo the 'regions' are more than you guys name here.. FOr example I
attached 2 screens which only shows you the regions.. What I think is
that it should always be possible to have free names for the regions.
No matter if i call - the region where my content appears in -
'content' or 'site items'..
See attached screens..
------------------------------------------------------------------------
April 18, 2005 - 10:56 : stefan nagtegaal
Attachment: http://drupal.org/files/issues/regions---possibility-2.png (1.39 KB)
And the second...
See these links:
- http://drupal.org/files/issues/regions---possibility-1.png
- http://drupal.org/files/issues/regions---possibility-2.png
------------------------------------------------------------------------
April 18, 2005 - 17:22 : nedjo
Attachment: http://drupal.org/files/issues/block-dynamic-regions2.patch (13.39 KB)
Here's a revised patch implementing some of the ideas so far. I've used
the theme engine - rather than individual themes - to generate the list
of available regions. I know this isn't ideal, but e.g. for xtemplate
it's at present the only option--no logic is possible in the individual
theme.
region is changed to a varchar field from the current tinyint.
I've roughed in several regions--really just for demo purposes. More
thought and work would be needed to refine them (e.g., styling, etc.).
But this maybe moves the conversation forward.
------------------------------------------------------------------------
April 18, 2005 - 23:26 : Dries
This patch enables different regions to be used. That is a good thing.
The next question is: should we take into account that different themes
could assign blocks to different regions? Lots of problems would be
solved if (i) there could only be one active theme on a website or (ii)
if all themes would have a common set of regions.
(This "let users select their own theme"-thing is a left-over from the
early days, except for WAP stuff maybe.)
------------------------------------------------------------------------
April 18, 2005 - 23:37 : killes at www.drop.org
Giving up multiple theme support would be a great thing. People could
still select from multiple style sheets. WAP shoud not be a user
preference setting, but automatically detected and redirected to a
special site with a WAP theme.
More information about the drupal-devel
mailing list