Problem/Motivation

We should be able to place menu blocks from the menu page. This is a half thought-out idea. It is barely a proof-of-concept. More explanation and code to come later.

Proposed resolution

The proposed patch in #11

Remaining tasks

Reroll the patch and test.

User interface changes

The menu page would be changed.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

tim.plunkett’s picture

FileSize
1.73 KB

No point in testing yet.

tim.plunkett’s picture

+++ b/core/modules/menu/menu.module
@@ -121,6 +122,37 @@ function menu_menu() {
+    // @todo Do not force the default theme when the block form has a theme
+    //   selector.

#2083877: Add a theme selector to the place block form

tim.plunkett’s picture

tim.plunkett’s picture

Okay, here's an action link. It triggers the modal added in #2083877: Add a theme selector to the place block form and then keeps you on the menu page.
Screen Shot 2013-09-09 at 9.38.01 PM.png

Attached a patch with just this issue, and one combined.

tim.plunkett’s picture

FileSize
3.3 KB

Okay, both blockers went in!

xjm’s picture

Issue tags: +Needs usability review

Nice! Patch code looks fine, but maybe the test should also confirm the block is actually placed in the expected region?

I tested manually and it seems to work as intended. Couple comments on the UX:

  1. (out of scope) Do we have an issue somewhere for the thing where overlay redirects, reloads the page, and eats your dsm? because that's seriously disorienting.
  2. Did we decide elsewhere that this should specifically be a local action instead of as a dropbutton operation on admin/structure/menu? I vaguely remember discussing this but not sure with who or what the decision might have been.
  3. Does it make sense for "+ Place block" to come before "+ Add link"?
  4. Are "+ Place block" and "+ Add link" the same kind of thing?
  5. Can we add descriptions to those buttons to explain what their purpose is? I'm not sure that the place block one is clear or if that's something we do for actions.
  6. (out of scope) We should add a tour that explains this page, including the new button.
  7. (partly in scope) admin/structure/menu/manage/admin needs hook_help(). That could give us a chance to explain about placing the block.
  8. The message after I place my block is:

    The block configuration has been saved.

    That doesn't give me any clue as to what I just did. It would be MUCH better to say something like "Block placed in Bartik Highlighted region" or something, possibly followed by <a href="admin/structure/block/whatever">Administer blocks for Bartik</a>.

tim.plunkett’s picture

confirm the block is actually placed in the expected region

We added explicit tests for that in #2083877: Add a theme selector to the place block form, which is the modal we're just repurposing.

1) Not that I know of. I don't really touch overlay...
2) I made this decision myself, because having the dropbutton operation trigger a modal seemed very odd to me
3) I have no idea if these support weights, but yes.
4) "+ Add link" is the menu_link add form. So, no.
5) Um, no idea how to add descriptions to local actions. Probably should be hook_help()
6) Would be cool!
7) Yep, sounds good.
8) That's exacerbated by this workflow, yes. Could be done separately, or here, doesn't matter to me.

Leaving at NR for usability input on 6.2, local action vs dropbutton

tim.plunkett’s picture

Okay, this addresses 6.3, 6.7, and 6.8
Screen Shot 2013-09-10 at 2.59.31 PM.png

Screen Shot 2013-09-10 at 2.59.43 PM.png

Bojhan’s picture

I will review this later today. Sorry, for the backlog on this tag.

xjm’s picture

Cool, the specific status message helps a lot.

+++ b/core/modules/menu/menu.module
@@ -43,8 +43,14 @@ function menu_help($path, $arg) {
+      $output .= '<p>' . t('On this page you can rename the menu and reorder or edit existing menu links. In addition, links are provided to add a new menu link, or place a block for this menu in any theme.') . '</p>';

@Bojhan, helping polish this help text would help for sure. :)

tim.plunkett’s picture

FileSize
12.81 KB

s/drupalPost/drupalPostForm

tim.plunkett’s picture

Assigned: tim.plunkett » Unassigned

Unassigning to help keep track of what is blocked on me.

jibran’s picture

+++ b/core/modules/menu/menu.module
@@ -121,6 +128,33 @@ function menu_menu() {
+    // @todo Move to a LocalAction plugin when https://drupal.org/node/2045267

Issue link is updated to https://drupal.org/node/2076283

Bojhan’s picture

So I am looking at it, but can I have a little bit more background - on the why?

jessebeach’s picture

Kevin would like to create soft-associations between placeable things (menus, aggregation entities, views) and layout. The idea is, AFAIU, if you create something, like a menu, you probably want to use it as well. So we provide a short-circuit path to put that new thing into active use.

Bojhan’s picture

This is a bit of a short review, I will do a longer one tomorrow - sadly I am running out of time today. I am surprised at how ugly our menu page edit screen has gotten with the merge of edit and list of links. So I am all for this concept, we have actually advocated for this several times in the past as usability testing showed this was needed. Its all about connecting the dots.

Onto the actual UI:

  • It is at the right place, this is where one would see the need to add a block. I'd honestly love this ability on block creation too.
  • Having more than one action button is a little suboptimal, its hard to move outside this paradigm (I have some ideas for this, but this needs a bit of design exploration).
  • There is no way, we can ever have two action buttons that are right next to each other spawn two different patterns (one a full page, the other a modal dialog).
  • I am missing some kind of overview, where can I learn in what theme and region this menu is placed as a block (I feel like we need a standardized design for this element, if we are to place it everywhere). This is an essential "connecting the dots" if you want to bring a UI like this to the menu page.

The text could indeed use some work, looking at it now - I wouldn't even bother with it. We don't need text, all its doing now is telling you to go to Blocks administration, thats not needed anymore - and we don't really need to explain the UI. If we need to explain the UI, we have a #Fail UI. In general I feel like this just needs a bit more design, probably not what you wanted to hear - but it will save us a lot of time in the long run when we transfer this to other concepts and user test this.

Bojhan’s picture

Actually can we not just have a theme + region selector? Or is that not possible because of all the instance stuff?

tim.plunkett’s picture

We cannot allow blocks to be placed without presenting the whole form, since we don't know what required fields might be needed by the block plugin, or a hook_form_alter

yoroy’s picture

I wonder if it's useful to keep referring to a menu as a block. I.e. the action says 'Place block'. Would it be more clearer if this read 'Place menu'? Same with the messages: I'm working on a menu here, but it's being referred to as a block.

Agreed with Bojhan that the page help text can be removed alltogether.

Re. 17 & 18: when do those potentially required fields get checked? Maybe it could be a 2-step process where we do have only a theme + region selection, on submit it either is ok or we ask for more configuration as per any required field that needs it.

Where do I make suggestions for the 'place block' form itself? It's a bit messy :)

klonos’s picture

@yoroy, regarding the rename to 'Place menu': great idea, here's an issue (credits to you) for it so that it doesn't get lost: #2100643: Replace the 'Place block' page title with either 'Place menu' or 'Place menu block'.

klonos’s picture

jhedstrom’s picture

Status: Needs review » Needs work
Issue tags: +Needs reroll
areke’s picture

Issue summary: View changes
Nitesh Sethia’s picture

Issue summary: View changes
Status: Needs work » Needs review
Issue tags: -Needs reroll +#drupalgoa2015
FileSize
160.96 KB

Rerolled the patch.

Status: Needs review » Needs work

The last submitted patch, 24: allow_menu_blocks_to_be-2083871-24.patch, failed testing.

jhedstrom’s picture

Version: 8.0.x-dev » 8.1.x-dev
Category: Task » Feature request
Status: Needs work » Postponed

This seems like a feature request at this point in time.

Bojhan’s picture

Issue tags: -Needs usability review

I think my review still applies.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.0-beta1 was released on March 2, 2016, which means new developments and disruptive changes should now be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.