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

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

chx’s picture

To give credit where it's due: it was Nedjo Rogers who suggested this, even your link points to his writeup.

Dries’s picture

Status: Needs review » Needs work

Patch no longer applies?

paranojik’s picture

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

paranojik’s picture

FileSize
36.97 KB

Reapplied...

paranojik’s picture

Status: Needs work » Needs review
drumm’s picture

Status: Needs review » Needs work

The indentation generally needs to be cleaned up. Here is an example of a correctly formatted array from the patch:

$form['new_block']['block_id'] = array(
  '#type' => 'select',
  '#options' => $options,
  '#description' => t('Place a new block in the selected region.'),
);

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.

paranojik’s picture

FileSize
45.24 KB

Thanks for reviewing. Here are the screenshots. If you think this is worth pursuing, I'll continue working on this patch.

paranojik’s picture

FileSize
29.29 KB

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

paranojik’s picture

FileSize
103.77 KB

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

drumm’s picture

FileSize
56.15 KB

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

RobRoy’s picture

Version: x.y.z » 6.x-dev
Category: task » feature

This would be sweet for 6.x-dev.

Wim Leers’s picture

Title: Allow block to appear in multiple regions » Allow blocks to appear in multiple regions

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

drumm’s picture

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

catch’s picture

Version: 6.x-dev » 7.x-dev

Don't think this will get in past beta.

aries’s picture

I'd like to see this feature soon

NaX’s picture

+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?

perandre’s picture

Great work, looking forward to this functionality!

moshe weitzman’s picture

Status: Needs work » Closed (works as designed)

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

moshe weitzman’s picture

Status: Closed (works as designed) » Needs work

Woops. This is about blocks in multiple regions which we do not yet support. Re-opening.

dropcube’s picture

Category: feature » task

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

Gábor Hojtsy’s picture

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

Jax’s picture

subscribing

catch’s picture

subscribing, this is a major shortcoming of the blocks system (not that there aren't others, but it's one of them).

moshe weitzman’s picture

FYI, it is trivial for code to copy a block into more regions using hook_page_alter().

Brigadier’s picture

subscribing

dropcube’s picture

FileSize
65.43 KB

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

amc’s picture

Issue tags: +block

Tagging.

ñull’s picture

+ subcribing

catch’s picture

Version: 7.x-dev » 8.x-dev
sun’s picture

Assigned: paranojik » Unassigned
Category: task » feature
Priority: Normal » Critical
Issue tags: -block

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

fourmi4x’s picture

suscribing

Anonymous’s picture

subscribing

greg.harvey’s picture

Interesting, shame this didn't make D7. I'm currently using Panels to achieve this really.

yoroy’s picture

Issue tags: +Usability, +ui-pattern

hello

catch’s picture

Priority: Critical » Major

Downgrading all D8 criticals to major per http://drupal.org/node/45111

claar’s picture

Subscribe. For those looking for a workaround, see the MultiBlock module.

leguy’s picture

subscribe

indytechcook’s picture

Status: Needs work » Closed (duplicate)

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