Opened 15 years ago
Closed 15 years ago
#12590 closed defect (bug) (fixed)
The Title and tinyMCE Editor should be optional for custom post types
Reported by: |
|
Owned by: |
|
---|---|---|---|
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)
Change History (29)
#2
@
15 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).
#4
@
15 years ago
- Keywords has-patch added; needs-patch removed
12590.diff checks post_type_supports() before displaying the title and/or the editor.
@
15 years ago
Consistent feature names: 'excerpts' -> 'excerpt' and 'post-thumbnails' -> 'thumbnail'
#6
@
15 years ago
We should really get this into 3.0, to avoid backwards compatibility issues with the 'supports' argument later on.
#7
@
15 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
@
15 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.
#10
@
15 years ago
- Resolution fixed deleted
- Status changed from closed to reopened
- Version set to 3.0
#11
follow-up:
↓ 12
@
15 years ago
replace 'editor' with 'content', to be in line with all the rest of the 'supports' array.
#12
in reply to:
↑ 11
;
follow-up:
↓ 13
@
15 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
@
15 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
@
15 years ago
But, custom fields refers specifically to the meta box. There's nothing stopping the post type from still utilizing post meta.
#15
@
15 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
@
15 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.
#17
@
15 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.
#21
@
15 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)
I agree. The title and editor should be metaboxes without the chrome.