Allow themes to side-load single block plugins

[creativecoder]

What problem does this address?

Currently, block themes and patterns from the block pattern directory are limited to using core blocks, since those are guaranteed to be available on any WordPress site. A lot more creativity and variety would be possible if a theme could side-load single block plugins for its templates and patterns, making it possible to use blocks that aren't in the core block library.

What is your proposed solution?

Block themes would side-load single block plugins that are used in its templates and patterns but not yet installed on the site.

Ideally this would be seamless--if a block is used in a template or pattern for a theme, the corresponding single block plugin is installed and activated as needed--either on theme activation or when the pattern is inserted into the editor.

Alternatively, themes could provide a list of single block plugin slugs that it requires in theme.json

Only single block plugins that qualify for and are listed in the block directory should be side-loaded, so that more complex plugins that change other aspects of the site or admin are not installed unexpectedly.

[mikachan]

It would be great if themes and patterns could declare their dependencies on third-party blocks. I think this fits in nicely with #61144.

cc @WordPress/block-themers for any additional thoughts here.

[MaggieCabrera]

When you say single block plugin, you mean a plugin whose only feature is to include said block? Is that something we can check that is happening? I think about plugins like Jetpack, that include multiple blocks and plenty of other functionality, that would not fit this description (and which honestly would be very strange to suddenly have installed an active just because I installed a theme that ahs a Jetpack block in it)

[creativecoder]

When you say single block plugin, you mean a plugin whose only feature is to include said block? Is that something we can check that is happening?

@MaggieCabrera I mean those that meet the guidelines here: "...plugins that contain only a single, independent, top-level block and a minimum of supporting code," and thus qualify to be shown in the block inserter when searching, and automatically installed/activated from the editor.

I think about plugins like Jetpack, that include multiple blocks and plenty of other functionality, that would not fit this description (and which honestly would be very strange to suddenly have installed an active just because I installed a theme that ahs a Jetpack block in it)

Agreed, I don't think more complex plugins should be installed/activated automatically.

---

Thanks for asking, I'll update the issue description to be more specific!

[MaggieCabrera]

Thanks for asking, I'll update the issue description to be more specific!

Oh, I didn't know about this, thanks so much for explaining. Then your idea seems like a no brainer to me :D

[creativecoder]

An important consideration is what happens when a block plugin becomes defunct: maybe it gets removed from the plugins repo or a critical bug emerges that makes it unusable and the plugin is never fixed.

This would effectively break theme templates and/or patterns that use the block. It may not happen often, but would affect all themes that use the block plugin--the impact could be very widespread.

It would be better if we could have a guarantee that side-loaded block plugins will continue to be supported and updated, similar to core blocks. For example, perhaps only accepting block plugins with a certain threshold of community support, or only canonical block plugins (#58773).

[creativecoder]

Note that this issue was discussed in core devchat today: https://wordpress.slack.com/archives/C02RQBWTW/p1719434552101139

[creativecoder]

Some points raised during devchat:

• What would a fallback look like if a block was no longer available in the repo? Would it just not show, or would there be a way for the external block to fall back to core blocks?
• Traditionally core has not automatically installed plugins. Is this changing for themes?
• Perhaps a safer first step could be to not make any themes that depend on external blocks, using the blocks only for enhancements when they exist.

[costdev]

Traditionally core has not automatically installed plugins.

Indeed. When developing the Plugin Dependencies feature, it became very clear that there was strong opposition to the automatic installation and/or activation of plugins. I understand the use case and differences here, though I can't speak to whether automatic installation/activation of single-block plugins would face the same strong opposition. That's something I think should be determined via outreach before any design or development is considered. Data should be collected in the context of theme authoring/use, as well as general WordPress principles of user consent and transparency.

Additionally, I think the establishment of a theme having a plugin dependency should apply to any theme type and any plugin type, and should look to the WP_Plugin_Dependencies class introduced in 6.5 for prior art, possibly introducing a WP_Theme_Dependencies class, tailored to themes.

[carolinan]

That the block plugin is not automatically installed does not mean that themes are limited to core blocks.

When a theme uses a block that does not exist, there is already message in the editor, it will either say that the block does not exist (plugins with multiple blocks), or it will ask the user to install the plugin (single block plugins).

[MaggieCabrera]

That the block plugin is not automatically installed does not mean that themes are limited to core blocks.

When a theme uses a block that does not exist, there is already message in the editor, it will either say that the block does not exist (plugins with multiple blocks), or it will ask the user to install the plugin (single block plugins).

Maybe this could be improved and we could provide a fallback if the plugin cannot be installed

[creativecoder]

@carolinan Thanks for pointing out the block plugin install prompt. I was not aware of that, and it certainly helps the situation.

I still think there's a need for improvement here. In order to install the block plugins used by the theme, you have to know to open the site editor and view the relevant templates where those blocks are used. This feels too hidden, especially for newer users or those less familiar with the site editor.

And the front end of the site will show the saved block markup from the template without any custom styles or js, which can look quite broken. For example, if I'm searching for a new theme for my site that has a carousel on the home page, preview the home page, and see a bulleted list of images rather than a carousel, I would most likely assume the theme is broken and move on to try another theme.

Perhaps we could treat this similarly to plugin dependencies: prompt the user to install any block plugins used by the theme immediately after the theme is activated?

[carolinan]

It is used not only in templates, but wherever that block is used.

Plugin dependencies for themes were originally part of this larger discussion https://core.trac.wordpress.org/ticket/22316,
but the scope was reduced, seemingly without a new ticket being created for themes. Do you know more about that @afragen? Perhaps there was a new ticket created but I am unable to find it.

I do not believe that this is a problem that should be solved in Gutenberg, because it is much broader than missing blocks.
Related https://core.trac.wordpress.org/ticket/22316
as well as https://meta.trac.wordpress.org/ticket/3863 where it is explained that the wordpress.org theme previewer also can not install and activate required plugins.

[afragen]

@carolinan there was no ticket created for themes, but I do have a stale branch where I had an early working version of this.

https://github.com/WordPress/wp-plugin-dependencies/tree/themes

[carolinan]

I do sympathize with wanting to use other blocks, and with the user who is trying to find themes that support specific features like LMS and ecommerce plugins.
But I also think that installing anything, including a plugin, without explicit user action, consent, and without the user's knowledge, should not happen because it is unexpected and a violation of trust.

So in my view, those are the problems to solve, and the editor already solves that by showing this notification to the users:

• Knowledge: As a user I am informed that I need to install something extra or that the theme will install something extra for me.
• Trust: As a user I can trust the source of that plugin, because it is from the plugin directory.
• Choice: As a user I make an active choice.
  -- Either by activating a theme that is very clearly labeled as having a dependency,
  -- or by installing the plugin when prompted.