Auto-inserting blocks: Add block inspector panel #52969
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
This pull request has changed or added PHP files. Please confirm whether these changes need to be synced to WordPress Core, and therefore featured in the next release of WordPress. If so, it is recommended to create a new Trac ticket and submit a pull request to the WordPress Core Github repository soon after this pull request is merged. If you're unsure, you can always ask for help in the #core-editor channel in WordPress Slack. Thank you! ❤️ View changed files❔ lib/experimental/auto-inserting-blocks.php ❔ lib/experimental/editor-settings.php |
|
Size Change: +1.23 kB (0%) Total Size: 1.51 MB
ℹ️ View Unchanged
|
ockham
force-pushed
the
add/auto-inserting-block-inspector-panel
branch
from
cf957fe
to
86eddd8
Compare
|
Flaky tests detected in e10c5b3. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/6010003914
|
|
Currently looking at https://github.com/WordPress/gutenberg/pull/47677/files#diff-afcd276d226efa4e9af0a9cf09cf68222ed1385d939b45d9b83a9145121091bf for inspiration how to add the extra |
|
Turns out the With ca1bafc, I see the
|
|
Aaand with a8dd375:
|
|
Typing This is likely because preloading happens before the additional I'll try investigating this; I might start by trying to disable the preloading altogether to see if that bypasses the issue. |
|
Ah, might not be the preloaded Edit: Right, and that is populated by |
|
I would probably be helpful to have some indicator of which plugin is registering the insertion. |
|
Yes, perhaps something like: 
|
|
We don't have any patterns or systems that put the toggles on the right, so if we are going to use toggles for this, the toggles should be on the left. |
|
Reading up on the context, to add to my previous comment, I do see how having the icons line up vertically with the toggle being on its own on the right, I think this PR can be a testbed for how to leverage this pattern, and if it works, it would be good to use it in additional contexts so the pattern becomes clearer. So my comment shouldn't be seen as blocking. |
ockham
force-pushed
the
add/auto-inserting-block-inspector-panel
branch
from
a60a553
to
8309ab4
Compare
|
Getting there (slowly but steadily):
(Nevermind the shitty styling, gonna change that later.) |
ockham
force-pushed
the
add/auto-inserting-block-inspector-panel
branch
from
5e004bd
to
2f1bb82
Compare
|
Tested with Jetpack (VideoPress block is the only one having a block.json file currently. We're working towads having all other blocks do the same.) 
|
|
I have a UX question for our designers 😊 After inserting a block by enabling its toggle, what should happen if we modify the auto-inserted block (e.g. by moving it around, or simply changing an attribute), and then visit its anchor block again? Is the toggle still shown as enabled?
My intuition would say that if the block is moved away (or even deleted!), the toggle should show up as disabled (which will also allow inserting a new copy of it in its target by re-enabling the toggle). I'm a bit less sure about other changes, but I'm leaning towards also disabling the toggle. Note that when the toggle shows up as enabled, we allow the user to remove the inserted block by disabling the toggle. The question is whether that should be allowed for a block that has already seen some user modifications. BTW: In terms of implementation, we'll likely need a global |
Thank you @oskosk! FWIW, auto-insertion into unmodified templates and template parts also works via a manual call to |
Yeah, should become disabled if the child block loses connection with the parent. We'd want to ideally communicate that there's already a block inserted, though. For example, perhaps if the block is still in the tree (because you moved it somewhere else) we remove the entire list item (so no disabled nor enabled); while if the block isn't present in the tree at all, that's when we show it disabled. |
|
I generally agree, but looking at the gif in #52969 (comment) it looks like the relationship will be lost instantly, which might result in an awkward UX:
Should the Mini Cart be inserted within the Navigation rather than outside? |
|
Inside or outside is a choice by the plugin, both should be supported. If a block is a sibling it should still show up as toggled since it matches the before/after condition. |
ockham
commented
Aug 7, 2023
|
Thanks for clarifying, @mtias and @jameskoster! I think this confirms my inkling that I'll implement this via a global |
|
Going to merge. E2E test failures seem unrelated and also present in some of the recent commits to trunk. |
Mamaduka
reviewed
Aug 29, 2023
This was referenced Aug 29, 2023
jsnajdr
reviewed
Aug 30, 2023
ockham
added a commit
that referenced
this pull request
Sep 4, 2023
…54024) If a block that would normally be auto-inserted is not found in its designated position but elsewhere, we can assume somewhat safely that it was inserted manually, and that the user is aware of the block and won't need any UI elements to make it more visible. Additionally, this PR fixes most of the following warnings (raised [here](#52969 (comment))): ``` The 'useSelect' hook returns different values when called with the same state and parameters. This can lead to unnecessary rerenders. ``` --------- Co-authored-by: George Mamadashvili <georgemamadashvili@gmail.com>
ockham
added a commit
that referenced
this pull request
Sep 4, 2023
…54024) If a block that would normally be auto-inserted is not found in its designated position but elsewhere, we can assume somewhat safely that it was inserted manually, and that the user is aware of the block and won't need any UI elements to make it more visible. Additionally, this PR fixes most of the following warnings (raised [here](#52969 (comment))): ``` The 'useSelect' hook returns different values when called with the same state and parameters. This can lead to unnecessary rerenders. ``` --------- Co-authored-by: George Mamadashvili <georgemamadashvili@gmail.com>
86 tasks
|
Trainer and end-user support feedback: Please don't call them "plugins." Maybe that term makes sense in the narrow circle of professional React developers that have taken over WordPress development but it's just going to be confusing for the vast majority of non-professional WordPress site owners and users. Obviously, WordPress already has a rather large feature called "Plugins," so overloading the term for "auto-inserting blocks" is asking end-user trainers and maintainers to spend even more time disambiguating terms. But, almost as important, thanks to the unfortunate state of plugins 15-20 years ago there's a persistent, almost superstitious dread of plugins outside WordPress professional circles. And not a little, um, resistance to Gutenberg. So adding something called "plugins" to the Gutenberg interface is just asking for trouble. (It's especially problematic since the Block Editor completely hides the dashboard, and obviously you'd only see the "Plugin" panel when you're in the editor. So if any novice goes looking for "plugins" there will be a 50/50 chance they'll go to the wrong place. I know it's a panel so the name has to be short. So how about something like "auto blocks?" That will be enough for experienced developers and end users while also letting beginners know it's not something they should mess with until they know what they're doing. But really anything but "Plugins" would probably do. Thanks. |
ockham
added a commit
to ockham/wordpress-develop
that referenced
this pull request
Sep 21, 2023
Block Hooks allow a third-party block to specify a position relative to a given block into which it will then be automatically inserted (e.g. a "Like" button block can ask to be inserted after the Post Content block, or an eCommerce shopping cart block can ask to be inserted after the Navigation block). The underlying idea is to provide an extensibility mechanism for Block Themes, in analogy to WordPress' [https://developer.wordpress.org/plugins/hooks/ Hooks] concept that has allowed extending Classic Themes through filters and actions. The two core tenets for Block Hooks are: 1. Insertion into the frontend should happen right after a plugin containing a hooked block is activated (i.e. the user isn't required to insert the block manually in the editor first); similarly, disabling the plugin should remove the hooked block from the frontend. 2. The user has the ultimate power to customize that automatic insertion: The hooked block is also visible in the editor, and the user's decision to persist, dismiss (i.e. remove), customize, or move it will be respected (and reflected on the frontend). To account for both tenets, the **tradeoff** was made to limit automatic block insertion to unmodified templates (and template parts, respectively). The reason for this is that the simplest way of storing the information whether a block has been persisted to (or dismissed from) a given template (or part) is right in the template markup. To accommodate for that tradeoff, [WordPress/gutenberg#52969 UI controls (toggles)] are being added to increase visibility of hooked blocks, and to allow for their later insertion into templates (or parts) that already have been modified by the user. For hooked blocks to appear both in the frontend and in the editor (see tenet number 2), they need to be inserted into both the frontend markup and the REST API (templates and patterns endpoints) equally. As a consequence, this means that automatic insertion couldn't (only) be implemented at block ''render'' stage, as for the editor, the ''serialized'' (but ''unrendered'') markup needs to be modified. Furthermore, hooked blocks also have to be inserted into block patterns. Since practically no filters exist for the patterns registry, this has to be done in the registry's `get_registered` and `get_all_registered` methods. Props gziolo. Fixes #59313.
pento
pushed a commit
to WordPress/wordpress-develop
that referenced
this pull request
Sep 21, 2023
Block Hooks allow a third-party block to specify a position relative to a given block into which it will then be automatically inserted (e.g. a "Like" button block can ask to be inserted after the Post Content block, or an eCommerce shopping cart block can ask to be inserted after the Navigation block). The underlying idea is to provide an extensibility mechanism for Block Themes, in analogy to WordPress' [https://developer.wordpress.org/plugins/hooks/ Hooks] concept that has allowed extending Classic Themes through filters and actions. The two core tenets for Block Hooks are: 1. Insertion into the frontend should happen right after a plugin containing a hooked block is activated (i.e. the user isn't required to insert the block manually in the editor first); similarly, disabling the plugin should remove the hooked block from the frontend. 2. The user has the ultimate power to customize that automatic insertion: The hooked block is also visible in the editor, and the user's decision to persist, dismiss (i.e. remove), customize, or move it will be respected (and reflected on the frontend). To account for both tenets, the **tradeoff** was made to limit automatic block insertion to unmodified templates (and template parts, respectively). The reason for this is that the simplest way of storing the information whether a block has been persisted to (or dismissed from) a given template (or part) is right in the template markup. To accommodate for that tradeoff, [WordPress/gutenberg#52969 UI controls (toggles)] are being added to increase visibility of hooked blocks, and to allow for their later insertion into templates (or parts) that already have been modified by the user. For hooked blocks to appear both in the frontend and in the editor (see tenet number 2), they need to be inserted into both the frontend markup and the REST API (templates and patterns endpoints) equally. As a consequence, this means that automatic insertion couldn't (only) be implemented at block ''render'' stage, as for the editor, the ''serialized'' (but ''unrendered'') markup needs to be modified. Furthermore, hooked blocks also have to be inserted into block patterns. Since practically no filters exist for the patterns registry, this has to be done in the registry's `get_registered` and `get_all_registered` methods. Props gziolo. Fixes #59313. git-svn-id: https://develop.svn.wordpress.org/trunk@56649 602fd350-edb4-49c9-b593-d223f7449a82
markjaquith
pushed a commit
to markjaquith/WordPress
that referenced
this pull request
Sep 21, 2023
Block Hooks allow a third-party block to specify a position relative to a given block into which it will then be automatically inserted (e.g. a "Like" button block can ask to be inserted after the Post Content block, or an eCommerce shopping cart block can ask to be inserted after the Navigation block). The underlying idea is to provide an extensibility mechanism for Block Themes, in analogy to WordPress' [https://developer.wordpress.org/plugins/hooks/ Hooks] concept that has allowed extending Classic Themes through filters and actions. The two core tenets for Block Hooks are: 1. Insertion into the frontend should happen right after a plugin containing a hooked block is activated (i.e. the user isn't required to insert the block manually in the editor first); similarly, disabling the plugin should remove the hooked block from the frontend. 2. The user has the ultimate power to customize that automatic insertion: The hooked block is also visible in the editor, and the user's decision to persist, dismiss (i.e. remove), customize, or move it will be respected (and reflected on the frontend). To account for both tenets, the **tradeoff** was made to limit automatic block insertion to unmodified templates (and template parts, respectively). The reason for this is that the simplest way of storing the information whether a block has been persisted to (or dismissed from) a given template (or part) is right in the template markup. To accommodate for that tradeoff, [WordPress/gutenberg#52969 UI controls (toggles)] are being added to increase visibility of hooked blocks, and to allow for their later insertion into templates (or parts) that already have been modified by the user. For hooked blocks to appear both in the frontend and in the editor (see tenet number 2), they need to be inserted into both the frontend markup and the REST API (templates and patterns endpoints) equally. As a consequence, this means that automatic insertion couldn't (only) be implemented at block ''render'' stage, as for the editor, the ''serialized'' (but ''unrendered'') markup needs to be modified. Furthermore, hooked blocks also have to be inserted into block patterns. Since practically no filters exist for the patterns registry, this has to be done in the registry's `get_registered` and `get_all_registered` methods. Props gziolo. Fixes #59313. Built from https://develop.svn.wordpress.org/trunk@56649 git-svn-id: http://core.svn.wordpress.org/trunk@56161 1a063a9b-81f0-0310-95a4-ce76da25c4cd
github-actions bot
pushed a commit
to platformsh/wordpress-performance
that referenced
this pull request
Sep 21, 2023
Block Hooks allow a third-party block to specify a position relative to a given block into which it will then be automatically inserted (e.g. a "Like" button block can ask to be inserted after the Post Content block, or an eCommerce shopping cart block can ask to be inserted after the Navigation block). The underlying idea is to provide an extensibility mechanism for Block Themes, in analogy to WordPress' [https://developer.wordpress.org/plugins/hooks/ Hooks] concept that has allowed extending Classic Themes through filters and actions. The two core tenets for Block Hooks are: 1. Insertion into the frontend should happen right after a plugin containing a hooked block is activated (i.e. the user isn't required to insert the block manually in the editor first); similarly, disabling the plugin should remove the hooked block from the frontend. 2. The user has the ultimate power to customize that automatic insertion: The hooked block is also visible in the editor, and the user's decision to persist, dismiss (i.e. remove), customize, or move it will be respected (and reflected on the frontend). To account for both tenets, the **tradeoff** was made to limit automatic block insertion to unmodified templates (and template parts, respectively). The reason for this is that the simplest way of storing the information whether a block has been persisted to (or dismissed from) a given template (or part) is right in the template markup. To accommodate for that tradeoff, [WordPress/gutenberg#52969 UI controls (toggles)] are being added to increase visibility of hooked blocks, and to allow for their later insertion into templates (or parts) that already have been modified by the user. For hooked blocks to appear both in the frontend and in the editor (see tenet number 2), they need to be inserted into both the frontend markup and the REST API (templates and patterns endpoints) equally. As a consequence, this means that automatic insertion couldn't (only) be implemented at block ''render'' stage, as for the editor, the ''serialized'' (but ''unrendered'') markup needs to be modified. Furthermore, hooked blocks also have to be inserted into block patterns. Since practically no filters exist for the patterns registry, this has to be done in the registry's `get_registered` and `get_all_registered` methods. Props gziolo. Fixes #59313. Built from https://develop.svn.wordpress.org/trunk@56649 git-svn-id: https://core.svn.wordpress.org/trunk@56161 1a063a9b-81f0-0310-95a4-ce76da25c4cd
pereirinha
pushed a commit
to pereirinha/wordpress-develop
that referenced
this pull request
Sep 21, 2023
Block Hooks allow a third-party block to specify a position relative to a given block into which it will then be automatically inserted (e.g. a "Like" button block can ask to be inserted after the Post Content block, or an eCommerce shopping cart block can ask to be inserted after the Navigation block). The underlying idea is to provide an extensibility mechanism for Block Themes, in analogy to WordPress' [https://developer.wordpress.org/plugins/hooks/ Hooks] concept that has allowed extending Classic Themes through filters and actions. The two core tenets for Block Hooks are: 1. Insertion into the frontend should happen right after a plugin containing a hooked block is activated (i.e. the user isn't required to insert the block manually in the editor first); similarly, disabling the plugin should remove the hooked block from the frontend. 2. The user has the ultimate power to customize that automatic insertion: The hooked block is also visible in the editor, and the user's decision to persist, dismiss (i.e. remove), customize, or move it will be respected (and reflected on the frontend). To account for both tenets, the **tradeoff** was made to limit automatic block insertion to unmodified templates (and template parts, respectively). The reason for this is that the simplest way of storing the information whether a block has been persisted to (or dismissed from) a given template (or part) is right in the template markup. To accommodate for that tradeoff, [WordPress/gutenberg#52969 UI controls (toggles)] are being added to increase visibility of hooked blocks, and to allow for their later insertion into templates (or parts) that already have been modified by the user. For hooked blocks to appear both in the frontend and in the editor (see tenet number 2), they need to be inserted into both the frontend markup and the REST API (templates and patterns endpoints) equally. As a consequence, this means that automatic insertion couldn't (only) be implemented at block ''render'' stage, as for the editor, the ''serialized'' (but ''unrendered'') markup needs to be modified. Furthermore, hooked blocks also have to be inserted into block patterns. Since practically no filters exist for the patterns registry, this has to be done in the registry's `get_registered` and `get_all_registered` methods. Props gziolo. Fixes #59313. git-svn-id: https://develop.svn.wordpress.org/trunk@56649 602fd350-edb4-49c9-b593-d223f7449a82
|
@davidinnes Apologies for the delay in getting back to you, I was fairly busy getting the code for auto-inserting blocks (which we've since renamed to "Block Hooks") merged into Core over the past three weeks. Have you had a chance to try out the feature? I don't think that "Plugins" is that ill-chosen a name, but the reason might become obvious only when using the feature. You can use e.g. WP 6.4 Beta 1, or alternatively WP 6.3 with the latest stable version of the Gutenberg plugin, and with this little plugin to test. Of note:
I hope that might help reframe the issue a bit. Finally, while we're now calling the feature "Block Hooks", this is more targeted towards developers (because of its analogy to WP's "classic" hooks which they'll be already familiar with); it's a term that would likely require extra effort to introduce users to, whereas it's more likely that they're already familiar with the term "Plugins". Here, it's supposed to simply mean "blocks added by plugins" (next to the current block), which in the context of the block inspector hopefully makes sense. |
|
If I understand this feature correctly a “plugin” in the block context is a block that automatically gets inserted on the page next to a block that’s placed there by an author?
So, to use an intentionally absurd example, a prankster colleague could install a (conventional) plugin to a site that automatically inserts a text block with the words “to your galactic overlords” next to any button block with the word “submit?”
Meanwhile the purpose of the “Plugin" panel would be so the author could remove the automatically inserted prank blocks?
Even though that’s a silly example I can definitely see why users would want a way to manage automatically inserted blocks. I'm sure there are genuinely helpful use cases for this but I’ll give you a nickel if one of the freemium plugin or theme developers doesn’t use hooked blocks to automatically add “powered by [my annoying company]” next to or below the last text block in the footer, or for instance after a form, calendar, or checkout block.
But even assuming these automatic blocks (that can be added only by plugins and not, say, by commercial theme vendors or malware) are used only for the most benign, high-utility cases, I would think that
Automatic
Auto-inserted
Auto blocks
By plugins
From plugins
would be clearer for ordinary site owners and users.
Again, I’m sure “plugins" makes total sense from inside the team and from inside the code. And sure, from a dev team perspective “panel for blocks hooked by plugins” can be shortened to “plugins.” But, seriously, how long would it take you to clarify that if you were explaining it over the phone to your uncle, an 8th-grader cousin, or a client’s disgruntled office admin. I ask because as a trainer and support professional I have to field those questions. I don’t look forward to getting calls like “so I deleted that plugin like you talked about last month but now the whole calendar is missing.”
—
I did try WP 6.4 Beta 1 with the sample “like” plugin you mentioned but couldn’t see a Plugin panel, even after I activated and inserted the “like” block. I didn’t see the panel either in post-edit or site-edit modes. (The plugin had only default documentation in the readme and I didn’t have time this morning to investigate further.)
David Innes, owner
Real Basics, LLC
(206) 390-8082
Schedule a call or Zoom meeting:
https://calendly.com/realbasics
… On Oct 2, 2023, at 6:23 AM, Bernie Reiter ***@***.***> wrote:
@davidinnes <https://github.com/davidinnes> Apologies for the delay in getting back to you, I was fairly busy getting the code for auto-inserting blocks (which we've since renamed to "Block Hooks") merged into Core over the past three weeks.
Have you had a chance to try out the feature? I don't think that "Plugins" is that ill-chosen a name, but the reason might become obvious only when using the feature. You can use e.g. WP 6.4 Beta 1, or alternatively WP 6.3 with the latest stable version of the Gutenberg plugin, and with this little plugin <https://github.com/ockham/like-button/releases/download/v0.5.0/like-button.zip> to test.
Of note:
The "Plugins" panel will show a list of hooked blocks that are, indeed, registered by plugins for automatic insertion next to the currently selected block -- in the traditional, "WordPress", sense of the word "plugin" 😄 (I.e. React doesn't have anything to do with this.) Any plugin that contains a block that's rendered in PHP on the frontend can opt to automatically have that block inserted next to another block; the editor will detect this and show the hooked block as such in the "Plugins" panel.
The toggle next to each block allows the user to easily remove or re-insert the corresponding hooked block.
The Plugins panel only shows up if there is at least one hooked block registered for insertion next to the currently selected one; otherwise, the panel won't be shown (thus hopefully reducing confusion).
AFAIK, this is the only block-based extension mechanism for Block Themes available to plugins; this is reflected by being the only UI element titled "Plugins" in the editor's block inspector.
I hope that might help reframe the issue a bit.
Finally, while we're now calling the feature "Block Hooks", this is more targeted towards developers (because of its analogy to WP's "classic" hooks which they'll be already familiar with); it's a term that would likely require extra effort to introduce users to, whereas it's more likely that they're already familiar with the term "Plugins". Here, it's supposed to simply mean "blocks added by plugins" (next to the current block), which in the context of the block inspector hopefully makes sense.
—
Reply to this email directly, view it on GitHub <#52969 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAON42SGKYCWDVLYYH74VDTX5K54BAVCNFSM6AAAAAA2YJ2PJ6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONBTGAYDSOBZHE>.
You are receiving this because you were mentioned.
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What?
Follow-up to #51449.
Add a new panel (tentatively named "Plugins") to the block inspector that lists blocks that are slated for auto-insertion next to that block, and provide toggles to insert (or remove) them.
Based on mockups by @jameskoster, following an idea by @mtias:
Started during a pair-programming session with @c4rl0sbr4v0.
Why?
While blocks are auto-inserted in a pretty straight-forward way into unmodified templates, there's currently no visibility of them in modified templates. This PR seeks to provide a way to the user to easily insert them into their designated spots.
How?
Remaining TODO items will be tackled in follow-up PRs
auto_insertfield via REST API.gutenberg_register_auto_inserted_block()(rather than viablock.json).Testing Instructions
See video below.
Screenshots or screencast
https://www.loom.com/share/82e50b1f30c641f9b9e470eb43ac7350?sid=687c394b-f2e5-47d9-a450-a1f2f51d8e96