Hide footnotes block from the inserter

[richtabor]

What?

Adding the block within the editor adds an empty placeholder, whereas the actual action of adding a footnote via the block toolbar formats control is when a footnote is added to the post. I propose we remove the Footnotes block from the inserter.

The block will still be appended to the content if a footnote is added, you just can't insert an empty footnotes block (which is a good thing).

Testing Instructions

1. Open a post or page.
2. Search for the footnotes block. -->
3. See no local results.
4. Add paragraph text.
5. Create a footnote via the formats control.
6. See footnotes block rendered below the content.

Screenshots or screencast

Before	After

[fabiankaegy]

I've not tested this so maybe it isn't even possible. But couldn't one add the footnotes block to a block template/template part for it to render the footnotes of the current post if they are set?

For that use case the block would need to be insertable?

If we already don't expose the block there / have something in place that prevents the block from getting used in a template this makes sense to me. Otherwise I would say it should stay visible in the inserter :)

---

Edit:

I have now tested it and whilst the block does show a notice when inserted in a template / template part it is working and behaving as expected 🤔

But it is rather confusing because you would want to remove the footnotes block from in content but need to leave it there till you are done editing all the footnotes... So for that alone it probably makes sense to remove it for now...

[github-actions]

Flaky tests detected in 9e0ce33.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/6410070093
📝 Reported issues:

• [Flaky Test] should partially select with shift + click (@webkit) #53524 in /test/e2e/specs/editor/various/multi-block-selection.spec.js

[richtabor]

But it is rather confusing because you would want to remove the footnotes block from in content but need to leave it there till you are done editing all the footnotes... So for that alone it probably makes sense to remove it for now...

Yea if the footnotes aren't added to the post content (at least for now), then you can't edit them. Interesting.

[jasmussen]

I would agree, it seems like a recipe for confusion to have the footnotes block available, and that the "inserter": false option exists for cases like these.

[youknowriad]

I'm not sure I agree with this change personally. If you want to put the block in a given position in the "single" template for instance, you should be able to do so (and remove the block from post content)

[richtabor]

I'm not sure I agree with this change personally. If you want to put the block in a given position in the "single" template for instance, you should be able to do so (and remove the block from post content)

But then you can't edit the footnote.

[Mamaduka]

I suggested the same during the WP 6.3 release cycle. Enabling the inserter was intentional. Ref: #52812 (comment).

[youknowriad]

I think we discussed with @ellatrix that we should allow inline editing of the footnotes as well (like in a dropdown or something) for these cases.

[jasmussen]

Apologies for missing this context. To be sure I understand this correctly, this is about ensuring you can position where the footnotes show up when you're building a template? Yes, that's valid, though I wonder, can we hide the block when you're not in the site editor?

[ellatrix]

We specifically enabled this in the inserter in #52445 after feedback (it was originally hidden).

[mikachan]

👋 Just checking if this PR should be backported to 6.4, as I noticed there was continued discussion after it was merged.

[richtabor]

Yes, that's valid, though I wonder, can we hide the block when you're not in the site editor?

I don't think we can specify editors in block.json, right?

[jasmussen]

👋 Just checking if this PR should be backported to 6.4, as I noticed there was continued discussion after it was merged.

Probably not, given the same discussion.

[mikachan]

Probably not, given the same discussion.

Thanks @jasmussen. I'll keep my eye on the discussion and cherry-pick if/when possible.