Consider optional wysiwyg above title

[mfolkeseth]

Issue Overview

Some articles have rich content, video, image, etc above the article title. I would like to hear your thoughts on adding a wysiwyg, single or multiple blocks above the title area.

We already have the featured image, but I was thinking about the ability to have other types of content. It will also give the possibility to distinguish media on the front page and article itself. It may also help the users workflow and experience as the whole article will be made in the main content area and separate it from the side bar completely.

Expected Behavior

Have wysiwyg, single or multiple blocks above title

Current Behavior

None

Possible Solution

Add wysiwyg, single or multiple blocks above title

[mtias]

This will be the case with step 2 (page templates) onwards as it looks beyond post_content, but it's not planned for the editor version to land in 5.0. Eventually, the title, the date, the author, etc, will all just be blocks you can place in whatever order around the content.

[jasonbahl]

I feel like every day I read conflicting things about the "scope" of this project. . .this response indicates that the version targeted for 5.0 is scoped to just post_content and that having blocks beyond post_content will come in a later version. . .but Gutenberg already hijacks interfaces for interacting with meta, terms, etc. Gutenberg already has introduced blocks that save outside of a post's post_content.

If we're being encouraged to move our metaboxes to blocks, and have a "block" mentality for content creation, etc then this seems like an important piece to that.

If you do want to try somehow to pretend the scope is just related to post_content, then at least move the title out of the canvas where blocks are interacted with and over into the Document inspector as it's a confusing experience to have one locked block for the title while trying to edit the rest of your page visually.

That way folks can at least control where the title shows (via dynamic block?) within their page content.

The title isn't always the first element displayed on a theme, so the editor shouldn't make it appear as if that's the case.

Also, side note, but having to select the title to find the permalink seems way out of place as well. Makes much more sense to be in the Document inspector as it's really an attribute of the Document, not the content.

[ZebulanStanphill]

Disclaimer: I am not a WordPress or Gutenberg developer.

@jasonbahl I think what @mtias means is that the ability to use blocks in non post_content areas is not coming until after WordPress 5.0. Yes, blocks can access meta attributes and display them, but those blocks are being used within the post_content area. And yes, the Gutenberg editor includes the ability to edit the categories and tags of a post. But those are non-visual attributes of the page. If they are shown on the page (inside or outside of post_content) then they are shown via something that is not the tags or categories themselves, but by a container that pulls its data from those taxonomies. Content above the title of a post is not in post_content, so you cannot edit it using blocks yet, nor can you edit the areas shown below post_content on a page.

Trying to add this functionality requires considering how the editing experience would work for non-post-content areas. If you wanted to edit the footer of your website, would there be an instance of the editor containing just the footer? Would that instance include some placeholder stuff above it to represent the other parts of the page? Would you edit the header, footer, sidebar, and their layout relative to each other from the same editor page? How would different page templates be edited and where would they be listed?

As you can see, this gets really complicated really quickly, and I can see why it is not being worked on for the 5.0 release.

As far as I can tell, there is no conflict about the scope of the Gutenberg project regarding how it interacts with stuff not in post_content. This issue is asking about displayed content outside of post_content, and that is the thing that can not be done yet, due to the complicated UI/UX and backend API decisions that have to be made to accomplish that. Gutenberg can access data from outside post_content, but it is still being used inside post_content.

[afercia]

Also, side note, but having to select the title to find the permalink seems way out of place as well. Makes much more sense to be in the Document inspector as it's really an attribute of the Document, not the content.

Re: the permalink UI, it's also an accessibility issue, see #5494. @jasonbahl and everyone: any thoughts there would be greatly appreciated 🙂

[mcsf]

Thanks for bringing this up. @SuperGeniusZeb pretty much summed up the rationale for 5.0 and the post_content scope. :)

@jasonbahl, I'm sorry to hear that it has come across that there have been scoping conflicts when it comes to this piece of Gutenberg. If it's any consolation, sticking to post_content as always been the focus for Gutenberg. Term and metabox support are part of the essential backwards compatibility requirements, and I see things like meta-sourced block attributes as simultaneously:

• providing some extra tooling for transitional support for third parties (e.g. I'd like to port my post-specific metabox or custom field to a block as soon as possible without changing the way its data is saved or used in the front-end);
• giving core developers a glimpse of the post-5.0 editor, to check if all the pieces are lining up as planned.

If you do want to try somehow to pretend the scope is just related to post_content, then at least move the title out of the canvas where blocks are interacted with and over into the Document inspector as [emphasis mine] it's a confusing experience to have one locked block for the title while trying to edit the rest of your page visually.

This to me is more of a design issue than a scoping one. I'm going to close this particular issue in order to keep things trimmed for 5.0, but feel free to open one on the UI of title vs. content.

[designsimply]

Closed #9854 in order to consolidate here and noting the suggestion to add formatting options:

There does not appear to be any formatting options for the main default headline of a document (e.g. Bold, italics), please make the headline formatable like the subheads.