Problem
We now have the ability for users to add blocks from the frontend with #2724819: Create experimental module for place block on any page feature, but there is no way to position the blocks.
When the user toggles on "place blocks" clicks a "place block" button in a region, then chooses a block to place, the next form presented is the block configuration form. This form contains visibility settings including region (automatically set to the region where the user clicked "place block") but there is nowhere to set the weight. Without drag-drop or any other way to set the weight the user who wanted the block anywhere besides at it's default position would need to:
- Know where to go to change weights
- Navigate to "Admin/Structure"
- Navigate to "Admin/Structure/Block-Layout
- Scroll to the block they just placed
- Drag the block to the desired position (or set it's weight)
- Scroll to the bottom of the page
- Click save
- Click "back to site"
At this point the whole "in place" aspect of placing blocks is rendered pretty much moot because I had to go to block layout anyway so why not just do the whole thing from there?
Proposed solution
After the user has placed a block and submitted the configuration form, load another modal showing the blocks in the region and allow the user to position it using table-drag.
Comment | File | Size | Author |
---|---|---|---|
#28 | 2735277-28-Let-users-set-the-weight-of-blocks.patch | 2.91 KB | SKAUGHT |
#5 | 2735277-block-5.patch | 762 bytes | tim.plunkett |
Comments
Comment #2
tkoleary CreditAttribution: tkoleary at Acquia commentedComment #3
tkoleary CreditAttribution: tkoleary at Acquia commentedComment #4
tkoleary CreditAttribution: tkoleary at Acquia commentedComment #5
tim.plunkettAFAICS, this will be the first time we expose weight outside of the context of a tabledrag. This seems problematic.
This is fully functioning (don't let the lack of submit changes fool you). This just needs tests.
Comment #6
tkoleary CreditAttribution: tkoleary at Acquia commented@Tim Plunkett
Patch works great!
One question, how is the number of available weights in the select determined? It looks like it's being calculated from the number of existing blocks, if so that's cool, but if it's the case that we can transform the weights as displayed to the user removing negatives would make the UI much simpler.
My suggested description was in the summary, but given the above it could be simpler:
"Low number blocks* are positioned before high number blocks. *Including negative numbers."
Or if we take out negatives
"Low number blocks are positioned before high number blocks."
Also we need to remind the user that region and weight only apply to the instance in the current theme. I'm thinking wrap them in a fieldset labeled:
Block position for theme: Bartik.
Because there's no guarantee that the region will be present in another theme.
Comment #7
tkoleary CreditAttribution: tkoleary at Acquia commented@timplunkett
Messing around testing the patch some more it occurred to me that there might be some confusion about how to get a block "higher" in the order.
Right now if I have a block "foo" with a weight -8 and I have another block "bar" below it with a weight of -7, My options only include -8, not -9. This leads me to conclude that I can't place a "bar" above "foo" until I actually give block "foo" a weight of -8, save and notice that now the weights have been recalculated and "bar" has a weight of -7.
This is very counterintuitive but could be solved easily by always providing an option of one weight between and outside every actual block weight. So instead of:
Block foo: weight = -3
Block bar: weight = -2
Block baz: weight = -1
If we had:
Block foo: weight = -5
Block bar: weight = -3
Block baz: weight = -1
We could show the user the options: -6, -5, -4, -3, -2, -1, 0, and there would be no ambiguity about whether you were placing the block above or below another block because you would always be moving the block to one of the "blank" weights (-6,-4,-2, 0).
Comment #9
stefanos.petrakis@gmail.comThings seem to be a bit different than what the OP described, reviewing this on the latest 8.3.x-dev version.
At the moment, after finalizing the configuration of a newly added block (custom or existing) and clicking on save,
the user is redirected to the Block/Regions overview page, and the page auto-scrolls to - and auto-highlights - the newly added block. In that way, the user can continue uninterrupted with dragging the newly added block at the desired place.
I would say this behaviour is already a lot closer to the "in-place" editing spirit and should not require such a radical change as suggested. So, unless I am missing the point of the OP, I would say this is not an issue. Setting this to "Cannot reproduce".
Comment #10
tkoleary CreditAttribution: tkoleary at Acquia commented@stefanos.petrakis
This issue is predicated on the user placing a block from the front-end using the 'place block" toggle. At the end of that process the user is not redirected to the block layout page (and if they are they shouldn't be) but back page on the front end where they started.
Comment #11
stefanos.petrakis@gmail.com@tkoleary: You are right, my bad.
Comment #12
tkoleary CreditAttribution: tkoleary at Acquia commentedComment #13
tkoleary CreditAttribution: tkoleary at Acquia commentedComment #14
tkoleary CreditAttribution: tkoleary at Acquia commentedAfter more discussion about this with others I think we can slightly alter the scope of this so that it is not dependent on settings tray but enables the user to table-drag the blocks in a modal.
Updating summary.
Comment #15
tim.plunkettNot actively part of the Layout Initiative
Comment #16
tkoleary CreditAttribution: tkoleary at Acquia commentedGiven changes to the issue summary post discussion on this in UX meetings the patch at #5 is out of date.
The current state of the flow in the module is:
All this patch needs to do is change #4 to:
4. User configures the block and clicks 'save" and the block layout form appears (still in modal)
And add #5:
5. User clicks 'save blocks' the modal closes and the block is visible on the page.
With this flow it will be possible for the Settings tray module to present the modals in the tray.
Comment #18
tedbowI think this might be duplicate of #2784495: Normalize block place and outside-in experiences
Don't have time to check right now but it allows sorting blocks after place.
Comment #19
nerdstein@tedbow, my sense is that the aim of this issue, 2791305 and motivations found in 2739075 ensures Place Block works agnostically from Outside In. 2784495 seems to emphasize Outside In integration, which will likely need to be revisited after 2791305, 2791305 or both get merged. My sense is that it is not a duplicate, but something that should be evaluated shortly.
Comment #20
nerdsteinFor visibility, I'm trying to determine how this issue relates to https://www.drupal.org/node/2791305, which seems to have a similar motivation.
Comment #21
SKAUGHTrebuilt #5. enhance form UX with detail wrapper. some actual Weight description text. removed old hidden weight field (duplicate form field)
Comment #23
SKAUGHThave realized this doesn't save correctly. needs work.
Comment #24
SKAUGHTalthough form has #tree=>true it seems the getValue won't get nested elements. added step in validateForm to bring values down.
Comment #26
SKAUGHTremade and renamed patch. ??hash in name
Comment #28
SKAUGHT..i see. removed details wrapper - breaks too much. fixed array syntax. moved above visibility settings (form elements under vertical tab, looks strange) and as tab isn't shown on settings tray it's just as well.
Comment #29
Bojhan CreditAttribution: Bojhan commentedCan you make sure to mark this "Needs usability review" when the UI is reviewable?
Comment #30
nerdsteinI've tested this with the following observations:
1. Logged in
2. Clicked "Place block"
3. Clicked "+" in a region, a modal window appears with block listing
4. Still in Modal: I click "place block" on an existing block (e.g. "who's online")
5. Still in Modal: I fill out the block settings, press "Save block"
6. Modal closes and redirected to block layout page with the selected block in the correct region
7. Press "Save blocks" on block layout page
8. Redirected back to block layout page
Video: https://www.youtube.com/watch?v=ViUknSpobkQ
Per the comments above, I sense the latest patch did not resolve the proposed workflow in #2735277-16: Let users set the weight of blocks after placing them from place-block, as observation 6 does not stay in the modal, it redirects to the block layout page. It should also be noted that observation 8 does not go back to the page in which the user placed the block.
As such, I'm setting this to "Needs work".
Comment #31
nerdsteinI believe this is now a duplicate of the work performed in #2784495: Normalize block place and outside-in experiences.
My commentary is found both in #2739075-41: [plan] Make Place Blocks module functionality part of the Block module (etc.) and #2784495-30: Normalize block place and outside-in experiences.
As such, I've updated the status of this issue accordingly.
Comment #32
SKAUGHTi hear what you're saying overall. Certainly, i think that 'let the user set the block weight in the ui' -- the basic work of this ticket is needed for the overall, regardless of the rest of the UX flow proposed
i have opened #2887032: Let user set block weight in while configuring block instance for this.
cheers.