Meta Boxes: Support the "after_title" context

[thatdevgirl]

Issue Overview

I would love to see support for the after_title meta box context in Gutenberg. This context is currently supported in the classic editor, placing meta boxes after the page title (but before the editor).

Right now, when I create a meta box using the after_title context (or any context that is not supported in Gutenberg; i.e.normal or advanced), the meta box does not appear on the page at all. I am using the Gutenberg plugin and creating meta boxes with the Meta Box plugin. I understand from the Meta Box plugin author is that any other contexts are unsupported by Gutenberg; he recommended that we not use contexts at all.

I am advocating for supporting the after_title context because there can be cases where the content in a meta box is meant to appear before the content in the post editor on the front-end. Having the meta box appear above the post editor on the edit screen is ideal from a UX perspective, because it will allow content editors to edit the page in order. If all of the meta boxes appear below the post editor in the edit screen, a content editor may be confused as to where to find a particular meta box if they are used to seeing its content above the main body of the page (on the front-end).

Steps to Reproduce

1. Create a meta box with the after_title context. (Again, I was using the Meta Box plugin to create meta boxes, but I suspect the outcome will be similar regardless of how the meta box is created.)
2. View the page edit screen with the Gutenberg editor.

Expected Behavior

I should see the meta box below the page title and above the post editor.

Current Behavior

The meta box does not appear at all.

[youknowriad]

I looked at this a bit and it looks like after_title is not a supported meta box location in WordPress.

Plugins hack the post editor to add it.

[benhuson]

Having inserted fields myself into that area, it is done using the edit_form_after_title action hook which fires between the title and the editor.

It doesn't specifically output meta boxes but can be used to output ANY content into this area.

I'm not sure how that hook could be used within the framework of the Gutenberg editor?

[youknowriad]

We may consider supporting this hook yes :) edit_form_after_title. Thoughts @mtias @aduth

[aduth]

It's something of a design consideration as well.

I think it could be reasonable to support, but more for backwards-compatibility so as not to break existing workflows, and maybe not as a first-class support; i.e. not necessarily located under title, but grouped with meta boxes.

[danielbachhuber]

@thatdevgirl Just to clarify, did you mean edit_form_after_title in your original report? Or is there some other after_title aspect we should be aware of?

[thatdevgirl]

@danielbachhuber I did mean edit_form_after_title. I've been using the Meta Box plugin and they call that context after_title (I guess they're simplifying the name for their users?).

[danielbachhuber]

@thatdevgirl Makes sense, thanks! Moving to the Back Compat milestone to evaluate there.

[bianqui149]

Hi! I have a similar issue, any update?

[Soean]

@bianqui149 Not yet. If we have an update, we will post it here.

[eriktdesign]

I have a bunch of client sites that rely on this hook to render meta boxes. +1 for supporting in some way.

[krisgale-zz]

Definitely had need of it also, and was disappointed to find it (like so many other previously-functional actions/filters) no longer works.

[mgcd]

Because of this removal the GDPR privacy policy help:-

"Need help putting together your new Privacy Policy page? Check out our guide (opens in a new tab) for recommendations on what content to include, along with policies suggested by your plugins and theme."

which appears before the "editor" (so the ideal place) with Classic just doesn't appear at all with Gutenberg active. Since it breaks Wordpress itself hopefully an equivalent will be forthcoming.

[danielbachhuber]

@matias Can we get a decision on this issue (either to support the after_title action or not)? Or, if we can't make a decision yet, can we get clarity on the decision-making criteria so we can help track down the information we need to make a decision?

[elliotcondon]

Any news on this?

[Jonnyauk]

+1 on this please - it would be VERY useful to have a after_title() hook available, we sometimes insert our own controls/info/bits up there for header options etc in our bespoke theme builds in the editor!

If this is going to get supported (which is should IMHO - many bespoke theme developers need this!!) why not add an additional before_editor_title() hook too ;)

Also worth noting to test support that hook still triggers if remove_post_type_support( $post_type, 'title' ); is deployed.

[mtias]

This is a tricky area because we don't want to set expectations for accessing edit_form_after_title that would be immediately invalidated as soon as the post tile becomes a block (and part of the editor flow) in the next phase. At that point all the canvas will have the expectation of visually matching the front.

[desrosj]

Because of this removal the GDPR privacy policy help which appears before the "editor" with Classic just doesn't appear at all with Gutenberg active.

@mgcd To follow up on this specific instance, this has now been resolved in #11999. The fix has also been committed to WordPress Core, and there is a PR on the Classic Editor plugin to maintain the current 4.9.x behavior when that plugin is active.

The notice now appears correctly as of Gutenberg 4.5, and will in Core as of the next Beta/RC release.

[musus]

Hi, I have a similar issue, any news?

[eyesofjeremy]

I agree that having the ability to target this area makes sense, as sometimes I need to set up client instruction, and it's best to have it front and center.

That said, could this be supported ONLY above the title, rather than after it? I get the point @mtias makes about having the title look like it's part of the flow with the rest of the content.

[thatdevgirl]

I like the idea of supporting this only above the title. So, maybe it should really be a before_title context? (Because, semantics.)

The use case for having a meta box in the after_title context that I usually deal with does not display the title at all on the front-end because it tends to be a landing page where content in the after_title is a full-width hero block in the designs and the title is not actually displayed on the page. But, if a title were to be displayed on the page, I would want it to be after that hero block anyway. (Disclaimer: I'm definitely not a designer.)

[eyesofjeremy]

If you're creating content that's displayed on the front end, I'd think maybe the "Gutenberg" way would be to create a block for it. But perhaps that is too flexible? Would there be a way to create a block which (a) can only be the first block on the page, and (b) can only occur once?

If it's directly presentational, I wouldn't necessarily expect traction on this context. That said, metaboxes can represent all kinds of things. In my case, I want to offer back-end only help info for the editor which needs to come before they start editing, and I'd like to offer the possibility of using the block editor.

I think ultimately that's the point we're all getting at — we have different reasons for wanting to target that area in the editor screen, and there should be a way to continue to target it. Just my $.02...

[mtias]

Handling content before / after the title is definitely a use case that needs to be supported, but it should be done through the block tree natively. The main issue to follow there is #16281 about expanding the editor beyond post_content.

[joshdavenport]

We often create templates for our clients where majority (but not all) of the pages is powered by block editor output, but aspects of the template are configured by fields in a metabox.

For example, the content of the page is from block editor but the header has options available on every page (header style 1, header style 2, header subtitle, etc etc) so it really sucks not being able to put metaboxes before the editor where it is helpful for a mental image of the template to do so.

We could dictate a particular block has to always be on the page that powers this header area, but then we'd lose the rigidity won by providing templates that dictate certain parts of the layout, with obviously great flexibility added after that with the block editor. We could still have a template-powered header and look for a particular block to grab the info, but then the admin would have to know every time they have to add this particular block in order to customise the header.

In that header customisation meta-box the ideal flow would be

• Page title
• Header metabox
• Block editor
• Other metaboxes

That somewhat matches how the frontend behaves, so is a nice admin UX. But instead it has to be:

• Page title
• Block editor
• Header metabox
• Other metaboxes

Kinda sucks! I realise this kind of old-school/new-school edge case is pretty niche, but it would just be so nice to be able to put metaboxes in those areas previously available.