Update: Footnotes support for custom post types to be support based.

[jorgefilipecosta]

Update to #57353.
Fixes: #58341
Alternative to #58343.

Follows @mcsf suggestion in #57353 (comment) and makes footnotes have their own supports key.
By default, every post that meets footnotes requirements has support for footnotes.
Developers can now remove footnotes support with:

remove_post_type_support( 'my_type', 'footnotes' );

cc: @mcsf, @peterwilsoncc, @ellatrix

Testing

Added the following post type:

function cptui_register_my_cpts_testfootnotes() {

	/**
	 * Post Type: Test foot notes.
	 */

	$labels = [
		"name" => esc_html__( "Test foot notes", "twentytwentyfour" ),
		"singular_name" => esc_html__( "Test foot note", "twentytwentyfour" ),
	];

	$args = [
		"label" => esc_html__( "Test foot notes", "twentytwentyfour" ),
		"labels" => $labels,
		"description" => "",
		"public" => true,
		"publicly_queryable" => true,
		"show_ui" => true,
		"show_in_rest" => true,
		"rest_base" => "",
		"rest_controller_class" => "WP_REST_Posts_Controller",
		"rest_namespace" => "wp/v2",
		"has_archive" => false,
		"show_in_menu" => true,
		"show_in_nav_menus" => true,
		"delete_with_user" => false,
		"exclude_from_search" => false,
		"capability_type" => "post",
		"map_meta_cap" => true,
		"hierarchical" => false,
		"can_export" => false,
		"rewrite" => [ "slug" => "testfootnotes", "with_front" => true ],
		"query_var" => true,
		"supports" => [ "title", "editor", "thumbnail", "custom-fields", "revisions" ],
		"show_in_graphql" => false,
	];

	register_post_type( "testfootnotes", $args );
}

add_action( 'init', 'cptui_register_my_cpts_testfootnotes' );

I have confirmed that the footnotes are functioning correctly on the specified post type.

Furthermore, I have removed the "custom-fields" support from the post type and confirmed that the footnotes are no longer available on the post type.

In addition, I have verified that remove_post_type_support( 'page', 'footnotes' ); successfully removes footnotes support from pages.

[github-actions]

This pull request has changed or added PHP files. Please confirm whether these changes need to be synced to WordPress Core, and therefore featured in the next release of WordPress.

If so, it is recommended to create a new Trac ticket and submit a pull request to the WordPress Core Github repository soon after this pull request is merged.

If you're unsure, you can always ask for help in the #core-editor channel in WordPress Slack.

Thank you! ❤️

View changed files

❔ lib/blocks.php

[peterwilsoncc]

I think this is a much nicer approach.

To ensure it doesn't hit the order of operations issue in #58341 once it's merged in to WordPress-Develop, are you able to hack the relevant file in WordPress and test it without Gutenberg active?

[peterwilsoncc]

A note explaining this runs late to allow for plugins registering post types would be helpful here.

@spacedmonkey @TimothyBJacobs does init, 100 run in the REST API or does rest_api_init exit beforehand on init, 10?

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Core SVN

Core Committers: Use this line as a base for the props when committing in SVN:

Props jorgefilipecosta, mcsf, peterwilsoncc, ellatrix, hellofromtonya.

GitHub Merge commits

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: jorgefilipecosta <[email protected]>
Co-authored-by: mcsf <[email protected]>
Co-authored-by: peterwilsoncc <[email protected]>
Co-authored-by: ellatrix <[email protected]>
Co-authored-by: hellofromtonya <[email protected]>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[peterwilsoncc]

Having sat on this for a while...

I think it might be better to require developers opt-in (either via supports => footnotes or add_post_type_support().

Making it opt-out will require extenders not wishing to support footnotes register their CPTs with the following code. Due to WP's commitment to back compat, we'll be stuck with it.

register_post_type( 'my_cpt', $args );
remove_post_type_support( 'my_cpt', 'footnotes' );

Making it opt-in will require extenders wanting to support footnotes make a single code change to registering their post types. Versions of WP that don't support footnotes will simply ignore the feature.

I think I suggested making it opt-out initially, sorry about that.

[ellatrix]

Tbh, I think as footnotes as just content and it should remain opt-out. The footnotes meta is just an implementation detail, we might as well have stored footnotes in the post content field. Footnotes should imo be thought of as any other block, which you can disable (globally or per post type) with the current block APIs and filters. For really advanced cases where you really don't want the meta to be registered, you can deregister meta and then footnotes will also get disabled without error, but I don't think it should be the way to do it, nor do I think we should move this into post type supports.

Btw, we might even have an option in the future where footnotes just get saved to the post content if there's no meta field, which is useful for example in standalone GB instances.

[jorgefilipecosta]

It is a good point @ellatrix, I guess it makes sense to not treat footnotes differently from any other block. So the way to disable footnotes in a post type would be:

add_filter( 'allowed_block_types_all', 'footnotes_allowed_block_types', 10, 2 );
 
function footnotes_allowed_block_types( $allowed_blocks, $editor_context ) {
    if( 'post' === $editor_context->post->post_type ) {
		$allowed_blocks_array = array();
		if ( is_array( $allowed_blocks )) {
			$allowed_blocks_array = $allowed_blocks;
		} else if( $allowed_blocks === false ) {
			return false;
		} else if ($allowed_blocks === true ) {
			$block_types = WP_Block_Type_Registry::get_instance()->get_all_registered();
			foreach( $block_types as $block_type) {
    			$allowed_blocks_array[] = $block_type->name;
			}
		}
	
        $allowed_blocks = array_values( array_diff( $allowed_blocks_array, array(
        'core/footnotes',
        ) ) );
    }
    return $allowed_blocks;
}

The same code can be used to disable any other block in a specific post type.

There was a bug where the disabling of the format was not working as expected that I'm fixing at #58855.

Following your suggestion I'm going to close this PR.

[peterwilsoncc]

Making them opt-out via the block APIs works for me as blocks are already opt-out.

[mcsf]

Tbh, I think as footnotes as just content and it should remain opt-out. The footnotes meta is just an implementation detail, we might as well have stored footnotes in the post content field. Footnotes should imo be thought of as any other block, which you can disable (globally or per post type) with the current block APIs and filters. For really advanced cases where you really don't want the meta to be registered, you can deregister meta and then footnotes will also get disabled without error, but I don't think it should be the way to do it, nor do I think we should move this into post type supports.

Btw, we might even have an option in the future where footnotes just get saved to the post content if there's no meta field, which is useful for example in standalone GB instances.

This all makes sense to me too, I've flipped my opinion on the matter. 👍