[drupal-devel] [feature] Block regions
Kiev1.org
drupal-devel at drupal.org
Thu Jan 27 15:19:04 UTC 2005
Project: Drupal
Version: cvs
Component: block.module
Category: feature requests
Priority: normal
Assigned to: arnabdotorg
Reported by: arnabdotorg
Updated by: Kiev1.org
Status: patch
http: // kiev1.org/download/block_module.zip
only it works while only with the usual themes, not using xtemplate -
to use so (there an example of a theme inside archive) - on similarity
as was
$leftblocks = theme ("blocks", "left");
$rightblocks = theme ("blocks", "right");
but in an any kind
$yyy=theme ("blocks", " anywhere 1 ");
$zzz=theme ("blocks", " for example here ");
$nnn=theme ("blocks", " and here it it is possible ");
$mmm=theme ("blocks", " or here it it is possible ");
Variables then to deduce where it is necessary to place in design group
of blocks as they were deduced earlier only to an attribute at the
left-on the right, now anywhere and as much as necessary, and the
changed module block itself parse the file of a pattern for new such
zones and in the administrator-panel of blocks shows those the dropping
out list instead of a radiobud all that has found in the current theme
and the block can be placed in an any zone instead of in left-right (in
general it is an initial variant shall complete then that with theme
engine worked)
requre
ALTER TABLE `blocks` CHANGE `region` `region` VARCHAR( 255 ) DEFAULT
'0' NOT NULL
Kiev1.org
Previous comments:
------------------------------------------------------------------------
November 16, 2004 - 08:17 : arnabdotorg
Attachment: http://drupal.org/files/issues/regions.png (6.46 KB)
(I don't know if this point has been brought up before, so writing
this...)
A Thought: Why do we have just "left" and "right" areas for blocks?
Ideally, regions should be configurable. This way we can have many
possiblities, like header blocks, footer blocks, etc. imho, This is a
very important feature for any good themeable CMS.
The design pattern is: "One Node area, to show the current document;
and many side block regions to show assosciated data"
------------------------------------------------------------------------
November 16, 2004 - 11:04 : arnabdotorg
Has been talked of before, posting links for reference:
http://drupal.org/node/2790
http://drupal.org/node/10653
------------------------------------------------------------------------
November 16, 2004 - 16:38 : arnabdotorg
Attachment: http://drupal.org/files/issues/patch_2.txt (2.56 KB)
Patch to latest block.module in CVS; changes the binary {left, right}
regions to {left, right, [custom....]} regions.
Any theme can now use theme_blocks("XXXX") where XXXX is any region set
up in the Blocks admin menu; not just left, or right. Current themes
with {left,right} will be unaffected.
Demo site: http://arnab.drupaldevs.org/ [authenticated user has
block_admin perms]
Move the blocks around "apples" "mangoes" and "grapes"; which are
defined as regions in the theme (colored areas).
shuffle...
------------------------------------------------------------------------
November 16, 2004 - 17:07 : Anonymous
This is potentially a very useful patch. It should be noted that this
would only be added to the CVS HEAD branch, not to 4.5, as 4.5 is in a
bugfix-only stage.
Also, would you mind resubmitting your patch using the unified diff
format? See these instructions for submitting patches [1].
[1] http://drupal.org/patch
------------------------------------------------------------------------
November 16, 2004 - 17:22 : arnabdotorg
Attachment: http://drupal.org/files/issues/patch_3.txt (4.01 KB)
- diff format fixed, attached.
- full code: http://arnab.drupaldevs.org/files/block.module.phps
------------------------------------------------------------------------
November 16, 2004 - 17:36 : stefan nagtegaal
Wouldm't it be nicer if the theme itself spits out the block_regions
which it supports?
So, in your theme:
Which will be parsed through the theme settings where we can select
which blocks to display in which region.. Imo this is going to the
right direction, but isn't really the way it should be yet..
What happens if I had a theme anbled which has 4 regions, and I switch
to a theme which only supports one?
Stefan
------------------------------------------------------------------------
November 16, 2004 - 18:27 : tostinni
Can't we log on your demo site using drupal ID ?
------------------------------------------------------------------------
November 16, 2004 - 18:31 : arnabdotorg
1. All themes support either {left,right} or {all}
2. If you notice that a theme doesn't support a region, either rename
the region, or create that region and move the block to that region.
Dependency handling is imho overkill for the job at hand. In other
words, you can always move blocks back to left / right.
------------------------------------------------------------------------
November 16, 2004 - 19:03 : drumm
I think this feature is greatly needed. Allowing more block regions
could clear away a bunch of the clutter in the theme configuration
pages.
However, providing a UI which won't work unless you have intimate
knowlege of your theme (who would guess 'mangoes' is a region) is quite
bad. I think something closer to the suggestion in #5 should be used.
The edge cases, changing themes and allowing users to pick their own
theme, provides some problems. I don't have any good ideas for that.
------------------------------------------------------------------------
November 17, 2004 - 03:37 : arnabdotorg
Attachment: http://drupal.org/files/issues/block.module.patch (4.33 KB)
Incorporated ideas from #5; a theme can now have the function:
If this function is defined, we check if this list is identical to the
current list of regions setup. If it is not, we issue a critical
warning to the user that things are amiss. This is done both during
setting up the regions, and selecting a theme.
If the themes_block_regions is not defined, nothing happens.
Files affected:
block.module
system.module
------------------------------------------------------------------------
November 17, 2004 - 03:38 : arnabdotorg
Attachment: http://drupal.org/files/issues/system.module_0.patch (811 bytes)
------------------------------------------------------------------------
November 17, 2004 - 23:17 : Goba
OK, but what if a user changes the theme? A site can have multiple
themes... You only check for the theme set when the admin sets the
block regions... Also none of the themes should define functions
starting with theme_, as this prefix is reserved for Drupal built in
theme functions. Themes define theme functions with their own prefix.
BTW I have also spotted a code style problem. We are not using string
concatenation with SQL parameters, but the %s notation for strings and
%d for numbers. Look for the db_query() implementation if you need more
info.
------------------------------------------------------------------------
November 18, 2004 - 08:55 : Dries
I agree that the theme should control the available regions (cfr.
comment #5).
As different themes can co-exist, the block positions should become
configurable per-theme.
------------------------------------------------------------------------
November 18, 2004 - 14:08 : Bèr Kessels
Attachment: http://drupal.org/files/issues/canvas-regions.png (15.48 KB)
I love this idea of regions. And to add my 2C I investigated the
existing themes, and my sites to find a genral set of regions. I placed
them in a schetch. I also suggest to folow the naming convention in that
scetch, since those names are already most common in Drupal themes.
------------------------------------------------------------------------
November 18, 2004 - 14:17 : Bèr Kessels
Pressed. submit too early Sorry. I still had some additional comments:
canvas = body.
canvas.head.primary and canvas.head.secondary, could and should be
merged into one, but thats still a project in preperation. It will then
become canvas.head.navigation
canvas.main.mission is a bit a silly name, but we use it currently a
lot. IMO, it could better be renamed to canvas.main.pre. It can contain
(error) messages, mission, etc.
We should refrain from the words "node" since there is far more content
than nodes.Hence I named it canvas.main.content.
Maybe, when future dictates it, we could split up the
canvas.main.content into four regions, canvas.main.content.NE
canvas.main.content.SE canvas.main.content.SW canvas.main.content.NW.
That would allow us to create more dynamical layouts, often used by
portals on fromt page. (E.gG to show the headline picture top-left in
content region.
------------------------------------------------------------------------
November 18, 2004 - 15:53 : arnabdotorg
dries: you're right, Stefan and I were discussing the same thing. The
"regions" configuration needs to be refactored out of block admin and
moved into the theme configuration; regions configurable on a per theme
basis. This also makes sense; region placement is a presentation issue
and should be separated from content. However, I don't think the
current DB schema for blocks will support this, options:
1) add "theme" attribute to {blocks} and store themeid [bad design,
unnormalized data]
2) add "regions"(themeid, blockid, regionid) table for solely this
feature. [normalized version of (1), but too much?]
3) store this in {system} somehow.
goba: thanks for pointing those out, will make changes in next patch.
berkes: Thanks for the sketch, helpful. Something like this can find a
good place in the Theme developer's(designer's?) handbook, under
"region naming guidelines"; or something like that. Note that I say
"guidelines"; I don't think we should restrict designers to conform to
any presentation metaphors. (not even {left, right}! :) ) However, such
kind of guidelines can be coded into drupal for "intelligently"
allocating regions for blocks - i.e. if we already have block->region
configuration for a theme, it can be reused to create initial settings
for a newly installed theme.
Todo list:
Decide on ...
1) how to store per-theme blockregion info.
2) function name to give for region discovery in place of
themes_block_regions()
Some layouts to browse:
http://www.terminus1525.ca/
http://k10k.net/
http://www.stylegala.com/
http://www.iht.com/pages/index.html
------------------------------------------------------------------------
November 18, 2004 - 17:09 : Bèr Kessels
More on 5the "naming guidelines". Of course they should be "guidelines"
and not laws! But... Users are dumb. Users know nothing, And mostly:
users should not need to know anything.
Thats why I proposed the naming guidelines, and chopped up everything
in regions. I would really, really like to see these regions to be the
default regions. We should always try to deliver a
ready-out-of-the-box working Drupal. We should really try to have
everything working, by default. And try to make everything working,
also without need to configure ofr even access the theme
configuration.
In other words: There must be a default set of regions (similar to what
we have now, with only left and right) preferably (by me) the regions I
named in my png. This set of regiosn should be default, and available in
the default (core) themes.
Bèr
------------------------------------------------------------------------
November 18, 2004 - 20:56 : Steven
I'd like to point out that ber's sketch is just one possibility. Even
the Drupal.org theme does not follow it, as the mission is between the
main content and the header, and not flanked by the sidebars.
We should avoid making structure part of the naming.
------------------------------------------------------------------------
November 18, 2004 - 23:38 : FactoryJoe at civicspacelabs.org
We should avoid making structure part of the naming.
This is key. In my latest theme (Democratica), I've changed the typical
"heading" and "footer" IDs to be called "branding" and "notices" since
that's what they're typically used for, rather than where they are to
be positioned.
I see a need for some leadership in determining both what regions
should come standard with each theme, how to name the regions
geographically as opposed to content use, and whether the control
should lie in the CSS or in the theme admin interface (for instance, if
I, as the theme designer want to force notices to be above the logo in
my CSS).
I think giving control to the users and admins is awesome and this idea
is one that I planned to advocate in my as yet vapordoc Theme Proposal.
I'd like to see where this discussion goes because while I think this
functionality is important, I strongly feel like we need to develop an
idea of what the ideal theme development/administration interface and
workflow would look like rather than tossing on features that would do
more to create bad site design rather than improve it or make it easy
for non-designers.
------------------------------------------------------------------------
November 19, 2004 - 10:32 : stefan nagtegaal
Something I don't get at the moment is why we want standardized names
for the regions..
I think that it is better to make it regionname free, so it is for the
theme administrator always clear where the blocks will appear..
In the situation we currently have, it is possible to set the region to
'left' and let the blocks appear on the right and the other way around,
due to changing the theme.
I think it is better to specify the regions inside any theme by doing:
But, for another use of the site, a whole other block usage and
approach can be used so the _regions() will look more like:
Looking at the above examples we see that, with the use of free
region-names, it is more clear to a third user (which downloaded the
theme), for what purposes all these regions are ment to be used..
I'm not fully convinced about the following approach, but it is
probably possible todo a module_invoke on the 'regions' hook or have a
error returned when there is no overrided function is found for the
standard theme_regions()..
------------------------------------------------------------------------
November 21, 2004 - 03:25 : FactoryJoe at civicspacelabs.org
With all due respect, I think that this whole discussion is missing
something... primarily a compatible goal and a purpose.
On the one hand, we want to have more semantic markup and more
flexibility from the layout engine (which, as of now, is simply a block
configuration tool that allows you to choose "right" or "left" and order
the blocks). Up until now, this functionality has sufficed, but when it
comes to making more advanced layouts like k10k.net or
downhillbattle.org, a much richer toolset is needed.
So on the one hand, we have end-users'/admins' goals of arranging
content on their site.
On the other hand, we have theme developers who need a more flexible
way of creating regions that different types of content can be dropped
into and a web interface that can give admins the ability to choose not
only what content gets dropped in, but whether content is dropped into
the region at all.
And a final issue is whether we have a standard number of regions that
have pre-defined relationships that people can count on from theme to
theme or whether we leave it entirely up to theme designers a la
csszengarden.com.
I don't know that there's one simple or easy solution to all of these
various needs. The way that this discussion has been going leads me to
think that the complexity of this problem isn't fully appreciated
despite all of the good suggestions and ideas. Ber Kessel's nice
regions mockup [2] only exacerbates the problem because it extends the
current head/3-column/footer Drupal paradigm — exactly what we
want to move away!
I'm not saying that I have a ready solution, but that I think this
requires some serious thinking not from the perspective of what's
doable given the current block system, but how this whole theme
config-theme development ecology should work. I'm extremely concerned
about jumping into a partial solution that doesn't fully serve anyone's
purposes.
I mean, if the best solution is to make theme development easier and
more powerful by removing control from the admin, I would support that.
If more control for the admin is the best solution at the expense of
theme designers flexibility, ok. But I think we need to take a step
back and do this right instead of cludge in some ad-hoc solution.
To this end, I've been working on an overarching theming proposal...
but with the CivicSpace 0.8 release, I haven't had time to devote to
it... I'd be interested to hear what people think the IDEAL system for
theming would like, rather than something that simply integrates into
the existing system... Not because we need to rewrite the whole thing,
but because we need fresh ideas and approaches to an obviously
complicated problem.
[2] http://drupal.org/files/issues/canvas-regions.png
--
View: http://drupal.org/node/13008
Edit: http://drupal.org/project/comments/add/13008
More information about the drupal-devel
mailing list