WordPress.org

Make WordPress Core

Opened 5 years ago

Closed 5 years ago

#12590 closed defect (bug) (fixed)

The Title and tinyMCE Editor should be optional for custom post types

Reported by: ptahdunbar Owned by: scribu
Milestone: 3.0 Priority: normal
Severity: normal Version: 3.0
Component: Posts, Post Types Keywords: has-patch commit
Focuses: Cc:

Description

We should be able to add/remove support for the title and tinyMCE editor fields when registering custom post types.

Patches welcomed :)

Attachments (6)

12590.diff (3.2 KB) - added by scribu 5 years ago.
use post_type_supports() for title and editor
12590.2.diff (3.0 KB) - added by scribu 5 years ago.
Consistent feature names: 'excerpts' -> 'excerpt' and 'post-thumbnails' -> 'thumbnail'
12590.3.diff (2.0 KB) - added by scribu 5 years ago.
replace 'editor' with 'content'
scripts.diff (2.3 KB) - added by scribu 5 years ago.
load scripts only when needed
scripts.2.diff (2.4 KB) - added by scribu 5 years ago.
Take #12792 into account
scripts.3.diff (2.8 KB) - added by scribu 5 years ago.
Re-add 'autosave'

Download all attachments as: .zip

Change History (29)

comment:1 @scribu5 years ago

I agree. The title and editor should be metaboxes without the chrome.

comment:2 @jane5 years ago

Agree with @scribu. This will also enable people using regular posts to hide title or body if they don't need it due to how they are creating content (ex. no title in P2, no description for catalogues that only use custom fields, etc).

comment:3 @unsalkorkmaz5 years ago

  • Cc unsalkorkmaz added

@scribu5 years ago

use post_type_supports() for title and editor

comment:4 @scribu5 years ago

  • Keywords has-patch added; needs-patch removed

12590.diff checks post_type_supports() before displaying the title and/or the editor.

comment:5 @scribu5 years ago

Related: #12591

@scribu5 years ago

Consistent feature names: 'excerpts' -> 'excerpt' and 'post-thumbnails' -> 'thumbnail'

comment:6 @scribu5 years ago

We should really get this into 3.0, to avoid backwards compatibility issues with the 'supports' argument later on.

comment:7 @ptahdunbar5 years ago

Tested 12590.diff, and it seems the title field needs to be optional when publishing content. With a post type that only supports the TinyMCE editor, it receives a title of "Auto Draft". Creating a few posts, and all the titles have "Auto Draft" making the content indistinguishable on the Edit page.

comment:8 @scribu5 years ago

If the post type doesn't support titles, you wouldn't be able to distinguish them by title anyway.

The columns on the edit.php screen should also take the 'supports' argument into account.

comment:9 @automattor5 years ago

  • Resolution set to fixed
  • Status changed from new to closed

(In [13710]) Allow enabling/disabling title and editor per post type. Introdoce remove_post_type_support(). Add enable/disable for author override. Props scribu. fixes #12590

comment:10 @scribu5 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened
  • Version set to 3.0

@scribu5 years ago

replace 'editor' with 'content'

comment:11 follow-up: @scribu5 years ago

12590.3.diff:

replace 'editor' with 'content', to be in line with all the rest of the 'supports' array.

comment:12 in reply to: ↑ 11 ; follow-up: @nacin5 years ago

Replying to scribu:

replace 'editor' with 'content', to be in line with all the rest of the 'supports' array.

I'm not sure I agree with that. Many arguments in the supports array seem to be admin UI-centric -- custom fields, revisions, etc.

Many post types will utilize post_content. This is only for whether the editor should be shown.

comment:13 in reply to: ↑ 12 @scribu5 years ago

The difference in my mind is that title, content, custom fields, revisions etc. represent actual entities in the database, whereas 'editor' is a tool.

A generic one at that: An editor for what? content, title?

comment:14 @nacin5 years ago

But, custom fields refers specifically to the meta box. There's nothing stopping the post type from still utilizing post meta.

comment:15 @scribu5 years ago

That's true. I'll leave it be then.

By the way, if the content editor isn't shown, there's no point in loading all the scripts for it, right?

comment:16 @nacin5 years ago

Ultimately, most of these supports arguments are rather non-standard. A theme supports "post-thumbnails", but a post type supports "thumbnail". I don't find editor any better than content, except that all it does is actually remove the editor from view.

By the way, if the content editor isn't shown, there's no point in loading all the scripts for it, right?

Yeah, I'd say so.

@scribu5 years ago

load scripts only when needed

comment:17 @scribu5 years ago

  • Keywords commit added

scripts.diff moves the script queueing to edit-form-advanced.php and uses post_type_supports() to determine which are needed.

comment:18 @scribu5 years ago

  • Owner set to scribu
  • Status changed from reopened to accepted

comment:19 @nacin5 years ago

Related: #12792 -- removing the editor breaks thumbnails.

@scribu5 years ago

Take #12792 into account

comment:20 @nacin5 years ago

#12792 is handled. This good now?

comment:21 @duck_5 years ago

Looks like scripts.2.diff removes the enqueue call on 'autosave' but doesn't reinsert it anywhere, so a new post will not autosave once the title has been entered and the loading gif will not show when you try to publish (for example)

@scribu5 years ago

Re-add 'autosave'

comment:22 @scribu5 years ago

Good catch, duck_.

scripts.3.diff re-adds autosave for post-new.php and also moves the admin-comments script back to post.php (a new post can't have comments).

comment:23 @nacin5 years ago

  • Resolution set to fixed
  • Status changed from accepted to closed

(In [14107]) Don't enqueue unnecessary scripts when the post type doesn't support the editor. fixes #12590, props scribu, _duck.

Note: See TracTickets for help on using tickets.