Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Basic mockup of Neil's suggestion of region-driven block placement UI. Please read this thread on the development mailinglist.
While the enabled/disabled, and throttle status of a module remain a site-wide setting, one can now place a block into multiple regions for every enabled theme and set different visibility settings for each instance of a block. (e.g. display the Navigation block in the left column on the first page, but in the right column on every other page).
Comment | File | Size | Author |
---|---|---|---|
#26 | block-admin-ui-proto.png | 65.43 KB | dropcube |
#10 | screenshot.png.png | 56.15 KB | drumm |
#9 | block_placement2.jpg | 103.77 KB | paranojik |
#8 | block_placement1.png | 29.29 KB | paranojik |
#7 | blocks.png | 45.24 KB | paranojik |
Comments
Comment #1
chx CreditAttribution: chx commentedTo give credit where it's due: it was Nedjo Rogers who suggested this, even your link points to his writeup.
Comment #2
Dries CreditAttribution: Dries commentedPatch no longer applies?
Comment #3
paranojik CreditAttribution: paranojik commented@chx: Yes, Nedjo was the one who started that threat, but I was reffering to Neil's reply where he explicitly suggested the relevant changes (also read at the end of Dries's reply) . I'm not trying to discredit Nedjo. As you noticed, I linked to his post, didn't I?
@Dries: I'll reaply soon.
Comment #4
paranojik CreditAttribution: paranojik commentedReapplied...
Comment #5
paranojik CreditAttribution: paranojik commentedComment #6
drummThe indentation generally needs to be cleaned up. Here is an example of a correctly formatted array from the patch:
All new and changed code should look like this (no need to reformat any otherwise untouched code). I noticed an if statment without braces too; we want those on all blocks of code. In the SQL, 'INT(10)' should be 'int'.
The menu items are weird. We prefer to use 'path/to/item/{id}/operation' instead of 'path/to/item/operation/{id}'.
Can you post some screenshots of the UI changes?
I think this probably should be two patches, one for the database and other backend and another for the UI and other frontend, but that might not be practical.
Comment #7
paranojik CreditAttribution: paranojik commentedThanks for reviewing. Here are the screenshots. If you think this is worth pursuing, I'll continue working on this patch.
Comment #8
paranojik CreditAttribution: paranojik commentedThe first screenshot (blocks.png) shows the enabled/disabled blocks page. Clicking the "configure" button enables you to configure general block settings.
On the seccond screenshot you can see the new "block placement" page. On the top, you select which block (using the dropdown, that only shows enabled blocks) you wish to place in which region. Clicking "Place block" ... see next screenshot.
Comment #9
paranojik CreditAttribution: paranojik commented... places a new instance of the block into the desired region. The "configure" button enables you to configure instance-specific visibility settings (for which roles and on which pages you want the block to show). The "remove" button removes the instance.
(I'm well aware that the UI is bad.)
Comment #10
drummI'm a bit confused by the UI. Attached is what I was thinking of. The page would stay as one page, with the same configure links for specific block instances.
Comment #11
RobRoy CreditAttribution: RobRoy commentedThis would be sweet for 6.x-dev.
Comment #12
Wim LeersWould this still be allowed in Drupal 6? It wouldn't imply API changes, I think.
Usability would definitely benefit, the current block administration becomes a pain if you have 20+ blocks.
Comment #13
drummSome simple changes could be made without API changes.
For example, the list of all disabled blocks isn't too useful since most of the time it does nothing. A better use of space would be to have a single line for each block region to add a block. This could either be a dropdown list or a separate page and should be organized by module and alphabetically.
The larger change requires some database rekeying and won't happen in 6.x.
Comment #14
catchDon't think this will get in past beta.
Comment #15
aries CreditAttribution: aries commentedI'd like to see this feature soon
Comment #16
NaX CreditAttribution: NaX commented+1
I often require placing of blocks in more than one region. Most recently I needed a block to appear in one region on taxonomy listings and in a different region on node pages. The only practical workaround I found is to duplicate the block. Putting even more strain on block administration.
I think this should be a priority. This proposal addresses usability and flexibility problems. Is there any other patches floating around that could be related to this issue?
Comment #17
perandre CreditAttribution: perandre commentedGreat work, looking forward to this functionality!
Comment #18
moshe weitzman CreditAttribution: moshe weitzman commentedI think we improved block admin in d6 so this is not needed. If folks disagree, please restate the issue considering current drag and drop ui.
Comment #19
moshe weitzman CreditAttribution: moshe weitzman commentedWoops. This is about blocks in multiple regions which we do not yet support. Re-opening.
Comment #20
dropcube CreditAttribution: dropcube commentedTo support this, we will require changes to the underlying database schema, with the introduction of the 'block instance' concept. See patch #72 at #257032: Split block $ops into separate functions.
Comment #21
Gábor HojtsyYup, I am dying for this on drupal.hu at this point. I'd put a block into three different regions depending on what page is being viewed.
Comment #22
Jax CreditAttribution: Jax commentedsubscribing
Comment #23
catchsubscribing, this is a major shortcoming of the blocks system (not that there aren't others, but it's one of them).
Comment #24
moshe weitzman CreditAttribution: moshe weitzman commentedFYI, it is trivial for code to copy a block into more regions using hook_page_alter().
Comment #25
Brigadier CreditAttribution: Brigadier commentedsubscribing
Comment #26
dropcube CreditAttribution: dropcube commentedAttached a quick prototype of a possible Block Admin page to allow blocks to appear in multiple regions.
There are blocks and block instances. Blocks are simply module provided blocks or user created custom blocks.
The main area of the page lists all available blocks. First user created custom blocks and then system provided blocks.
Drag-and-drop can be used to create new block instances, by dropping them in a the region area. New instances can be added using the link in the region as well.
Ideally, each block instance should have it's own settings, and use block default settings if they are not overridden by the instance.
Of course, all this will require a lot of work and a revamp of the underlying database structure.
Comment #27
amc CreditAttribution: amc commentedTagging.
Comment #28
ñull CreditAttribution: ñull commented+ subcribing
Comment #29
catchComment #30
sunThis should have been a critical feature for D7 already. Blocks need to be able to be re-used for Dashboard. Thus, absolutely critical for D8.
Comment #31
fourmi4x CreditAttribution: fourmi4x commentedsuscribing
Comment #32
Anonymous (not verified) CreditAttribution: Anonymous commentedsubscribing
Comment #33
greg.harveyInteresting, shame this didn't make D7. I'm currently using Panels to achieve this really.
Comment #34
yoroy CreditAttribution: yoroy commentedhello
Comment #35
catchDowngrading all D8 criticals to major per http://drupal.org/node/45111
Comment #36
claar CreditAttribution: claar commentedSubscribe. For those looking for a workaround, see the MultiBlock module.
Comment #37
leguy CreditAttribution: leguy commentedsubscribe
Comment #38
indytechcook CreditAttribution: indytechcook commentedOld issue is old.
I believe this issue is covered in #430886: Make all blocks fieldable entities for custom blocks.
For "system blocks" once I finally show convince people that all blocks should be entities then it will be solved #1164718: Improving the usability between "custom block" and "content"
Also see the http://drupal.org/project/bean and http://drupal.org/project/block_api modules.