Footnotes not detected on CPTs registered by plugins (in WordPress 6.5 wp-dev PR)

[peterwilsoncc]

Description

The register_block_core_footnotes is currently hooked on the init action to run at the default priority of 10.

1. This will miss CPTs registered late in the init action at priority 11 or higher
2. In WordPress Core this will miss Custom Post Types (CPTs) registered by plugins using the default init priority as register_block_core_footnotes() runs before the action registered by the plugins.

When two actions are registered at the same priority, WordPress runs the actions in the order in which they are registered as each subsequent action is appended to the array.

In the released version of WordPress, the blocks are registered prior to plugins so the relevant portion of the WP_Hook instance is:

$GLOBALS['wp_filter']['init']['callbacks'][10] = [
    'register_block_core_footnotes',
    'my_plugin_register_cpts'  
]

Note

This portion of the bug may be suppressed when running the Gutenberg plugin due to the hook being registered by a plugin. Please check out WordPress/wordpress-develop#5922 to test the second part of this issue.

Suggested resolution

Run the register_block_core_footnotes later on the init action, I suggest at a priority of about 100 but that's pretty much a random number.

To maintain backward compatibility for plugins deactivating the footnotes block by running remove_action( 'init', 'register_block_core_footnotes' ); some juggling will be required.

Follow up to #57353.

cc @youknowriad @ellatrix @jorgefilipecosta

Step-by-step reproduction instructions

1. Check out Editor: Initial WordPress package updates for 6.5 wordpress-develop#5922
2. Ensure the Gutenberg plugin is disabled
3. Activate the plugin in the code snippet below
4. Visit Dashboard > CPT Supporting Footnotes > Add New Post
5. Write some content and attempt to insert a footnote, they will be unavailable.

The same result will occur for Late CPT Supporting Footnotes

Screenshots, screen recording, code snippet

Plugin for testing

<?php
/**
 * Plugin Name: Testing CPT Footnotes
 */

namespace PWCC\TestingCptFootnotes;

add_action( 'init', __NAMESPACE__ . '\\register_cpts' );
add_action( 'init', __NAMESPACE__ . '\\late_register_cpts', 20 );

function register_cpts() {
	register_post_type(
		'cpt-with-footnotes',
		[
			'public' => true,
			'show_in_rest' => true,
			'labels' => [
				'name'          => 'CPT Supporting Footnotes',
				'singular_name' => 'CPT Supporting Footnote',
				'plural_name'   => 'CPTs Supporting Footnotes',
			],
			'supports' => [
				'title',
				'editor',
				'revisions',
				'custom-fields',
			],
		]
	);
}

function late_register_cpts() {
	register_post_type(
		'late-cpt-with-fns',
		[
			'public' => true,
			'show_in_rest' => true,
			'labels' => [
				'name'          => 'Late CPT Supporting Footnotes',
				'singular_name' => 'Late CPT Supporting Footnote',
				'plural_name'   => 'Late CPTs Supporting Footnotes',
			],
			'supports' => [
				'title',
				'editor',
				'revisions',
				'custom-fields',
			],
		]
	);
}

Environment info

• WordPress Editor Merge PR: Editor: Initial WordPress package updates for 6.5 wordpress-develop#5922
• Gutenberg: Inactive
• Plugins
  • Query Monitor
  • Code snippet above

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

[peterwilsoncc]

I've created WordPress/wordpress-develop#6043 for making the footnotes feature opt-in.

Currently all supports features for post types are opt-in. While the supports attribute has a default value (title, editor), developers defining the supports property need to opt-in to the defaults.

WordPress has never added a new post type feature that is opt-out. as doing so requires developers run register_post_type(); remove_post_type_support(). Unless requiring a new supports value to be opt-in would break BC, I think we need to continue this long term practice.

I haven't created a GB version of the PR as I wanted to make sure the WordPress-Develop PR didn't hit the order of operations issue above when runninng the plugin.

cc @hellofromtonya

[hellofromtonya]

Currently all supports features for post types are opt-in. While the supports attribute has a default value (title, editor), developers defining the supports property need to opt-in to the defaults.

WordPress has never added a new post type feature that is opt-out. as doing so requires developers run register_post_type(); remove_post_type_support(). Unless requiring a new supports value to be opt-in would break BC, I think we need to continue this long term practice.

I agree with @peterwilsoncc. Supports should continue to be opt-in, not opt-out. In other words, what is configured in a post type's supports should be respected.

[youknowriad]

As far as I know this has been addressed already. can you confirm?

Also removing this from 6.5 as today is RC1.

[peterwilsoncc]

As far as I know this has been addressed already. can you confirm?

Yes, that's correct. The meta is now registered at init,20 so catches CPTs in wp-dev registered on the default hook.

I'm closing this as completed should it be moved to the done column on the board?

Edit: Heh, I guess the bot answered my question. Thanks bot, no AI needed :)