Block regions

Wouldm't it be nicer if the theme itself spits out the block_regions which it supports?

So, in your theme:

theme_block_regions() {
  return array('top', 'right', 'bottom', 'left');
}

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

Can't we log on your demo site using drupal ID ?

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.

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.

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.

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.

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.

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

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.

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.

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:

/**
 * Example for the Chameleon-theme
**/
function chameleon_regions() {
  return array('left blocks', 'right blocks');
}

But, for another use of the site, a whole other block usage and approach can be used so the _regions() will look more like:

/**
 * Example for an example Marketing-theme
**/
function marketingexample_regions() {
  return array('advertises at the top', 'advertises on the right', 'right blocks', 'content related blocks');
}

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()..

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 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.

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

Arnab, your patches got uploaded as html. Also, please post one multifile patch for all your changes.