Auto Draft title issue for custom post types

[rajanit2000]

I have register post type without title support

$labels = array(
	'name'               => _x( 'Social posts', 'post type general name', 'text-domain' ),
	'singular_name'      => _x( 'Social post', 'post type singular name', 'text-domain' ),
	'menu_name'          => _x( 'Social posts', 'admin menu', 'text-domain' ),
	'name_admin_bar'     => _x( 'Social post', 'add new on admin bar', 'text-domain' ),
	'add_new'            => _x( 'Add New', 'social-post', 'text-domain' ),
	'add_new_item'       => __( 'Add New Social post', 'text-domain' ),
	'new_item'           => __( 'New Social post', 'text-domain' ),
	'edit_item'          => __( 'Edit Social post', 'text-domain' ),
	'view_item'          => __( 'View Social post', 'text-domain' ),
	'all_items'          => __( 'All Social posts', 'text-domain' ),
	'search_items'       => __( 'Search Social posts', 'text-domain' ),
	'parent_item_colon'  => __( 'Parent Social posts:', 'text-domain' ),
	'not_found'          => __( 'No social-posts found.', 'text-domain' ),
	'not_found_in_trash' => __( 'No social-posts found in Trash.', 'text-domain' )
);
$args = array(
	'labels'             => $labels,
	'description'        => __( 'Description.', 'text-domain' ),
	'public'             => true,
	'publicly_queryable' => true,
	'show_ui'            => true,
	'show_in_menu'       => true,
	'query_var'          => true,
	'rewrite'            => array( 'slug' => 'social-post' ),
	'capability_type'    => 'post',
	'has_archive'        => true,
	'hierarchical'       => false,
	'menu_position'      => 10,
	'menu_icon'          => 'dashicons-id',
	'delete_with_user'   => true,
	'can_export'         => true,
	'show_in_rest'       => true,
	'supports'           => array( 'editor' )
);
register_post_type( 'social-post', $args );

And if i add post the list post page shows title as "Auto Draft"

[rajanit2000]

Add default title option

[nrqsnchz]

Hi @rajanit2000!

Would you mind clarifying what the issue is?
Is the fact that the list post page shows the title as "Auto Draft" a bug? Where you expecting something else?

[rajanit2000]

I have registered a new post type and its only support "editor" using this code

'supports'           => array( 'editor' )

And create a post in this post type and published it. But the listing page only shows the title is "Auto Draft"

Does it make sense?

Refer my screen record
​https://www.loom.com/share/ebadb2bd8f934c20bc96d1841bef04f8

[nrqsnchz]

But the listing page only shows the title is "Auto Draft"

@rajanit2000 What title were you expecting to see?

[rajanit2000]

@nrqsnchz I think "No Title" is the better word

[SergeyBiryukov]

Related: #29320

[garrett-eclipse]

Thanks @rajanit2000 the patch looks good. Discussing in ​#design Slack (A WordPress.org slack account is required to view that link) today and the idea of making the string a customizable label when registering the post type seems like it could have some merit. Going to switch this from ui-feedback to 2nd-opinion to get thoughts on if having it be a customizable label makes sense or if just going with '(no title)' here is the extent we want to go here.

[donmhico]

Thanks for the ticket @rajanit2000. I'm no longer able to reproduce the issue. I can't find the exact Changeset at the moment. But what I can tell is that class-wp-posts-list-table.php - https://core.trac.wordpress.org/browser/tags/5.2/src/wp-admin/includes/class-wp-posts-list-table.php#L1007 - uses _draft_or_post_title() - ​https://developer.wordpress.org/reference/functions/_draft_or_post_title/ - to determine the title displayed in wp-admin/edit.php.

I used the same code as you provided above to create a custom post type without title support. And what I tried to create a post. This is what I can see - https://core.trac.wordpress.org/attachment/ticket/45516/Screen%20Shot%202019-08-22%20at%203.46.40%20PM.png

[garrett-eclipse]

Thanks @donmhico for testing, I ran through myself and was able to reproduce the issue on Trunk w/ Twenty Twenty and the code provided in the description. Looking at the code base when you go to add a post it creates the auto-draft w/ title of 'Auto-Draft'. Reviewing code there's a few ways you can avoid the auto-draft such as disabling the functionality or providing a post_title on the request, you can also avoid it by programatically creating the post. @donmhico maybe you circumvented it somehow, would you mind retesting on trunk and confirm you are or aren't seeing the issue now.

As there's some work to be done here and a decision needed on behaviour I'm going to move this into 5.4 to address there as we're already in beta2 for 5.3.

The item requiring 2nd-opinion is;
"Going to switch this from ui-feedback to 2nd-opinion to get thoughts on if having it be a customizable label makes sense or if just going with '(no title)' here is the extent we want to go here."
@SergeyBiryukov do you have any thoughts on a customizable label or just using (no title)?

[donmhico]

@garrett-eclipse - I used a fresh installation using the trunk after you get my attention to re-test and:

1. I was able to reproduce the error now.
2. The fix still applies cleanly.

Regarding the use of '(no title)', maybe we can use something like '(Not supported)' or '(Not applicable)' instead? Creating a post without a title in a post types that support titles uses '(no title)' which indicates that the post has no title but can have a title. So using a label that indicates that title isn't supported on post types that doesn't support it seems like a better idea. What do you guys think?

[garrett-eclipse]

Thanks @donmhico for confirming, and I agree it is a little misleading which may be a reason to go with the custom label option there. Leaving open for opinion and marking for some copy-review would be nice to get thoughts on an alternative to (no title) in the cases the post type doesn't support titles.

[rajanit2000]

When this ticket will be solved?

[garrett-eclipse]

Hi @rajanit2000 I milestoned this into 5.4 and hope it is addressed within that release. It's currently awaiting a 2nd-opinion and needs-copy-review which will hopefully come once devs start working through the 5.4 milestone.
*In hopes of getting a copy-review going to ping @marybaum

Mary, the part specific to copy review;
'would be nice to get thoughts on an alternative to (no title) in the cases the post type doesn't support titles.'

[marybaum]

Replying to garrett-eclipse:

Hi @rajanit2000 I milestoned this into 5.4 and hope it is addressed within that release. It's currently awaiting a 2nd-opinion and needs-copy-review which will hopefully come once devs start working through the 5.4 milestone.
*In hopes of getting a copy-review going to ping @marybaum

Mary, the part specific to copy review;
'would be nice to get thoughts on an alternative to (no title) in the cases the post type doesn't support titles.'

I'm on it! Thanks for the heads-up!

[audrasjb]

Hi,

Looks like this patch unfortunately still needs copy review.

With 5.4 Beta 3 approaching and the Beta period reserved for bugs introduced during the cycle, this is being moved to Future Release. If any maintainer or committer feels this should be included or wishes to assume ownership during a specific cycle, feel free to update the milestone accordingly.

[bridgetwillard]

Copy Review of "(no title)"

Hi @garrett-eclipse am I understanding this correctly?

The CPT doesn't support any title whatsoever.

Therefore, the Title is Not Applicable.

Suggested Copy

'(N/A)' or '(Title Not Applicable)' or '(Title N/A)'

Replying to garrett-eclipse:

Hi @rajanit2000 I milestoned this into 5.4 and hope it is addressed within that release. It's currently awaiting a 2nd-opinion and needs-copy-review which will hopefully come once devs start working through the 5.4 milestone.
*In hopes of getting a copy-review going to ping @marybaum

Mary, the part specific to copy review;
'would be nice to get thoughts on an alternative to (no title) in the cases the post type doesn't support titles.'

[garrett-eclipse]

Thanks @bridgetwillard greatly appreciated, yes that's the part and concept exactly. Re-reading I wonder if we use the 'support' term that's used in the register_post_type() method as documented here (search 'supports');
​https://developer.wordpress.org/reference/functions/register_post_type/

Maybe just append 'supported' to what we have already;
(no title supported)
Or
(title not supported)

Thoughts?

[bridgetwillard]

Excellent point, @garrett-eclipse.

I would go with (no title supported).

'(title not supported)' feels unclear to me.

Cheers.

[garrett-eclipse]

Refreshed patch to take into account copy review of (no title supported)

[garrett-eclipse]

Test of a post type that doesn't support title

[garrett-eclipse]

Thanks for the copy review @bridgetwillard I've updated the patch in 45516.2.diff I think this is good to go so am going to see if we can land it in 5.6.

@SergeyBiryukov would you like to review the latest please.

[SergeyBiryukov]

In 49288:

Posts, Post Types: Set better default title for custom post types without title support.

The default title is now set to "(no title supported)" instead of "Auto Draft".

Props garrett-eclipse, rajanit2000, bridgetwillard, donmhico, nrqsnchz.
Fixes #45516.

[TimothyBlynJacobs]

Has this been tested against Gutenberg? The plugin does some manual checks against "Auto Draft" being the title.

[SergeyBiryukov]

Thanks, reopening to see if any additional changes are needed.

[SergeyBiryukov]

It looks like ​line 475 in core-data package needs an update to account for the new value as well.

Haven't found any other instances.

[joyously]

It seems like the Post List Table class should check for title support and use something else to differentiate the posts if no title is supported. How is the user supposed to find the post to edit when the link is on the title, which isn't supported? (I guess they will have code to add a column for something else.)

[hellofromTonya]

Notes from today's scrub:

Per Sergey

Here: ​https://github.com/WordPress/gutenberg/blob/c33f007d70ed5978d433b1069af23db1c2d94c2f/packages/core-data/src/actions.js#L475
It's not quite clear why it only seems to compare to a non-translated title :thinking_face:
I can open an issue [ie in GB]

[helen]

Reverting this from 5.6 and moving to 5.7 to try again due to lack of update in Gutenberg package and being ~24 hours from RC. I would like to think through a different string as well if we could, (no title supported) manages to be both too technical and not descriptive enough at the same time for me, which makes it sound alarming or like something has gone wrong if you are not somebody who understands that you can turn off title support for a post type.

More broadly I do not love when CPTs do this and have the admin interface exposed without coming up with a user-friendly way of differentiating items. Not sure if there's also something we can do here to nudge them a certain way.

[helen]

In 49614:

Posts, Post Types: Go back to "Auto Draft" for CPTs without title support.

Reverts [49288] due to late point in 5.6 cycle and lack of update in Gutenberg package to account for the string change.
See #45516.

[hellofromTonya]

@SergeyBiryukov Did you get a chance to open an issue upstream in Gutenberg for this one? See notes in slack ​https://wordpress.slack.com/archives/C02RQBWTW/p1604951464174800

[hellofromTonya]

With 5.7 RC1 landing tomorrow and no activity on this ticket since 5.6, punting this ticket to Future Release.

If any maintainer or committer feels this can be resolved in time, or wishes to assume ownership during a specific cycle, feel free to update the milestone accordingly.

[Cybr]

If the post type had support for titles but lost it, the last stored value will be unalterable but still used.

Therefore, I think it's best to (also) have a post_type_supports() check in single_post_title().

This (extra) check may impact developers that deliberately removed support but have prefilled the value. But I think this is where they had to filter single_post_title instead.

[SirLouen]

Test Report

Description

✅ This report validates that the indicated patch works as expected.

Patch tested: https://core.trac.wordpress.org/attachment/ticket/45516/45516.2.diff

Environment

• WordPress: 6.9-alpha-60093-src
• PHP: 8.2.29
• Server: nginx/1.29.1
• Database: mysqli (Server: 8.4.6 / Client: mysqlnd 8.2.29)
• Browser: Chrome 139.0.0.0
• OS: Windows 10/11
• Theme: Twenty Twenty-Five 1.3
• MU Plugins: None activated
• Plugins:
  • Testing Dolly 1.0.0
  • Test Reports 1.2.0

Testing Instructions

1. Add the code in the first post (remember to add it to a function and hook it into init)
2. Publish a new post to the new CPT called "Social Posts"
3. 🐞 Title return wrongly "Auto Draft"

Actual Results

1. ✅ Issue resolved with patch, adding "No title supported". (By the default a post without title displays just "No title")

Additional Notes

Replying to Cybr:

This (extra) check may impact developers that deliberately removed support but have prefilled the value. But I think this is where they had to filter single_post_title instead.

I think this is worth another report. Although it's correlated, it is an entirely different topic.

• Added a Unit Test for this.

Supplemental Artifacts

Adding Unit Tests to the patch 45516.2.diff

Trac ticket: https://core.trac.wordpress.org/ticket/45516

[mosescursor]

Patch Testing Issue “45516”

Test Report

Description

A custom Post type that has no Title is displayed as “Auto Draft” instead of something like No Title or UnSupported Title.

Patch tested:
[45516.2.diff​](573 bytes) - added by garrett-eclipse 5 years ago.
Refreshed patch to take into account copy review of (no title supported)

Environment

• WordPress: 6.8.2
• PHP: 8.2.29
• Server: Apache/2.4.65 (Debian)
• Database: mysqli (Server: 8.0.43 / Client: mysqlnd 8.2.29)
• Browser: Chrome 140.0.0.0
• OS: macOS
• Theme: Twenty Twenty-Five 1.3
• MU Plugins: None activated
• Plugins:
  • Test CPT Without Title 1.0
  • Test Reports 1.2.0

Actual Results

1. ✅ Issue resolved with patch

Additional Notes

• Any additional details worth mentioning.

Supplemental Artifacts

[SirLouen]

This is ready to be launched.

[fakhriaz]

Test Report

Description

CPT Social Post with no title displays: (no title supported) after applying the patch.

Patch tested: 45516.2.diff​ (573 bytes) - added by garrett-eclipse 5 years ago.
https://core.trac.wordpress.org/attachment/ticket/45516/45516.2.diff

Environment

• WordPress: 6.9-alpha-60093-src
• PHP: 8.2.29
• Server: nginx/1.29.1
• Database: mysqli (Server: 8.4.6 / Client: mysqlnd 8.2.29)
• Browser: Chrome 140.0.0.0
• OS: Linux
• Theme: Twenty Twenty-Five 1.3
• MU Plugins: None activated
• Plugins:
  • Hello Dolly test 1.7.2
  • Test Reports 1.2.0

Actual Results

1. ✅ Issue resolved with patch.

Additional Notes

• We edited the hello.php file of Hello Dolly plugin adding the code at the first post.
• CPT with no title displays: Auto Draft, before applying the patch (as shown below as well).

Supplemental Artifacts

Image showing test results:
​https://ibb.co/tT66cpgf
The social post at the top is after applying the patch: (no title supported)
The social post at the bottom is before applying the patch: Auto Draft

[gulamdastgir04]

Tested the patch in the WordPress Playground using PHP 8.3 and 6.9 alpha version.

Test Report

Description

This report validates whether the indicated patch works as expected.

Patch tested: ​https://github.com/WordPress/wordpress-develop/pull/9597

Environment

• WordPress: 6.9-alpha-20250825.225429
• PHP: 8.3.27-dev
• Server: PHP.wasm
• Database: WP_SQLite_Driver (Server: 8.0.38 / Client: 3.40.1)
• Browser: Chrome 142.0.0.0
• OS: Linux
• Theme: Twenty Twenty-Five 1.3
• MU Plugins: None activated
• Plugins:
  • Test Reports 1.2.0

Actual Results

✅ Issue resolved with patch.

[wildworks]

Since the RC1 release is coming soon, I'm punting this ticket to 7.0.

Has this been tested against Gutenberg? The plugin does some manual checks against "Auto Draft" being the title.

Based on the discussions I've read, it seems that no research or testing has yet been conducted on the points mentioned above.

Further investigation and testing are needed to determine whether this change will cause problems with the block editor or site editor, and whether any string changes are required on the Gutenberg project side.

Additionally, what would happen if title support was added to that post type later on?

• Register a post type without title support.
• Insert a post and save it.
• In the post list table, it will be displayed as (no title supported).
• Add title support to that post type.
• In the post list table, it will be displayed as (no title supported).
• In the post list, the post type is still displayed as (no title supported) even though it supports a title.

Perhaps, it might be possible to simply use (no title)?

[SirLouen]

Based on the discussions I've read, it seems that no research or testing has yet been conducted on the points mentioned above.

I'm not sure what "Testing" should be driven in Gutenberg specifically. All tests have been actually done in Gutenberg as this is the default editor.

If we check the code, Auto Drafts are still being executed when they should for Gutenberg drafting purposes. The (no title supported) is only relevant when the post is actually saved, but there is no title support explicitly set at that exact moment. Currently it will be set as Auto Draft generating a faulty behavior.

Replying to wildworks:

Perhaps, it might be possible to simply use (no title)?

@wildworks the problem is that since this is not a dynamic field, this is only reflecting the current status when set.
It's like (Auto Draft). You could edit this in a million ways and still it will be saying "(Auto Draft)" until you manually change it.

(no title) is not much descriptive in regards of what is happening but (Auto Draft) is actually misbehaving.

So currently this is misbehaving and this patch will add a fix to this. It could always be reimproved but current situation is unstable.

I still believe this is a commit, and it should be committed in 6.9

[wildworks]

Let's look at an example of an inconsistency occurring in Gutenberg.

• Register a post type without title support.
• Insert a post and save it.
• In the post list table, it will be displayed as (no title supported).
• Open the block editor. The header document bar will display No title. This should be (no title supported).

I understand that there are already inconsistencies between the dashboard and the block editor for post types that do not currently support titles, but instead of fixing only a part of it, we should aim for consistency in the behavior of both the core and Gutenberg.

[SirLouen]

Replying to wildworks:

Let's look at an example of an inconsistency occurring in Gutenberg.

• Register a post type without title support.
• Insert a post and save it.
• In the post list table, it will be displayed as (no title supported).
• Open the block editor. The header document bar will display No title. This should be (no title supported).

I understand that there are already inconsistencies between the dashboard and the block editor for post types that do not currently support titles, but instead of fixing only a part of it, we should aim for consistency in the behavior of both the core and Gutenberg.

@wildworks got you
I added a fix in Gutenberg for this.
​https://github.com/WordPress/gutenberg/pull/73091

I still think we are on time to add this for 6.9.

[peterwilsoncc]

I agree with @helen's earlier comment #36 that (no title supported) is unhelpful. It was a wise decision to revert back then and I don't think it's wise to commit with the same text now.

I'm not seeing any design/copy discussions on this ticket since then so I'm bumping this from the 6.9 milestone.

[wildworks]

I reread the entire discussion and considered what the ideal solution would be.

My understanding is that the "title" post type support simply determines whether or not to display the UI for editing the title in the editor. It doesn't relate to what the title of that post is, or whether the title should be displayed on the front end. For example, the_title and get_the_title do not consider whether that post type supports titles.

Furthermore, if we proceed with ​PR 9597, unintended problems will occur. Try the following:

• Add a post type without title support.
• Add and save a post.
• Check the display on the front end.
• The title will be (no title supported).

The text (no title supported) only for the dashboard and should not be displayed on the front end.

This result is to be expected, as the reason is that the string is stored in the post_title column of the database. However, a similar problem already exists in the trunk branch, where Auto Draft is displayed on the frontend.

Another problem is that these titles are not localized even when the site language is changed.

Perhaps it would be ideal to set an empty string instead of forcing some string as the title? That way, it would work as follows:

• Dashboard: (no-title) is displayed as a fallback.
• Front end: Nothing is displayed as a title.

In any case, I agree to punt this ticket to a future release, as I feel there is still insufficient discussion and investigation to proceed with it in 6.9.

[SirLouen]

Replying to peterwilsoncc:

I agree with @helen's earlier comment #36 that (no title supported) is unhelpful. It was a wise decision to revert back then and I don't think it's wise to commit with the same text now.

I'm not seeing any design/copy discussions on this ticket since then so I'm bumping this from the 6.9 milestone.

@peterwilsoncc @wildworks

There are several copy discussions going from comment #12 to comment #24.

Personally, I don't understand your POV.

However, a similar problem already exists in the trunk branch, where Auto Draft is displayed on the frontend.

This is what I mean.

Another problem is that these titles are not localized even when the site language is changed.

They have the loc method. I'm assuming that (no title supported) is just a new string to be added or I'm missing something?

In any case, I agree to punt this ticket to a future release, as I feel there is still insufficient discussion and investigation to proceed with it in 6.9.

Currently we have a problem: if you save a post without a title, it will save it with “Auto Draft,” which is seriously confusing. Firstly, we are trying to fix it. Then we will add some bells and whistles to make this a wonderful and massive user experience. But the current user experience is feeble with the current status. So we are trying to “postpone” this fix again, for another year, instead of opting to introduce a minor improvement.

Let's put it this way: Now we are going in the driveway with one blown tire. The current patch brings the substitution tire, which is not the official tire, but it's good to get to the garage. @peterwilsoncc proposes to continue a little more with the blown tire and destroy rims.

I still believe we should push it into 6.9 and keep it open for further refinements. Going from bad to meh is not always the worst thing. Maybe we should even create a new ticket for these refinements. But the reality is that we are least, fixing the Administration display.

[wildworks]

@SirLouen

Applying the patch causes the title to change from 'Auto Draft' to '(no title supported)' on the frontend for the post that doesn't support the title. This is a more serious problem for me.

However, there's a final bug scrub happening later today before the RC1 release. If you're able to participate in that, it might be a good idea to bring up this ticket and get more opinion.

​https://make.wordpress.org/core/2025/09/15/bug-scrub-schedule-for-wordpress-6-9/

[SirLouen]

Replying to wildworks:

Applying the patch causes the title to change from 'Auto Draft' to '(no title supported)' on the frontend for the post that doesn't support the title. This is a more serious problem for me.

Yes, I can agree with you that this must be fixed. But it can potentially display "Auto Draft".

For example, the_title and get_the_title do not consider whether that post type supports titles.

The problem here is this. I think we need to fix this by adding another ticket because it's correlated but not strictly related. This is a wrong behavior in the front end (showing a weird title "Auto Draft" when no title is supported) vs. showing a title in the_title and get_the_title when no title is supported.

But the discussion of @peterwilsoncc is that he doesn't like (no title supported) because, as @helen said, it feels slightly misdirecting (but he is also disregarding that currently people are seing Auto Draft which is not slightly misdirecting but deceiving).

PS: The last 10 times I opened a ticket for something like this, they were entirely ignored and ultimately closed. So I will wait to see a conclusion on any of your sides.

[SirLouen]

However, there's a final bug scrub happening later today before the RC1 release. If you're able to participate in that, it might be a good idea to bring up this ticket and get more opinion.

I'm moving this back to 6.9 again, so it can pop back in this last scrub and I will be present. If we finally decide to leave it behind, we will see what to do. But given that I'm the Posts maintainer, I don't like to leave this without a resolution in any direction, because for me, this is finished and makes sense (still I agree 100% with Aki, that another ticket should be opened to manage unhandled titles in no-support templates).

[peterwilsoncc]

@SirLouen Please don't status war this ticket.

You mentioned that there was a copy discussion in a few comments that came before the decision to revert. That may be true but there was no such discussion after the revert.

No one is saying that Auto Draft is good, what has been said is that (no title supported) is an insufficient improvement in order to close this ticket. Further discussion is required in order to get close to a good user experience.

[SirLouen]

Replying to peterwilsoncc:

@SirLouen Please don't status war this ticket.

Aki told that maybe this could be reviewed during the evening bug-scrub so I re-added it to the milestone so it could pop up during the session. But it didn't appear.

You mentioned that there was a copy discussion in a few comments that came before the decision to revert. That may be true but there was no such discussion after the revert.

Oh, there was no discussion after the revert. @TimothyBlynJacobs was simply curious if there was any interaction between Auto Draft and Gutenberg. There was interaction in the past, but there is no interaction nowadays. The concern that @SergeyBiryukov brought in comment#31 is not valid anymore because this is not considering the title itself.

No one is saying that Auto Draft is good, what has been said is that (no title supported) is an insufficient improvement in order to close this ticket. Further discussion is required in order to get close to a good user experience.

This is what I mean. Auto Draft is a disaster. (no title supported) is average. Personally, I like it, and @garrett-eclipse @marybaum and @bridgetwillard confirmed that is was semantically correct, with only @helen somewhat opposing.

More broadly I do not love when CPTs do this and have the admin interface exposed without coming up with a user-friendly way of differentiating items. Not sure if there's also something we can do here to nudge them a certain way.

There was this concern, which I can somewhat agree (CPT with custom things tending not to fit in the mold).

The reality is that a combination of:

• (no title supported) in the Admin interface (following the common standard on special titles: (<informational_text>))
• No title supported in the Gutenberg's document bar
• And removing the title string from the_title and get_the_title (new ticket required for this)

Will be clutch.

But all starts with this ticket being merged and finally closed before 6.9 to avoid 1 additional year of broken Auto Draft in no title supports.

[wildworks]

Let me explain my proposal accurately once again.

My understanding is that the "title" post type support simply determines whether or not to display the UI for editing the title in the editor. It doesn't relate to what the title of that post is, or whether the title should be displayed on the front end. For example, the_title and get_the_title do not consider whether that post type supports titles.

I'm not saying this is a bug; I believe this is the correct specification. This also applies to support for many other post types. Basically, existing data should be output on the front end even if there is no support for that post type.

Applying the patch causes the title to change from 'Auto Draft' to '(no title supported)' on the frontend for the post that doesn't support the title. This is a more serious problem for me.

I feel that applying the patch will only make the symptoms worse on the front end. This is the main reason I'm hesitant to apply the patch.

Perhaps it would be ideal to set an empty string instead of forcing some string as the title? That way, it would work as follows:

• Dashboard: (no-title) is displayed as a fallback.
• Front end: Nothing is displayed as a title.

This is the best approach I can think of at the moment, but considering there's only half a day left until the RC1 release and there are differing opinions, my personal opinion remains unchanged: I still believe this ticket should be postponed to version 7.0 or a future release.

[mosescursor]

Can we use the Following

• Dashboard: (no-title) is displayed as a fallback.
• Front end: (no-title) is displayed as a title. Someone will know that they didn't supply a title and this works better than leaving Empty and it is also better than no-title-supported which is too long for nothing since it represents nothing.

The term supported feels misused here. The Post may noy just have a title but can get a title. When you set supported makes an impression that a title can not be used which is wrong

[wildworks]

There are only two hours left until the commit freeze for 6.9 RC1. ​Since string changes will not be allowed after the RC1 release, let's move this ticket to the Future Release.

[SirLouen]

Recapping the problem

When we create a new Custom Post Type (CPT), and we remove the "title" support (which means that we cannot add a title to the post type), we create a new post of this CPT and we save it, in the Administration panel appears (Auto Draft) in the Title column.

In the editor top bar (also called the Document Bar) appears: No title

And when we check the newly created post in the front end (with a theme that shows the title by default, like Twenty Twenty), we see Auto Draft as well.

With this context, let's continue the discussion (I'm adding this, so more people can join the conversation fast and furiously).

Replying to wildworks:

This is the best approach I can think of at the moment, but considering there's only half a day left until the RC1 release and there are differing opinions, my personal opinion remains unchanged: I still believe this ticket should be postponed to version 7.0 or a future release.

So here the discussion goes back to (no title).

I had to read through the whole ticket conversation to understand the motivations of the participants of why (no title) is a bad idea: https://core.trac.wordpress.org/ticket/45516?replyto=68#comment:15

Basically, (no title) seems to be insufficient. The problem with (no title) is that it's currently being used to specify, "The post doesn't have a title but CAN have a title".

This is why they decided to step into an alternative, and several copy alternatives were proposed until they settled down with (no title supported).

About the:

• Front end: Nothing is displayed as a title.

This is the best approach

Isn't this contradictory? You are commenting in the beginning.

Basically, existing data should be output on the front end even if there is no support for that post type.

And then you say that in the front end nothing should be displayed as a title.

Anyway, again, as I said and is crucial, this is content for another ticket.

We are focusing here just on the administration display.

Replying to mosescursor:

The term supported feels misused here. The Post may noy just have a title but can get a title. When you set supported makes an impression that a title can not be used which is wrong

You are not correct on this point, Mr. Sebunya. This is exactly what it means: a title cannot be used because at one point, you created that post without title support (not having title support means that you cannot add a title).

@wildworks was dubious with "What happens if the title supports are returned". This is a tricky question. The same goes for other title static options like Auto Draft. What happens if the post was edited but the title was never updated? Is it still an Auto Draft?. Given the nature of static titles, we cannot switch them once settled for the first time. They are just an indication of the current status when they are set, and they can become obsolete the minute after.

Replying to wildworks:

I feel that applying the patch will only make the symptoms worse on the front end. This is the main reason I'm hesitant to apply the patch.

I don't understand how it can worsen it. How can (title not supported) be worse than Auto Draft? Auto Draft is misdirecting, while (no title supported) is aligned with the problem. This patch is softening this issue. Leaving things unchanged means that we can't add incremental improvements, and we prefer to leave things broken than things “less broken”.

My concern here is that we are not giving solutions, and I'm providing a solution.

The answers are like, "I don't like your solution, but I'm not really sure what I like".

This is a problem because, as we are now, we are leaving this ticket orphaned without a solution or a direction. And my task is to get tickets from this component to a final resolution. And I have not heard any convincing criteria to avoid (no title supported) yet.

I'm going to bring @marybaum to the conversation, as she is the copy master. :)

So here we start the "Copy Review" part 2

[mindctrl]

It's unfortunate that post_title is a required field at the table level, but then posts without titles are supported.

It seems like the Post List Table class should check for title support and use something else to differentiate the posts if no title is supported.

On the admin side, this was the very first thought I had. Why show the title field if the post type doesn't support titles? It's the default, and it's where the actions row goes, but if you have no knowledge of WP internals, it won't make a lot of sense. Also the Screen Options dropdown doesn't allow you to turn off the title column display, even if you want to, presumably because actions are attached to that column.

Any default fallback text for posts with no title is going to be confusing in the admin, without some kind of additional code to update the list table display. Is a list of 20 posts with "Auto Draft" really more confusing than 20 posts with "(no title)" or similar? There's still no way to differentiate them.

get_the_title() provides an empty string for the title if one does not exist on the post object.

The Twenty Twenty One theme filters the_title to change an empty string to "Untitled".

[peterwilsoncc]

For posts that don't have title support, it's not possible to assume they don't have a title. Title support indicates whether or not they are supported in the editor interface.

For example, the WooCommerce post type shop_order doesn't support a title but auto-generates one ​based on the order date.

The shortnotes plugin, which is used for social posts, similar to the example in this ticket's description, also ​auto generates a title based on the content.

For copy, some options are:

• display the generated title if it exists
• the first N characters of the content if it exists
• (Post type) @ (long form date)

For SEO reasons, the title on the front end should be different for each post. I recently messed up the SEO for some post types that don't support titles in the editor on my site and Bing Webmaster tools displayed the warning Too many pages with identical titles. The solution needs to avoid that.

---

To be clear, because I feel my opinion is being somewhat misrepresented. I AM NOT disagreeing with (no title supported) because @helen said so. I respect Helen's opinion but have been known to disagree with her on numerous occasions.

The order of operations for my comment was that I felt the new copy was not suitable to solve this ticket so I reviewed the discussion and found that it had previously been reverted due to much the same concerns I had. It's easier to refer back to existing comments that repeat them.

[SirLouen]

Replying to peterwilsoncc:

For copy, some options are:

• display the generated title if it exists
• the first N characters of the content if it exists
• (Post type) @ (long form date)

1. The generated title obviously should be displayed when available (not available by default), but what we are assuming here is the absence of it, and how to deal with the original fallback (ie Auto Draft, which currently is deceiving and rubbishy).

2. Hoping that there is content at least, otherwise, we will drop into no title at all, which leads back to the original discussion I commented in my previous message)

3. A somewhat random sequence could be another copy solution for the troubles stated with SEO.

I recently messed up the SEO for some post types that don't support titles

It's kind of strange to see a no titles support CPT + titles being shown in the template = angry because all titles are identical (Auto Draft or whatever are the same), and we trying to fix such a number of wrong decisions… As you said you messed up adding unhandled no titles support, and for some reason, your template for such CPT displayed titles... Also the SEO "troubles" are going to be affecting just those pages, should not be a big deal and SEO tools will be informing you about this, which is good because you will be able to spot the issue (you left your template showing wrong titles). So you had a free debugger, and now we could be planning to obscure this great information?

Anyway, almost anything, except for (no title), is better than Auto Draft.
Even adding a 👍 emoji will do the trick... Currently we have left unmerged with the worst copy of all scenarios, Auto Draft

Replying to mindctrl:

get_the_title() provides an empty string for the title if one does not exist on the post object.

Yes, this is what I was expecting originally. It seems that templates should deal with this. Here we are just informing about what is currently happening with titles.

But we must also consider what @peterwilsoncc suggested also: if titles are not supported, because we are managing internally such titles, and they must be displayed in the admin posts table, we should not be messing up with this.

I'm still trying to grasp why (no title supported) is still not the option

I remember some weeks ago when Adam Silverstein was asking which copy we should use for the new gutenberg notes. People were proposing ofering convoluted ideas like "Editorial Comments", and someone just said: "why not simply naming them Notes". @marybaum and me ​were agreeing with this because it was so simple and obvious. Here it feels just about the same. We could choose among a range of similar simple options like:

• (not supported): implicit given the position in the table
• (unsupported) again implicit
• (title not supported): which was discarded by @bridgetwillard
• (title unsupported): similar fashion but shorter.

Anyway, let's hear more about copy feedback.

[helen]

Fascinating to see this pop up again :) I think the real problem here is that there is not an actual clearly defined problem trying to be solved besides "this phrase is not my preference" which is an inevitable endless debate. I would like to take this back to @garrett-eclipse's comment early on in #12:

the idea of making the string a customizable label when registering the post type seems like it could have some merit

I also mentioned in my revert:

More broadly I do not love when CPTs do this and have the admin interface exposed without coming up with a user-friendly way of differentiating items. Not sure if there's also something we can do here to nudge them a certain way.

Can we take the conversation to "how can users differentiate between items when a post type doesn't support the title in the editor" instead? For instance, as a seed idea but not a solution, should there be a default_title arg (that takes placeholders or some other way of programmatic generation) and we also update the core default to be generated in a way that allows for some kind of differentiation? From there you would need to identify all the places in which the code expects a specific string and understand why that assumption was made and whether the knock-on effects are accounted for in addition to repairing those assumptions. Otherwise close this, no amount of back and forth is going to solve for a personal preference.

[SirLouen]

Replying to helen:

Fascinating to see this pop up again :)

And even more to pop up soon, I'm triaging through every single ticket in the post/post-types component. :)

I think the real problem here is that there is not an actual clearly defined problem trying to be solved besides "this phrase is not my preference" which is an inevitable endless debate.

I'm not totally sure about this. The original problem we are completely ignoring is the fact that when you create a new post in a no-title support CPT, in the title appears Auto Draft. It's ultra misdirecting. As I told @wildworks: any solution, even a simple dot or an empty title will do way better than Auto Draft. We should not leave this alone.

Can we take the conversation to "how can users differentiate between items when a post type doesn't support the title in the editor" instead? For instance, as a seed idea but not a solution, should there be a default_title arg (that takes placeholders or some other way of programmatic generation) and we also update the core default to be generated in a way that allows for some kind of differentiation? From there you would need to identify all the places in which the code expects a specific string and understand why that assumption was made and whether the knock-on effects are accounted for in addition to repairing those assumptions.

The problem as you exactly suggest, is that after "sorting" the Auto Draft thing, we want to go two steps forward, and sort it with a super-elegant and perfect solution. As I suggested to Aki I feel that we preferred to go in the road with the blown tire destroying our rims, than using a temporary wooden wheel. :)

Otherwise close this, no amount of back and forth is going to solve for a personal preference.

I feel wrong for closing this and leaving the "Auto Draft" thing. Maybe is not a big deal because I doubt that many users remove titles from CPT and leave it unmanaged, but this is a wrong behavior, a bug that we are not simply addressing. It's at the tips of our hands with a tested patch and one return away from being shipped. From there, we could have a discussion on marvelous solutions that favor the UX. But first things first is fixing this bug.

[SirLouen]

I've been rethinking on this topic after a couple of days and got to a new conclusion: I can't really understand why we are setting a title at all here. If the title is not supported, we should simply leave the title empty.

In the first patch they first settled to (no title) (which happens to be the default with no title), and I believe that this conditioned the direction of the whole discussion from there and brought a lot of misdirected thought about what to set instead.

But I've been re-reading the whole conversation and thinking again about what wildworks said:

Perhaps it would be ideal to set an empty string instead of forcing some string as the title? That way, it would work as follows:

• Dashboard: (no-title) is displayed as a fallback.
• Front end: Nothing is displayed as a title.

Which I completely misread back in the day 🤦

In Gutenberg, by default, No Title is placed when no title exists. And since here there is no support for titles, so I entirely agree with him: why are we actually setting one?

In most classic themes, a weird title is appearing (now it's Auto Draft), but if we set (no title supported) or (no title) or whatever, it will make 0 sense

But since no title is supported, no title should appear (unless we obviously programmatically set one)

I have updated the PR and the testing suite. I'm closing ​GB73090 as it makes no sense to me any more.

Let's fix this ticket.

cc @wildworks @peterwilsoncc

[peterwilsoncc]

I'd like to go back to first principals and consider what exactly the problem is that needs to be solved.

I believe the issue is that "Auto Draft" is technical details AND that there is no way to differentiate between posts when viewing the admin screen.

The issue with (no title supported) was similar: it's a technical detail AND there was no way to differentiate between posts when viewing the admin screen.

Wrapping the title in brackets isn't great. No title or Untitled is an improvement on the earlier version but still lacks a way of differentiating the posts in the admin.

An additional question to ask is this: Is this a bug in WordPress or themes/plugins developing CPTs without title support? WordPress provides numerous filters to modify the title display; is it reasonable to expect these to be used (I believe it is).

Regarding the default themes, I'm not overly concerned about them displaying the default value on the front end. WordPress default themes are designed to support WordPress default post types which support titles.

[SirLouen]

Replying to peterwilsoncc:

I'd like to go back to first principals and consider what exactly the problem is that needs to be solved.

I believe the issue is that "Auto Draft" is technical details AND that there is no way to differentiate between posts when viewing the admin screen.

The issue with (no title supported) was similar: it's a technical detail AND there was no way to differentiate between posts when viewing the admin screen.

Wrapping the title in brackets isn't great. No title or Untitled is an improvement on the earlier version but still lacks a way of differentiating the posts in the admin.

An additional question to ask is this: Is this a bug in WordPress or themes/plugins developing CPTs without title support? WordPress provides numerous filters to modify the title display; is it reasonable to expect these to be used (I believe it is).

Regarding the default themes, I'm not overly concerned about them displaying the default value on the front end. WordPress default themes are designed to support WordPress default post types which support titles.

To be clear, I don't 100% understand what you are expecting from this.

I'm going to try to guess what your proposal is: switching from (no title) to No title?

(no title) in the Admin dashboard, has been the default for centuries when no title has been set.

If this is what you have in mind, basically you are going out of scope of this ticket. The right way to proceed is to open a new ticket focusing on this change if you think this will bring a legibility improvement.

But this ticket is trying to fix a singular defect. I don't understand why we must solve 2 or 3 things at a time. We should aim to do atomic changes, which are easier to review, easier to test and unit test, and easier to track back and understand when git blaming. If we fix this, switching from Auto Draft to an empty string (which results, by default, in (no title) then we can steer into No Title or whatever idea, but in another ticket.

At this point I think that this is legit straightforward to be merged. Future improvements can be made to the Administration panel in various forms, but this fix is quite neat.

[SergeyBiryukov]

In 61360:

Posts, Post Types: Only set default title for custom post types if they have title support.

Previously, the default post title was always set to Auto Draft, regardless of whether the CPT supports a title.

This commit ensures that the default title is present when a CPT has title support, and is an empty string otherwise.

Follow-up to [12987], [49288], [49614].

Props SirLouen, rajanit2000, garrett-eclipse, wildworks, nrqsnchz, donmhico, marybaum, audrasjb, bridgetwillard, TimothyBlynJacobs, joyously, hellofromTonya, helen, Cybr, mosescursor, fakhriaz, gulamdastgir04, peterwilsoncc, mindctrl, westonruter, SergeyBiryukov.
Fixes #45516.