Posted by paranojik on August 19, 2006 at 9:50pm
| Project: | Drupal core |
| Version: | 8.x-dev |
| Component: | block.module |
| Category: | feature request |
| Priority: | major |
| Assigned: | Unassigned |
| Status: | closed (duplicate) |
| Issue tags: | ui-pattern, Usability |
Issue Summary
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).
| Attachment | Size | Status | Test result | Operations |
|---|---|---|---|---|
| blocks-regions.patch | 33.67 KB | Ignored: Check issue status. | None | None |
Comments
#1
To give credit where it's due: it was Nedjo Rogers who suggested this, even your link points to his writeup.
#2
Patch no longer applies?
#3
@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.
#4
Reapplied...
#5
#6
The indentation generally needs to be cleaned up. Here is an example of a correctly formatted array from the patch:
<?php$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.
#7
Thanks for reviewing. Here are the screenshots. If you think this is worth pursuing, I'll continue working on this patch.
#8
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.
#9
... 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.)
#10
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.
#11
This would be sweet for 6.x-dev.
#12
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.
#13
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.
#14
Don't think this will get in past beta.
#15
I'd like to see this feature soon
#16
+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?
#17
Great work, looking forward to this functionality!
#18
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.
#19
Woops. This is about blocks in multiple regions which we do not yet support. Re-opening.
#20
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.
#21
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.
#22
subscribing
#23
subscribing, this is a major shortcoming of the blocks system (not that there aren't others, but it's one of them).
#24
FYI, it is trivial for code to copy a block into more regions using hook_page_alter().
#25
subscribing
#26
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.
#27
Tagging.
#28
+ subcribing
#29
#30
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.
#31
suscribing
#32
subscribing
#33
Interesting, shame this didn't make D7. I'm currently using Panels to achieve this really.
#34
hello
#35
Downgrading all D8 criticals to major per http://drupal.org/node/45111
#36
Subscribe. For those looking for a workaround, see the MultiBlock module.
#37
subscribe
#38
Old issue is old.
I believe this issue is covered in #430886: Make blocks 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: The distinction between "custom block" and "content" is non-sensical
Also see the http://drupal.org/project/bean and http://drupal.org/project/block_api modules.