[Widgets Editor] Fix insertion point in widget areas #25727
Conversation
kevin940726
added
[Type] Bug
kevin940726
requested review from
draganescu,
adamziel,
noisysocks,
talldan and
tellthemachines
|
Size Change: +121 B (0%) Total Size: 1.18 MB
ℹ️ View Unchanged
|
|
Looks good! The block is inserted into the right place when I click on it in the inserter. This isn't addressing the first part of #25708, though. When I hover over the block in the inserter, I should see a blue line appear at the bottom of the widget area where the block will be inserted. |
packages/block-editor/src/components/inserter/hooks/use-insertion-point.js
Outdated
Show resolved
Hide resolved
@noisysocks Good point, I missed it! However, there's no blue line when inserting to post editor via the inserter either though. I wonder if we should follow the current behavior in post editor? 🤔 |
Oh, huh. That might be a bug unless it was intentionally removed and @mapk and I have missed it. |
|
It seems like in both the post editor and widgets editor the blue line doesn't show if you're trying to insert at the end of a block list. I think it's only implemented to show before a block that exists: I made a separate bug report for this - #25785 |
…nsertionPoint prop (#25763) * Fix widget insertion from sidebar block library by using a declared insertionPoint prop * Add comments * Optimize by avoiding `getEntityRecord` call unless needed
|
@kevin940726 this looks great overall! I found two problems:
|
|
I encouraged the same interaction as in the post editor here. If there is an area selected, or a block selected that has no blocks below it, the blue line doesn't appear. I could be convinced that it needs to show all the time. |
@adamziel This seems expected to me? Since the user explicitly "un-focus" the selected block. I think it could be pretty frustrating if the user can't do that. It's just my opinion though, and I would love to be proven wrong!
Nice catch! Open another issue? |
|
@kevin940726 yes, can you open another issue for that lack of margin? |
@kevin940726 I checked what happens in the post editor. If you click on the top bar, it still remembers the last focused block. |
Hmmm, interesting, could you share a gif just to be sure that I understand it correctly? It's similar in the Widgets Editor, it will remember the last focused block if you click on the top bar. In the post editor, the inserter will append to the end when you click on an empty area in the post too. I think they are behaving similarly? Maybe I'm missing some edge cases though 🤔 .
|
|
@kevin940726 oh that's right! It seems like it's a mental model thing - in the post editor, the entire page is the editor and so whenever I want to remove the blue focus I feel it's "safe" to click on the blank area of top bar without really affecting the editor area (as if the top bar was outside of the editor). I applied the same mental model to the grey area in the widgets editor, even though if you inspect it with dev tools, it is part of the editor. I somehow instinctively click there every now and then though (as if it was outside of the editor) :-) Sounds like it's something that we should consider separately (if at all). Let me CC @mapk and approve this PR! |
* Move hooks inside the newly created Interface component * Fix insertion at the top of the widget area * Fix widget insertion from sidebar block library by using a declared insertionPoint prop (#25763) * Fix widget insertion from sidebar block library by using a declared insertionPoint prop * Add comments * Optimize by avoiding `getEntityRecord` call unless needed Co-authored-by: Daniel Richards <[email protected]>
* Include edit-widgets php files in build (#25792) * Fix PHP warining in widget utils controller (#25797) * Fix PHP warning in WP_REST_Widget_Utils_Controller The `WP_REST_Widget_Utils_Controller::is_valid_widget` method needs to be public in order to be accessible as a callback (since it's being called from outside the class, via `call_user_func`). This commit fixes the warning by changing the method's visibility from `private` to `public`. * Ammend the inline documentation. Add `* @access public` * [Widgets Editor] Fix insertion point in widget areas (#25727) * Move hooks inside the newly created Interface component * Fix insertion at the top of the widget area * Fix widget insertion from sidebar block library by using a declared insertionPoint prop (#25763) * Fix widget insertion from sidebar block library by using a declared insertionPoint prop * Add comments * Optimize by avoiding `getEntityRecord` call unless needed Co-authored-by: Daniel Richards <[email protected]> * Initialize the state before rendering widgets editor (#25736) * Initialize the state before rendering widgets editor * Replace empty div with null * Document persistStubPost * Document persistStubPost further * Bump version to 9.1.1 * Update changelog * Fix spaces in changelog.txt * Adjust spaces in changelog.txt * Fix link formatting in the changelog Co-authored-by: Jon Surrell <[email protected]> Co-authored-by: David Biňovec <[email protected]> Co-authored-by: Kai Hao <[email protected]> Co-authored-by: Daniel Richards <[email protected]>
Description
Fix #25708.
Fixes #25764.
Insert blocks at the bottom of the widget area via the inserter.
Also fixes a regression in #25708 where the inserter would insert blocks to the first widget area no matter which widget area is selected.
How has this been tested?
Screenshots
Types of changes
Bug fix
Checklist: