The region handling we introduced for 4.7 (and that I mostly wrote) is a step forward but produced confusion and instability in multi-theme sites. It's cumbersome to have to configure things like enabled status separately for each theme. As a 4.7 workaround I wrote a helper module, http://drupal.org/project/issues/blockregion. 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? If not, I'd like to consider the following approach: 1. Drop the ability for each theme to define more than the region of a block. 2. Pull the theme-block configuration into a separate table, e.g., block_theme, with fields module, delta, theme, region 3. Limit the UI configuration to region only for non-default themes. Is this needed/a good idea?
On 17 Aug 2006, at 21:41, Nedjo Rogers wrote:
1. Drop the ability for each theme to define more than the region of a block. 2. Pull the theme-block configuration into a separate table, e.g., block_theme, with fields module, delta, theme, region 3. Limit the UI configuration to region only for non-default themes.
I'm not sure I understand what you are proposing ... -- Dries Buytaert :: http://www.buytaert.net/
Dries Buytaert wrote:
On 17 Aug 2006, at 21:41, Nedjo Rogers wrote:
1. Drop the ability for each theme to define more than the region of a block. 2. Pull the theme-block configuration into a separate table, e.g., block_theme, with fields module, delta, theme, region 3. Limit the UI configuration to region only for non-default themes.
I'm not sure I understand what you are proposing ...
Same here. How about some visual mockups of UI changes? -- Neil Drumm http://delocalizedham.com/
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
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. 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 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
Neil Drumm pravi:
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.
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.
I found this so interesting that I took the right to play a bit and produced a patch which tries to implement suggestion #1. The rest is here: http://drupal.org/node/79571 -Tadej
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/
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
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?
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
On 22 Aug 2006, at 15:17, Bèr Kessels wrote:
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.
So ... what is the summary of this thread, and the required/agreed action points in particular? Do we need to change something? (Interesting question, huh. Time to get this discussion back on track, and to turn it into something concrete.) -- Dries Buytaert :: http://www.buytaert.net/
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
On 17 Aug 2006, at 21:41, Nedjo Rogers wrote:
The region handling we introduced for 4.7 (and that I mostly wrote) is a step forward but produced confusion and instability in multi- theme sites. It's cumbersome to have to configure things like enabled status separately for each theme. As a 4.7 workaround I wrote a helper module, http://drupal.org/project/issues/blockregion.
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: 1. My perception of the world is wrong. People are in fact heavily using block regions. 2. Users asked for the wrong functionality, or developers delivered the wrong functionality (they didn't listen to the users). Maybe the users need something else: think panels.module or section.module, for example. The panel and section module appear to be fairly popular; maybe we need to pull in some more ideas from them, maybe we should adopt common terminology or interface elements. 3. The block region feature does match people's expectations/need but is simply too hard to use. This could be due to a number of things: (i) poor UI design, (ii) poor documentation, (iii) lack of examples, etc. I think it is a combination of (2) and (3): sweeping changes are required to bring block regions onto the map. Neil's suggestions would make for interesting starting points, IMO. -- Dries Buytaert :: http://www.buytaert.net/
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
Morbus Iff 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)
I use it in nearly every site I do now
*aol* What I still do not use is the "multiple themes" feature, though. Cheers, Gerhard
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
I doubt it is 1), nor do I think 2) is very likely, though I lack any proof for that. Op vrijdag 18 augustus 2006 08:47, schreef Dries Buytaert:
3. The block region feature does match people's expectations/need but is simply too hard to use. This could be due to a number of things: (i) poor UI design, (ii) poor documentation, (iii) lack of examples, etc.
Recently I started a new base theme, which I already used on two sites sucessfully. I think a third site will prove it to be release ready, and I'll give it a 4.7 brach. The whole idea is: LOADS of regions. That theme has already 7 regions. Regions that are not called "top", "left" or "right", but have proper semantic names such as "tools", "branding" etc. I really hope this is a start for a second generation of (CSS) themes that break out of the threecol HTML, and get us into the era of semantic 3col layouts (the difference is only semantic)[1]. For proper semantics one needs loads of regions. * examples: Indeed there are hardly any. Only examples how to build complex homepages. Let us get some good ones out there! themes.drupal.org suffers from the "bug" in core that only themes with left and right regions can be presented there in the first place. Anyone whom is creative and added a "post content region" but no left or right, can not present its theme there. This needs a solution, though I don't know any. * poor UI design: I doubt it. We have much poorer designed features. If people need it, theyll get around usability thingies. * documentation: again, the only i can find is how to make nicer frontpages. This is in fact more an abuse of regions then a proper use! :) Does anyone have anything working? I want to finish up my docs[2] on using regions and nicer HTML in the next weeks, but have been overwhelmed (again). Maybe we can list more complete and other manuals? Bèr [1] http://www.stuffandnonsense.co.uk/archives/whats_in_a_name_pt2.html [2] http://webschuur.com/node/635
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.
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.
In 4.8/5.0, this is no longer a problem, either. You can have per-region, per-module, and per-module-delta block templates. --Jeff
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
Op vrijdag 18 augustus 2006 08:47, schreef Dries Buytaert:
(iii) lack of examples
I just thought that core is very guilty here too. 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) We could take it to extremes, but I fear that will lead to a discussion that will slow down actual implementation. Main. Content. As a block. In a "content" region. But lets forget about that special one, for reasons mentioned above :). 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
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
Op zaterdag 19 augustus 2006 21:30, schreef Johan Forngren:
Can you tell us more about brickslate? I love talking :)
Here are some resources: * http://webschuur.com/node/479 «Brickslate: Moving phptemplate a step closer to perfection» * http://groups.drupal.org/node/184 incrowd details. * http://groups.drupal.org/node/928 some links and thoughts about that new base theme * http://webschuur.com/node/635 the whatsinitsname -in-progress- theme manual. A thing I realised too late and that is not documented, is where I got the idea: building a page with brickslate is like building a /DOM/. Rather then the common way: glue some strings together. The way brickslate should let you build a page, is exactly like how you build DOM stuff with javascript. (And how Ruby on Rails can build an XML DOM, but this very fact makes some Drupal people dislike the idea in the first place.). Bèr
participants (13)
-
Boris Mann -
Bèr Kessels -
Dries Buytaert -
Evan Leeson -
Gerhard Killesreiter -
Jeff Eaton -
Johan Forngren -
johan@forngren.com -
Khalid B -
Morbus Iff -
Nedjo Rogers -
Neil Drumm -
Tadej Baša