Allow pure Gutenberg extensions to be registered with Jetpack (with plan gate).

[getdave]

Alternative approach to #16746.

Enables registering a Gutenberg extension with Jetpack without registering a block but including a plan check. New the API is:

function register_extension() {
	jetpack_register_extension(
		EXTENSION_NAME,
		array(
			'plan_check' => true,
		)
	);
}
add_action( 'init', __NAMESPACE__ . '\register_extension' );

Why do this?

Some extensions for the Gutenberg editor in Jetpack are not strictly blocks. However, there is no way to register an extension with Jetpack which is gated by a plan without either:

• manually setting the extension to be available using set_extension_available.
• calling register_jetpack_block.

Moreover, if you need to gate your extension to a particular plan on either Jetpack or WPCom then you are forced to either:

• use register_jetpack_block with the plan_check argument - this is odd because the nomenclature of extension and block is jarring and confusing.
• manually call set_extension_available and perform the plan checks yourself manually.

This PR attempts to normalise the situation by creating a new helper register_jetpack_extension which essential captures the functionality of register_jetpack_block (including the ability to do plan checks), but avoids registering a block with Gutenberg via register_block. The original register_jetpack_block is left in place, but now simply delegates the bulk of its functionality to the aforementioned register_jetpack_extension, and then simply calls register_block if extension registration is successful.

Use Cases

The social-previews extension needs to be gated for WPCom but not for Jetpack. Currently, in order to do this we are forced to register a block which doesn't do anything (because it isn't a block!). This is confusing because the social-previews feature is not a block - it is purely adding to the Jetpack sidebar.

Using the new approach in this PR we are able to register the social-previews extension and gate it to WPCom plans.

Changes proposed in this Pull Request:

This change allows us to:

• register Gutenberg extensions within Jetpack without registering a block.
• gate an extension to a WPCom or Jetpack plan in a central location.
• avoid spreading gating logic for Jetpack extensions within individual files (or indeed within the WPCom codebase as per this diff D46955-code).
• continue to register Jetpack blocks "as was" - this PR should preserve existing functionality.

Jetpack product discussion

See 84-gh-dotcom-manage.

Does this pull request change what data or activity we track or use?

No.

Testing instructions:

Same as #16746.

We should also check that all existing Jetpack blocks continue to be register "as was".

Proposed changelog entry for your changes:

• Allow Gutenberg extensions which need to be gated by plan to be registered via Jetpack without registering a corresponding block.

[jetpackbot]

Thank you for the great PR description!

When this PR is ready for review, please apply the [Status] Needs Review label. If you are an a11n, please have someone from your team review the code if possible. The Jetpack team will also review this PR and merge it to be included in the next Jetpack release.

E2E results is available here (for debugging purposes): https://jetpack-e2e-dashboard.herokuapp.com/pr-16804

Scheduled Jetpack release: September 1, 2020.
Scheduled code freeze: August 25, 2020

Generated by 🚫 dangerJS against 4ab1cb2

[getdave]

Let's try and land #16746 first and then rebase this branch.

[pablinos]

This looks like a good first step towards the refactor suggested in #16816. Sorry about the nitpick comments.

I've just come back from AFK and have seen some activity around this gating discussion, so there's a good chance this PR is obselete now anyway!

[pablinos]

Here and with the similar return statement below, I think we should be explicit about returning false

[pablinos]

This probably makes readability worse (and is almost the textbook definition of bikeshedding), but this could be rewritten to a single statement:

Suggested change

	if ( isset( $args['version_requirements'] )
	&& ! Jetpack_Gutenberg::is_gutenberg_version_available( $args['version_requirements'], $slug ) ) {
	return false;
	}
	// Checking whether block is registered to ensure it isn't registered twice.
	if ( Jetpack_Gutenberg::is_registered( $slug ) ) {
	return false;
	}
	return true;
	return ! (
	( isset( $args['version_requirements'] ) && ! Jetpack_Gutenberg::is_gutenberg_version_available( $args['version_requirements'], $slug ) )
	// Checking whether block is registered to ensure it isn't registered twice.
	&& Jetpack_Gutenberg::is_registered( $slug )
	);

It's a personal preference thing but it seems odd to have if ( boolean check) { return false } instead of return ! (boolean check)

[pablinos]

Does 'extension' only ever refer to Gutenberg extensions in Jetpack? I think that's the case, but otherwise, we might want to make that explicit here. jetpack_register_editor_extension or something.

[pablinos]

I realise it's not for this change, but the idea with plan_check was that it was a way of opting into the plan check until we ensured that the features for each plan were set up correctly for all the blocks/extensions.

As this file only exists to register the extension it would be good to take this a step further, and blocks and extensions auto-registered, maybe using something similar to block.json?

[stale]

This PR has been marked as stale. This happened because:

• It has been inactive in the past 3 months.
• It hasn’t been labeled `[Pri] Blocker`, `[Pri] High`.

No further action is needed. But it's worth checking if this PR has clear testing instructions, is it up to date with master, and it is still valid. Feel free to close this issue if you think it's not valid anymore — if you do, please add a brief explanation.

[getdave]

I'm not going to be picking this up so let's close it for now.