Blocks and Regions rethink (concept needs feedback)
I'm aware we just hit code freeze so this is waaayyyy into the future, but I have a few itches that need to be scratched soon and want to garner feedback (concept needs feedback) on some ideas. I constantly use and abuse the ability to add regions nearly anywhere in drupal and find it incredibly useful. That said, The blocks admin section has a few highly infuriating ui issues. Namely. * You can only assign a block to one region at a time. * Current inability to 'clone' blocks. * Block admin is at block-admin not inline. I want to start work on some features that would first create a 'blocks available' and a 'Regions Using Blocks' interface at the block admin page - In this manner you could take one block and print it in two separate regions. e.g. printing a menu in the footer and the left sidebar, or printing "Who's online" block on the left sidebar on one page and the right on another. Second feature: Ability to edit blocks per page. This, I would imagine would take the form of a 'block edit' tab for properly permissioned users. Clicking it would take you to a block configuration page for that URL - you could then specify if you want to wildcard the url per each block (user/*), and set placement for each block. I would envision this as adding form elements for weight, url, roles, user visibility and region per block -or- a jQuery drag and drop feature (or one degrades to the other) Third feature: Cloning Blocks. When you want a block 'just like this module generates only different' - cloning it would generate the appropriate code in a custom block. This is much less important to me, just wnat to know if others find it useful. So, is this a worthwhile thing to investigate - what do people think? Thank you in advance for your feedback. --samtresler
Op zaterdag 07 juli 2007, schreef Sam Tresler:
I want to start work on some features that would first create a 'blocks available' and a 'Regions Using Blocks' interface at the block admin page - In this manner you could take one block and print it in two separate regions. e.g. printing a menu in the footer and the left sidebar, or printing "Who's online" block on the left sidebar on one page and the right on another.
Very usefull for core, indeed! However, if the itch is really itchy, you might want to look at microcontent. Microcontent is a node type that becomes a block. I have done a lot of work on it lately that will trickle into the main trunk soon, amongs others the ability to add a microcontent block to any amount of regions. It also features little 'minitabs', edit links that appear if you hover the block. the latest version uses degrading javascript to achieve this, as opposed to CSS that won't work in IE. For a client I will add the ability to assign views to a microcontent in the next week. With microcontent you never need the /admin/build/blocks interface. </plug> Bèr -- Drupal, Ruby on Rails and Joomla! development: webschuur.com | Drupal hosting: www.sympal.nl
Sam Tresler wrote:
I'm aware we just hit code freeze so this is waaayyyy into the future, but I have a few itches that need to be scratched soon and want to garner feedback (concept needs feedback) on some ideas.
I constantly use and abuse the ability to add regions nearly anywhere in drupal and find it incredibly useful.
That said, The blocks admin section has a few highly infuriating ui issues. Namely.
* You can only assign a block to one region at a time. * Current inability to 'clone' blocks. * Block admin is at block-admin not inline.
I want to start work on some features that would first create a 'blocks available' and a 'Regions Using Blocks' interface at the block admin page - In this manner you could take one block and print it in two separate regions. e.g. printing a menu in the footer and the left sidebar, or printing "Who's online" block on the left sidebar on one page and the right on another.
Second feature: Ability to edit blocks per page. This, I would imagine would take the form of a 'block edit' tab for properly permissioned users. Clicking it would take you to a block configuration page for that URL - you could then specify if you want to wildcard the url per each block (user/*), and set placement for each block. I would envision this as adding form elements for weight, url, roles, user visibility and region per block -or- a jQuery drag and drop feature (or one degrades to the other)
Third feature: Cloning Blocks. When you want a block 'just like this module generates only different' - cloning it would generate the appropriate code in a custom block. This is much less important to me, just wnat to know if others find it useful.
I'm looking very seriously at attempting to deprecate block.module in Drupal 7 and replace it with a verson of Panels 2. Panels 2 has or by then will have almost all of the abilities you've mentioned here, plus a lot more.
My (fairly simple, I think) desired improvement for Regions is to allow modules to declare them, e.g. hook_regions(), instead of just allowing the theme to declare them. For example, I'd like to have a "Node Regions" module that lets me declare a region "floated left at the beginning of the third paragraph of a node's body field"; any block could then be added to the region. I've actually already written the module but it requires manually editing the theme's template.php file. It should not have to. I should have submitted a hook_regions() patch for D6 but did not, so now I'm just trying to get my pet feature added to your rethink. :-) Thanks, Barry
Barry Jaspan wrote:
My (fairly simple, I think) desired improvement for Regions is to allow modules to declare them, e.g. hook_regions(), instead of just allowing the theme to declare them. For example, I'd like to have a "Node Regions" module that lets me declare a region "floated left at the beginning of the third paragraph of a node's body field"; any block could then be added to the region. I've actually already written the module but it requires manually editing the theme's template.php file. It should not have to.
I should have submitted a hook_regions() patch for D6 but did not, so now I'm just trying to get my pet feature added to your rethink. :-)
Thanks,
Barry
Barry, Sorry to be a downer, but that is perhaps the one thing that I wouldn't want in something like this. And I'm not certain why you would want it in a module-form, so maybe there is something I'm missing about what you are saying here. If we did anything like that it would need to generate CSS with it, and also need to be overridable. I can't imagine us hitting upon a default region design that would be even close to universally useful to people - if one region is floated left in your node-content -despite the design its in- every time you enable a module, well, that would get annoying quick - to always need to overrie it to kill the module specific region. Blocks are just content that can be themed, regions are very theme specific. We need to keep a solid separation of data and design in this. I guess what I'm proposing would be changing both the data stored (allowing blocks to be cloned and appear in multiple regions) and the input interface - but not really touching on any block's theme() calls.
Sam, I gave a perfectly useful example of a module-provided region: "just before the the Nth paragraph of the body of a node." Many sites want to place ads within body content, and such a region would allow them to do so. The module would not need to provide CSS, just insert the block at the specified location with a class and id tag. The site's style.css would then perform necessary themeing. Another example: "Just after the Nth result in a search or views result page." Again, this would be quite useful for ads. Another example: "In $node->content['my_custom_block'] with a #weight of N." This would show among all the other pieces of a node's content. Another example: "Absolutely positioned on the page at offset X,Y." This might be useful for setting a block as an overlay on top of certain pages. In this case, the module would need the provide its own CSS, but it could do so via the standard drupal_add_css() function. In short, regions are NOT just about themes. A region can be defined (or, rather, should be defineable) within any piece of content with a sufficiently predictable structure and for which a hook exists to allow it to be modified. Thanks, Barry At 11:06 AM 7/8/2007, Sam Tresler wrote:
Barry Jaspan wrote:
My (fairly simple, I think) desired improvement for Regions is to allow modules to declare them, e.g. hook_regions(), instead of just allowing the theme to declare them. For example, I'd like to have a "Node Regions" module that lets me declare a region "floated left at the beginning of the third paragraph of a node's body field"; any block could then be added to the region. I've actually already written the module but it requires manually editing the theme's template.php file. It should not have to. I should have submitted a hook_regions() patch for D6 but did not, so now I'm just trying to get my pet feature added to your rethink. :-) Thanks, Barry
Barry,
Sorry to be a downer, but that is perhaps the one thing that I wouldn't want in something like this. And I'm not certain why you would want it in a module-form, so maybe there is something I'm missing about what you are saying here.
If we did anything like that it would need to generate CSS with it, and also need to be overridable. I can't imagine us hitting upon a default region design that would be even close to universally useful to people - if one region is floated left in your node-content -despite the design its in- every time you enable a module, well, that would get annoying quick - to always need to overrie it to kill the module specific region.
Blocks are just content that can be themed, regions are very theme specific. We need to keep a solid separation of data and design in this.
I guess what I'm proposing would be changing both the data stored (allowing blocks to be cloned and appear in multiple regions) and the input interface - but not really touching on any block's theme() calls.
participants (4)
-
Barry Jaspan -
Bèr Kessels -
Earl Miles -
Sam Tresler