Footnotes: ensure compatibility with Custom Post Types

[bridgetwes]

Description

Bug Report

Description

I could not get footnotes to work in Custom Post Types in my testing. I used ACF Pro to create a quick custom post type, then set up some content in a new post of the custom post type. When I select "Footnote" in the paragraph toolbar (using WP 6.3 RC 1), it behaves differently than it does in Pages, and I can't set the footnote text in the Footnote block that is automatically added to the end of the content in the custom post type.

(This is my first time posting a bug report so let me know if I need to do something differently. I checked, but could not find this issue reported in github or https://core.trac.wordpress.org/tickets/major.)

Step-by-step reproduction instructions

Steps to Reproduce

1. Try to add a footnote in paragraph block of a custom post type using the new Footnote feature in the paragraph toolbar in WP 6.3 RC 1.
2. 🐞 Bug occurs.

Expected Results

1. ✅ A Footnote block should be added to the bottom of the content blocks, with a place to set your footnote text. When Footnote is selected in the paragraph toolbar menu, you should be taken down to the footnote block.

Actual Results

1. ❌ Footnote block gets added but there is no place to set your footnote text (see attached video). You are also not moved down all the way to the footnote block. Footnotes work fine on this site when adding them to pages. Just Custom Post Types behave this way.

Screenshots, screen recording, code snippet

Environment info

Environment

• WordPress: 6.3-RC1
• PHP: 8.0.22
• Server: nginx/1.16.0
• Database: mysqli (Server: 8.0.16 / Client: mysqlnd 8.0.22)
• Browser: Firefox 115.0 (Windows 10/11)
• Theme: Twenty Twenty-Three 1.1
• MU-Plugins: None activated
• Plugins:
  • Advanced Custom Fields PRO 6.1.7
  • Create Block Theme 1.13.1
  • WordPress Beta Tester 3.5.2

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

[ramonjd]

Thanks for reporting!

I can replicate this. The footnotes block only supports post and page types at the moment:

gutenberg/packages/block-library/src/footnotes/index.php

Line 62 in f2a685f

foreach ( array( 'post', 'page' ) as $post_type ) {

I was using this code to create a custom post type:

Example custom post type

function my_custom_post_type_dogfood() {
	$supports = array(
		'title',
		'editor',
		'author',
		'thumbnail',
		'excerpt',
		'custom-fields',
		'comments',
		'revisions',
		'post-formats',
	);
	$labels   = array(
		'name'           => _x( 'dogfoods', 'plural', 'gutenberg' ),
		'singular_name'  => _x( 'dogfood', 'singular', 'gutenberg' ),
		'menu_name'      => _x( 'dogfood', 'admin menu', 'gutenberg' ),
		'name_admin_bar' => _x( 'dogfood', 'admin bar', 'gutenberg' ),
		'add_new'        => _x( 'Add New', 'add new', 'gutenberg' ),
		'add_new_item'   => __( 'Add New dogfood', 'gutenberg' ),
		'new_item'       => __( 'New dogfood', 'gutenberg' ),
		'edit_item'      => __( 'Edit dogfood', 'gutenberg' ),
		'view_item'      => __( 'View dogfood', 'gutenberg' ),
		'all_items'      => __( 'All dogfood', 'gutenberg' ),
		'search_items'   => __( 'Search dogfood', 'gutenberg' ),
		'not_found'      => __( 'No dogfood found.', 'gutenberg' ),
	);
	$args     = array(
		'supports'     => $supports,
		'labels'       => $labels,
		'public'       => true,
		'query_var'    => true,
		'rewrite'      => array( 'slug' => 'dogfood' ),
		'has_archive'  => true,
		'show_in_rest' => true,
		'hierarchical' => false,
	);
	register_post_type( 'dogfood', $args );
}
add_action( 'init', 'my_custom_post_type_dogfood' );

@ellatrix What do you reckon about invoking filter callbacks here via apply_filters? 🤷🏻

E.g., Something like

function register_block_core_footnotes() {
	/**
	 * Filters to edit the list of post types that permit footnotes.
	 *
	 * @since 6.3.0
	 *
	 * @param string[] $post_types Block name.
	 */
	$post_types = (array) apply_filters( 'block_core_footnotes_post_types', array( 'post', 'page' ) );

	foreach ( $post_types as $post_type ) {
		register_post_meta(
			$post_type,
			'footnotes',

[ramonjd]

Moved to 6.3 tasks board. Initial thought is that it's an enhancement not a bug per se. Let's see.

[ramonjd]

@andrewserong thought of the following:

maybe ... hide it in the inserter if it’s an unsupported post type?

[Mamaduka]

Registering the meta should enable Footnotes for the post type; at least, that's what I remember from the original PR - #51201 (comment). I think this will be mentioned in Docs and DevNote.

I think we can do a following for the post types that haven't opted-in the Footnotes:

• Don't render the format button/handler.
• Hide the footnotes block from the inserter. Don't let users manually insert it. The block will be auto-inserter when there's a footnote.

What do you think?

cc @ellatrix

register_post_meta(
	'dogfood',
	'footnotes',
	array(
		'show_in_rest' => true,
		'single'       => true,
		'type'         => 'string',
	)
);

[ellatrix]

It sounds fine, though I feel like requiring plugins to register the same meta is a bit too low level and duplicative (what if the settings change in the future?)

Maybe we should use https://developer.wordpress.org/reference/functions/post_type_supports/?

[Mamaduka]

That's better, and we'll avoid exposing the implementation details.

We could also pass post-type support as block editor settings for post types and skip Footnotes registration when it's not supported, just like - #52823.

[ellatrix]

Or should we just add footnotes to all post types that support editor?
I mean, why not? If we weren’t using post meta, it would be available in all posts with an editor…
And if you don’t want footnotes, maybe disabling the block should be the mechanism to disable footnotes altogether.

[Mamaduka]

Sounds like a big shift for RCs, IMO.

And if you don’t want footnotes, maybe disabling the block should be the mechanism to disable footnotes altogether.

Currently, we don't have this mechanism in place, and people can disable the block in various ways. We'll have to account for all of them.

[ramonjd]

Maybe we should use https://developer.wordpress.org/reference/functions/post_type_supports

Oh, much better! 😀

[ndiego]

For 6.3, is there a way to simply remove the Footnotes option from the inserter for unsupported custom post types?

[Mamaduka]

I suggested disabling the inserter for the Footnotes block. It's an inserter programmatically when a footnote is added, and the block is missing from the content. Adding it via inserter when content has no footnotes feels odd, IMO. Happy to provide PR for it.

We also need to disable Footnote rich text format when CPT doesn't support the feature.

[ramonjd]

We also need to disable Footnote rich text format when CPT doesn't support the feature.

What about adding "footnotes" to the post type object supports array (via register_post_type_args)?

Then we'd be able to filter support by get_post_types_by_support( 'footnotes' ). Not sure there's an equivalent in JS, but select( coreStore ).getPostTypes returns enough information I believe.

The only tricky thing that was beyond me was to grab the postType in the format callback. I suppose we could unregisterFormatType elsewhere? I'm not yet familiar enough with it to make a call.

Sorry if this has muddied the water even further.

[ellatrix]

@Mamaduka I disagree with removing from the inserter, we specifically added support in Footnotes: show in inserter and placeholder.

[Mamaduka]

@ellatrix, I wasn't aware of that. Do you mind correcting the URL? It points to this issue.

[mcsf]

I'm leaning towards only supporting post and page types in 6.3, given how late we are in the cycle. Think of it as a soft release. :) In that scenario, the appropriate fix would be to prevent the registration of the footnotes inline format when the post type isn't supported — much like we prevent the registration of the footnotes block type.

[Mamaduka]

I'm leaning towards only supporting post and page types in 6.3, given how late we are in the cycle.

I agree that this is a good middle ground based on where we're in the WP 6.3 cycle.

In that scenario, the appropriate fix would be to prevent the registration of the footnotes inline format when the post type isn't supported — much like we prevent the registration of the footnotes block type.

We don't have anything in place for this. But I guess it can be hardcoded for now. We could skip block and format registration during the editor init. Here's my PoC for the Site Editor - #52823.

[ellatrix]

Temporary fix: Footnotes: disable based on post type

[tellthemachines]

Are we good to close this or shall we leave it open until it's addressed in a more permanent way?

[mcsf]

Not having an explanation in the placeholder is a shame, but there was not much we could do after string freeze. So I would say close this issue and move on. :)

[mcsf]

However, I see the issue has been removed from the 6.3 project board, which is good. So, if keeping this one open helps people find these decisions more easily, that's also fair.

[t-hamano]

As this comment suggests, until an ideal solution is found, I think it might be a good idea to add a description at a time when a block is inserted in a custom post type.

gutenberg/packages/block-library/src/footnotes/edit.js

Line 26 in a8eead8

// To do: add instructions. We can't add new string in RC.

[annezazu]

I wanted to follow up here to add more context to why this was punted to 6.5 and where this currently stands. For now, footnotes remain only available in post and pages per this PR merged into 6.3. This is mainly due to the fact that work around revisions took priority and time ran out to pursue this further for 6.4.

The stage is set for 6.5 though to enable everything at that time! In the meantime, work can be done to get it in place in Gutenberg plugin as well. For anyone keen to see this feature in place then, please help test at that time. Any amount of testing and feedback early and often helps ensure a feature has the greatest chance of landing outside of the usual Core processes.

cc @shirokoweb as I see you left a comment here and want to be sure you can see my response.

[dpellenwood]

Thank you for the update @annezazu . To clarify, are Footnotes enabled for custom post types in the Gutenberg plugin already? Or, is there a separate ticket/task tracking that work? It would be great to follow that conversation or possibly even help out with the work if that is possible.

[annezazu]

Noting this PR that seeks to address this: #57353

[annezazu]

Closing out as this PR has been merged 🥳 #57353