Make WordPress Core

Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#30892 closed enhancement (wontfix)

Renaming Custom Post Types

Reported by: eclare's profile eclare Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Posts, Post Types Keywords: close
Focuses: administration Cc:

Description

Not sure where to put this.

Custom Post Types can be of the following types: Post, Page, Attachment, Revision, Navigation menu (more: http://codex.wordpress.org/Post_Types)
It's a bit confusing that a custom post type can actually be a page or attachment and not a post. It gets weirder with translation, at least in my language.

TLDR: Wouldn't it be better if Custom Post Types were renamed to Custom Content Types or just Content Types?

The drawback here is backwards incompatibility for all WP content created on CPT, but maybe it's better now than later considering it can be confusing now and might be more confusing when more content types are added?

Change History (8)

#1 @swissspidy
9 years ago

I think the core developers are very well aware of this badly named feature. IMHO renaming things without breaking BC isn't really worth the effort. Let's just reference to them as custom content types, but use register_post_type() and the like in the code.

#2 @ocean90
9 years ago

  • Keywords close added

There is no need to rename CPT technically. Functions and UI can be detached, for historical reasons. In German it's already the translation for custom content types.

This is simular to the blogs/sites/networks terminology. We've also started to use widget area in UI, but still using sidebar in functions.

#3 @eclare
9 years ago

I agree that changing (or adding aliases) the function names may not be worth it, although it might be worth it to change the terminology in the Codex, like you both suggested. I'm voting for that option.

Aside from developers, the end user sees the CPT phrase mostly in plugins - and a lot of them, actually: SEO plugins, Sitemap plugins, Analytics plugins etc. etc... So it's not uncommon, even though there's no "custom post" string in Glotpress (both admin and front-end).

If we settle on changing the terminology and not the function names, can someone just push this to the Docs groups and we're done with it? And any other appropriate groups.

Last edited 9 years ago by eclare (previous) (diff)

#4 @nacin
9 years ago

markjaquith and I (both lead developers) have been subversively calling them "custom content types" at WordPress conferences for years now.

#5 @mdgl
9 years ago

Agreed the terminology of "post type", "content type" and even "post format" is all a bit confusing, as is the underlying implementation. Before we rush into renaming things, though I think we are still missing something.

I'd like to see us introduce a separate "content type" field to properly describe the encoding of the data contained within a post type (i.e. the how to interpret "the content"). Presently, the content of all post types is assumed to be an messy combination of some kind of HTML with embedded shortcodes, "texturised" and "smiley" elements and with special meaning to blank lines for wpautop(). This "WP-Mush" content type causes much confusion as well as numerous problems as hundreds of other bug reports will attest.

If we made the content type for posts explicit (really a MIME type for "the content"), we could start to clean up some of this mess, avoid confusing users by mangling their content and give more flexibility to CPTs to store and display content of their own choosing, even use their own custom content editors in the admin tool.

We would then have the following elements (names could be changed to suit):

  • post type = name of the overall information object for administration purposes
  • content type = way in which the content is encoded within the post type (i.e. MIME type for post content), used to select both editor and display pipeline
  • post format = way for themes to interpret the content for display if content type is "WP-Mush"

Sadly the current "mime type" field would need to remain to refer to the content type of attachments, even though this would more properly belong within the post meta.

#6 @iseulde
9 years ago

  • Version trunk deleted

#7 @swissspidy
9 years ago

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

comment:5 is something for a new ticket. Closing this one.

#8 @SergeyBiryukov
9 years ago

  • Milestone Awaiting Review deleted
Note: See TracTickets for help on using tickets.