Plugin Blocks: Consider showing source in Advanced panel

[jasmussen]

Extending the block editor through new blocks is one of the most powerful ways of adding functionality. Yet when you've installed a slew of blocks, it can be hard to know which plugin, or theme, added the particular block. Shown here, the Image Compare block from Jetpack, solely denoted using the green accent color of the icon:

Would it be useful if "block credits" were shown in the Advanced panel? Shown here, an "About" sub-section there that adds the text: "This block was added by Jetpack." with a link to the plugin page.

This would not be plugin-customizable, it would simply output the plugin-name.

@WordPress/gutenberg-design

[Marc-pi]

yes, agreed, needed daily :-)

[jarekmorawski]

It's an important problem to solve. Thanks for raising it! I wonder if that information should be shown somewhere near the top? That's where the block description is and the new info feels related.

Should it be displayed so prominently? Perhaps we'd have a small ( i ) or plugin icon next to the block's name displaying a tooltip on hover?

Could this be an opportunity to create a core-approved pattern for displaying additional links to support docs, onboarding guides, and feedback prompts? Each 3PD and platform seems to do it differently. Here are examples from Dotcom and Woo.

[jasmussen]

It's an important problem to solve. Thanks for raising it! I wonder if that information should be shown somewhere near the top? That's where the block description is and the new info feels related.

I think we should be careful to force anything into that area, because that area should already be fully extensible by plugins to do with as they please. Anything we put there would potentially reduce plugin flexibility. While the benefit could be consistency, there's also an opportunity cost. By making the area free, it is a space for ideas we have perhaps not yet seen.

I agree with your point, though, plugins can benefit from a great description. I wonder if there's a "best practices" doc we can add to the block card docs?

[hanneslsm]

Good issue!

I'd also expect the info on the top.
What about below the description, just as we know it from the classic plugin view? Adding a "by line" of the Author and maybe even a URL attribute?

Question would be if it's also needed (and possible) to add a info like "via plugin", "via theme" or so?

[jasmussen]

Another reason for including it under Advanced, rather than at the top, is that most of the time this information isn't that useful to you. It's only useful when you're specifically looking for it: "I want to figure out from where this Image Compare block came, so I can share it with my friend who asked for it".

[jarekmorawski]

Could something like this work, then?

blockdetails.mov

[jasmussen]

Definitely could, yes.

[t-hamano]

From a technical standpoint, we need to consider that it may not be possible to determine which plugin a block was registered from.

Registering blocks, i.e. functions like register_block_type(), can be done from themes as well as plugins. A theme cannot include blocks if it is published in the theme directory, but a theme not published in the theme directory can include blocks.

Furthermore, if the block is not exposed in the plugin directory as a plugin, we will need to find out the plugin name and author somehow. We might need to update the register_block_type() function to include meta info.

[jameskoster]

Just to note, this case is a bit similar to the markings applied to the homepage / posts page in the document inspector:

It might be worth looking at the card from a systems perspective, and consolidating between document/block?

[jarekmorawski]

It might be worth looking at the card from a systems perspective, and consolidating between document/block?

Shouldn't we reserve pills for something more important from the UX POV, like states (#38277)? They're quite prominent visually and I'd argue they're better used to inform users about the active block state, variation, or other important information rather than something that doesn't have much impact on the editing experience.

[jameskoster]

Potentially yes. I see that as another good argument for approaching this with a systems hat on, contemplating all the information the card(s) might need to display.

I'm not entirely convinced about putting this information (block source) in a menu, it feels semantically incorrect to me.

[jarekmorawski]

Maybe a subtle help text could work? Or a popover that also contains the block description? I feel it's often redundant, especially after you become more experienced with the editor.

[jasmussen]

I would recommend being extremely careful adding anything to the top block card unless we're super sure what it should be. Anything we add there pushes down the inspector controls that you'll be using 99% of the time. So we need to strike that balance where this information can still be intuitively found if you are specifically looking for it.

Also just to echo/boost Aki, this may not even be possible after all:

From a technical standpoint, we need to consider that it may not be possible to determine which plugin a block was registered from.

So before we dive too deep in visual implementations (of which several of the prosals here can work), it might be good to move it to a tech spike.