Make WordPress Core

Opened 14 years ago

Closed 14 years ago

#12590 closed defect (bug) (fixed)

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

Reported by: ptahdunbar's profile ptahdunbar Owned by: scribu's profile 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 14 years ago.
use post_type_supports() for title and editor
12590.2.diff (3.0 KB) - added by scribu 14 years ago.
Consistent feature names: 'excerpts' -> 'excerpt' and 'post-thumbnails' -> 'thumbnail'
12590.3.diff (2.0 KB) - added by scribu 14 years ago.
replace 'editor' with 'content'
scripts.diff (2.3 KB) - added by scribu 14 years ago.
load scripts only when needed
scripts.2.diff (2.4 KB) - added by scribu 14 years ago.
Take #12792 into account
scripts.3.diff (2.8 KB) - added by scribu 14 years ago.
Re-add 'autosave'

Download all attachments as: .zip

Change History (29)

#1 @scribu
14 years ago

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

#2 @jane
14 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).

#3 @unsalkorkmaz
14 years ago

  • Cc unsalkorkmaz added

@scribu
14 years ago

use post_type_supports() for title and editor

#4 @scribu
14 years ago

  • Keywords has-patch added; needs-patch removed

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

#5 @scribu
14 years ago

Related: #12591

@scribu
14 years ago

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

#6 @scribu
14 years ago

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

#7 @ptahdunbar
14 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.

#8 @scribu
14 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.

#9 @automattor
14 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

#10 @scribu
14 years ago

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

@scribu
14 years ago

replace 'editor' with 'content'

#11 follow-up: @scribu
14 years ago

12590.3.diff:

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

#12 in reply to: ↑ 11 ; follow-up: @nacin
14 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.

#13 in reply to: ↑ 12 @scribu
14 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?

#14 @nacin
14 years ago

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

#15 @scribu
14 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?

#16 @nacin
14 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.

@scribu
14 years ago

load scripts only when needed

#17 @scribu
14 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.

#18 @scribu
14 years ago

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

#19 @nacin
14 years ago

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

@scribu
14 years ago

Take #12792 into account

#20 @nacin
14 years ago

#12792 is handled. This good now?

#21 @duck_
14 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)

@scribu
14 years ago

Re-add 'autosave'

#22 @scribu
14 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).

#23 @nacin
14 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.