Updated: Comment #0

Problem/Motivation

In #2055853: [meta] Improve the place block UX; Separate interaction from the create block UX; Improve the existing blocks-by-theme layout it was determined that the current path structure was confusing.

Proposed resolution

Move the custom block pages below the block UI, instead of next to it

Remaining tasks

N/A

User interface changes

The custom block pages move, and the per-theme tabs are now secondary instead of primary

API changes

N/A

#2055853: [meta] Improve the place block UX; Separate interaction from the create block UX; Improve the existing blocks-by-theme layout
#1926294: Write tour integration for custom_block.module
#2078635: Add an 'Add custom block type' local action to the 'Custom block library' Postponed on this

Files: 
CommentFileSizeAuthor
#17 bl1.jpg160.68 KBdcrocks
#17 bl2.jpg146.62 KBdcrocks
#9 block-2078341-9.patch18.83 KBtim.plunkett
PASSED: [[SimpleTest]]: [MySQL] 58,647 pass(es).
[ View ]
#9 interdiff.txt769 bytestim.plunkett
#4 Screen Shot 2013-08-31 at 1.21.05 PM.png120.75 KBtim.plunkett
#4 Screen Shot 2013-08-31 at 1.21.11 PM.png103.63 KBtim.plunkett
#4 block-2078341-4.patch18.67 KBtim.plunkett
FAILED: [[SimpleTest]]: [MySQL] 58,470 pass(es), 1 fail(s), and 0 exception(s).
[ View ]
#4 interdiff.txt2.38 KBtim.plunkett
#1 block-2078341-1.patch17.86 KBtim.plunkett
FAILED: [[SimpleTest]]: [MySQL] 58,357 pass(es), 10 fail(s), and 8 exception(s).
[ View ]

Comments

Status:Active» Needs review
Issue tags:+Block UI overhaul
StatusFileSize
new17.86 KB
FAILED: [[SimpleTest]]: [MySQL] 58,357 pass(es), 10 fail(s), and 8 exception(s).
[ View ]

First pass.

Status:Needs review» Needs work

The last submitted patch, block-2078341-1.patch, failed testing.

Does this mean it becomes a tab? How do you access this outside of the vertical menu?

Status:Needs work» Needs review
StatusFileSize
new2.38 KB
new18.67 KB
FAILED: [[SimpleTest]]: [MySQL] 58,470 pass(es), 1 fail(s), and 0 exception(s).
[ View ]
new103.63 KB
new120.75 KB

Here is the regular blocks page, now called "Block layout". The difference between 7 and 8 is that the theme-specific tabs are now secondary tabs.
Screen Shot 2013-08-31 at 1.21.05 PM.png

Here is the custom blocks page, which has a default secondary tab for the custom blocks, and the other secondary tab is the custom block types:
Screen Shot 2013-08-31 at 1.21.11 PM.png

If we do not make "Custom block library" a local task, then the only way to get there will be through the vertically expanded toolbar.

Every other instance of a page being a subpage of a listing is a local task. Think of the Comments page (admin/content/comments) under the Content page (admin/content) or the Views settings (admin/structure/views/settings) under the Views listing (admin/structure/views).

Unless we choose to just keep the page title changes and nix the entire restructuring, we're pretty much forced to use local tasks like this (and for the record, I think this is an improvement).

Status:Needs review» Needs work

The last submitted patch, block-2078341-4.patch, failed testing.

I could support this if we also got an 'Add custom block type' local action on the 'custom block library' tab (can be follow up).
Without that I think discoverability of the fact that block types exist and are fieldable is lost.
This is a new; and in my-opinion kick-ass feature of Drupal 8 that we're effectively burying as deep as the 'roles' tab or the 'user profile fields' tab in Drupal 7. And we deliberately hid the 'user profile fields' tab as deep as possible.
I think this also makes #1926294: Write tour integration for custom_block.module more important

Issue summary:View changes

Updated issue summary.

Status:Needs work» Needs review
StatusFileSize
new769 bytes
new18.83 KB
PASSED: [[SimpleTest]]: [MySQL] 58,647 pass(es).
[ View ]

Yes. This does happen to terribly inconvenience custom block types. I think a new local action would be great.

Obviously we can't have an IA that is only accessible through the vertical menu. So that sounds fine to me, too. The labeling/descriptions for the custom block library worries me a little, but that can probably be a separate issue.

The patch worked on simplytest.me, so from a pure visual pov this seems RTBC

#9: block-2078341-9.patch queued for re-testing.

Assigned:Unassigned» tim.plunkett

Helps me keep track

Status:Needs review» Reviewed & tested by the community

The code looks good as well. So adding this up with Bojhan's visual RTBC from #10, looks like good to go. I'm not sure about adding an "Add custom block type" local action on a page that does not deal with types, that sounds like an antipattern to me, but as people said above can/should be a followup to let this happen sooner.

Status:Reviewed & tested by the community» Fixed

Committed to 8.x. Thanks.

This UI is not working for me on Firefox 23.1 on OS X 10.6. Went to simplytest.me and did standard install of Core. The placement window is partially hidden by the toolbar. See attached. If I turn off Overlay, then the placement window is on top of the toolbar. Running on localhost, the placement window doesn't open at all.

StatusFileSize
new146.62 KB
new160.68 KB

Sorry, here are images.

@dcrocks: this patch did not introduce dialogs for such pages, this issue merely reorganized tabs. So not sure doing anything with this issue would help with your problem. (I *think* dialog displacement with the toolbar should work).

OK, I checked on an older install, before this was committed, and it failed then as well. I need to find out when this broke.

I need to find out when this broke.

Why?

#2058321: Move the 'place block' UI into the block listing added the usage of the modal, but it did not make the modal broken. The modal has always been broken.

Because I can't place a block if I can't access the form properly, unless I turn off features like overlay and/or toolbar. Is there a follow up to #2058321: Move the 'place block' UI into the block listing.

You can, for now, use your browser to open the link in a new tab, bypassing the modal. I was pretty sure there was a bug report for the modal not scrolling/resizing, but I can't find it. Feel free to open it, and link it here.

Overlay does not participate in displaying the modal that you posted. Also overlay does support toolbar displacement, so as you place the toolbar in different orientations, it will adjust size. #2067263: Drupal dialog placement must take displacing viewport elements, like the Toolbar, into account when calculating placement is the issue you are looking for.

Thanx, I'll move over there.

Assigned:tim.plunkett» Unassigned

Automatically closed -- issue fixed for 2 weeks with no activity.

Issue summary:View changes

Updated issue summary.