Jetpack currently loads about 70 blocks and plugins in the editor. A small portion of those blocks aren't immediately available though. If the feature is tied to a Jetpack module (as available in projects/plugins/jetpack/modules), we've typically not loaded the block until the associated module was activated.

We've typically done that by placing the code that was registering the block in files that are only loaded when the module is active, or by adding a is_module_active check`. Here is an example:

While this make sense, it's also not ideal for site owners:

• Someone may have heard / read about Jetpack offering a specific feature, but may not find it in their block editor because the module isn't active yet.
• Someone may be looking for a specific block, and looking for a plugin that will help them even though they wouldn't have to look for a new plugin if they knew the Jetpack plugin that's already installed on their site offers that functionality.

Ideally, we would offer all the blocks available in Jetpack, with a prompt to activate the feature when necessary. This is something we've already implemented with the Subscriptions block:

Let's aim to offer a similar experience for the other features that rely on modules, listed below.

This would also address the problem of obscure error messages when a block is used on a site where the module was disabled: #11903

Implementation

In #29044, we've introduced the useModuleStatus hook in @automattic/jetpack-shared-extension-utils, that allows us to turn a module on from the block editor. This can be used for the modules below.

While for some of those modules the change should be fairly straightforward, for others we'll need to watch out for any meta data that may be created on module activation.

Block List

Internal references

PT: pf5801-7Q-p2

Past discussions:

• p8oabR-DS-p2#comment-5223
• pafL3P-78-p2
• pafL3P-1X-p2
• pafL3P-cP-p2
• pafL3P-aF-p2
• p1HpG7-5JG-p2