I'm not sure I understand what you are proposing ...

Currently we store a row in the blocks table for each module/delta/theme/region combination. This allows separate configuration of blocks by theme--a block can be enabled in one theme but disabled in another. That seemed like a good idea when we introduced the functionality. But it turns out that, if you have, say, 10 themes enabled, it's next to impossible to get your blocks configured evenly across themes. To enable a new block on all themes, you need to visit and submit 10 different screens (one for each theme). The result, on most sites, is a table with many near-duplicate records--they vary only by theme and/or region. 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. For the UI, the basic block configuration would be done only once. Just the region placement would be theme-specific. That's more or less what I've done in the blockregion module. It uses form_alter to change the default theme's block configuration page into a page for overall configuration of all settings. Then each additional theme's block configuration page is limited to region placement. I've added a screenshot of a non-default theme's UI: http://drupal.org/project/blockregion

Op vrijdag 18 augustus 2006 02:30, schreef Neil Drumm:

[1] While defining page templates by path is great for custom themeing, it limits the ability to redistribute themes since paths will change from site to site. It would be nice to have a UI to pick which page template is on which page.

sections.module? This is the main thing that I have against the various themes (civicspace) that hardcode the admin area/theme. Bèr

On Aug 17, 2006, at 5:30 PM, Neil Drumm wrote:

Nedjo Rogers wrote:

...

I know that there's work ongoing to improve theme handling of regions. But I'm behind on the status of this work. Is any of it for 4.8/5.0?

I see two big challenges in block administration:

1. The number of regions is getting larger

Block regions are defined by the needs of page templates. Multiple themes can be enabled and have at least one page template each. More page templates can be defined by path [1]. There continue to be a lot of blocks.

This trend is already straining the existing user interface. Placing a block in multiple regions will probably be wanted in the future.

The UI is currently block-driven, you see every block and decide where it needs to go. I think this needs to be reversed to be region-driven. You see every region and decide what needs to go in it.

WordPress widgets uses an excellent ajaxian UI where you drag and drop widgets (blocks) into columns that represent regions so you can see how they will show up and can re-order them by drag and drop. Given most Drupal Themes arrange blocks vertically inside regions, this would seem to be applicable as well, though a horizontal region should be representable the same way. Then you click on that block in the GUI to bring up other block configuration options like block title, contents, etc. Drag and drop might remove the need for setting weights the way we do it now. In this case I would suggest the blocks be arranged by region as you suggest, but also by template. I tend to use multiple page templates, so a tab in the block administration interface for each template in a theme would be useful as well. each tab would give you another visual representation of the block arrangement. Permissions-based display of a lot of blocks (i.e. in an OG install) would make this kind of interface a challenge in a high N block environment, but I must say, I love the way Wordpress Widgets does it. In the case of a lot of blocks, you could allow the user to scale the GUI so blocks are smaller, and then they magnify on mouse- over like the icons in the Mac OS X Dock. And then we could solve all the pain and suffering the world and end war forever. :-) I'm jumping in in the middle here so I hope I'm not redundant. Please ignore if so. evan

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.

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

[1] While defining page templates by path is great for custom themeing, it limits the ability to redistribute themes since paths will change from site to site. It would be nice to have a UI to pick which page template is on which page.

-- Neil Drumm http://delocalizedham.com/

Op dinsdag 22 augustus 2006 09:06, schreef johan@forngren.com:

I like these thoughts, fact is that I was going to write something simular when I got the time... However, how about non javascript browsers?

The problem is not so much the interface. So adding nifty javascript will not solve the REAL problem. The real problem is that the concept of regions and blocks and their configuration is very inconsistent (troughout modules and themes, even in core) and very complex. One could argue that blocks icw multiple themes in Drupal are "brokenish" right now. One could argue that blocks that seem to (re)appear at random (why does a book block show up only there and not here? is one of the most asked quesions from my clients). One could argue about whether or not we must offer PHP block visibility or rather some far simpler interface, etc etc. Lets focus on a real solution, instead of obfuscating a rather "brokenish" system with javascript and ajax. Once we have the real problems cleared out and can offer people a consistent, clear and simple solution for blocks we should look at adding drag and drop. No earlier IMO. Bèr

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

The block regions feature was touted as a much needed improvement, and after many years, finally made it into Drupal 4.7. That said, I haven't seen that many people take advantage of it. This can mean (at least)

I use it in nearly every site I do now - I don't think people take advantage of it too much because the number of users in Drupal who have "different" themes, or those with special requirements, is low. But it is most certainly being used quite regularly at Trellon, LLC. -- Morbus Iff ( sleep breeds sanity ) Technical: http://www.oreillynet.com/pub/au/779 Culture: http://www.disobey.com/ and http://www.gamegrene.com/ icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus

...

I use it in nearly every site I do now

*aol*

What I still do not use is the "multiple themes" feature, though.

I use that regularly with sections.module - all of admin and node editing goes into bluemarine, and everything else is controlled by my user visible theme (which is almost never plausible to use for administrative display also). I can't say that I've set upon a master setup of admin/bluemarine-only blocks that make it the ultimate adminterface, but I certainly like the idea that I someday might ;) -- Morbus Iff ( dare you overpower my stench of eeeevil? ) Technical: http://www.oreillynet.com/pub/au/779 Culture: http://www.disobey.com/ and http://www.gamegrene.com/ icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus

The block regions feature was touted as a much needed improvement, and after many years, finally made it into Drupal 4.7. That said, I haven't seen that many people take advantage of it. This can mean (at least) three things:

I use the 4.7 region feature extensively. Before I converted my sites to 4.7, I used several methods to display adsense blocks. These ranged from the flexiblock module, to calling block_block('view', $delta) directly. When I converted my sites to 4.7, I junked all that in favor of regions. I even went further and had one "announcment" block at the top center of the page, also using regions. One problem I ran into, is that all blocks now inherit the styles of side bar blocks, and I had to work around that with some quick hacks. I agree with what Nedjo is saying, that normalization could help. I did not run into that issue myself, because most of my sites are one theme type of sites, however, I realize it can be a drag editing tons of themes.

On 8/18/06, Khalid B <kb@2bits.com> wrote:

...

The block regions feature was touted as a much needed improvement, and after many years, finally made it into Drupal 4.7. That said, I haven't seen that many people take advantage of it. This can mean (at least) three things:

I use the 4.7 region feature extensively.

Before I converted my sites to 4.7, I used several methods to display adsense blocks. These ranged from the flexiblock module, to calling block_block('view', $delta) directly.

When I converted my sites to 4.7, I junked all that in favor of regions.

I even went further and had one "announcment" block at the top center of the page, also using regions.

One problem I ran into, is that all blocks now inherit the styles of side bar blocks, and I had to work around that with some quick hacks.

Well, that is absolutely theme dependent. If you do styles that look like .region .block, then all will be different. block.tpl.php still ends up being a giant switch statement for truly unique blocks (not just CSS skinning). I agree with what Nedjo is saying, that normalization could help. I did

not run into that issue myself, because most of my sites are one theme type of sites, however, I realize it can be a drag editing tons of themes.

There are some logic flow problems that make it hard(er). You edit/add blocks "in" one theme, then hit save...and find yourself at the "first" theme, even if that is not the default. I'd love to see this approached from the point of view of themers. I do think e.g. panels module is more what themers were hoping for: an easy way to store chunks of content (nodes, blocks) and then a way to select where to place them in a layout (panels). There are a few themes that use regions to good affect. I think it's the Internet (?) theme that has four columns -- one left, one main, two right. -- Boris Mann Vancouver 778-896-2747 San Francisco 415-367-3595 Skype borismann http://www.bryght.com

Can you tell us more about brickslate? Bèr Kessels wrote:

Most of above, is what I do in whatinitsname theme. Which is the first step towards a theme engine I have in mind, called brickslate, where /everything/ is a block in a region. (bricks).

Bèr