[wp-trac] [WordPress Trac] #9674: Better support for custom post types

[WordPress Trac]

#9674: Better support for custom post types
------------------------------------+---------------------------------------
 Reporter:  wnorris                 |        Owner:  ryan    
     Type:  task (blessed)          |       Status:  reopened
 Priority:  normal                  |    Milestone:  3.0     
Component:  Administration          |      Version:  2.9     
 Severity:  normal                  |   Resolution:          
 Keywords:  has-patch tested early  |  
------------------------------------+---------------------------------------

Comment(by jeremyclarke):

 I think the argument that it should be '''object''' because of the use of
 '''object_id''' in the term_relationships table is pretty solid. When I
 first saw that in the db I thought it was a good move, and that it was
 just a shame that the wp_posts table couldn't be switched to wp_objects,
 and the post_type field changed to object_type. While I'd hate for WP to
 become Drupal, I don't see any reason why the database would hurt by being
 abstracted in that way (beyond the obvious backwards-compatibility
 nightmare). Considering saved content items as 'objects' is very
 functional if our goal is to have it make sense that on a fundamental
 level 'posts', 'pages', 'links', and 'revisions' are all the same kind of
 information, just with a different 'type'.

 That said, the use of 'object' is ''only'' important if we want to
 maintain the current, specific meaning of '''post''', as a time-sensitive
 "story" with an author, categorization and a url based on the primary
 permalinks settings. This IMHO is a very important question and the vital
 one for assessing Mike's question about the status quo.

 Using 'post_*' as the general catch-all term for stuff saved to the db has
 a LOT of benefits if we are willing to do it.

 For one thing it makes a ton of sense semantically: On some level all the
 core content types and most potential 3rd party ones (tickets, players,
 stores) are things that get posted to the site and are thus posts. 'Post'
 defines the action by which the content is saved rather than the content
 itself, as well as aligning directly with _POST in http which happens to
 be how WP gets that shit done.

 Another huge benefit, albeit one tinged with problems, is that using
 'post_*' will mostly fit in with the current code. Unlike 'object_*' which
 makes sense but leaves the wp_posts table and various fields misnamed.
 'post_*' is back-compatible with almost everything out there. For the most
 part this is accidental, based on the (understandable) shortsightedness of
 the past where the specific content type of 'post' was given undue
 prominence and other types were effectively shoehorned into the existing
 database. That doesn't mean it can't be a benefit. If we are willing to
 shift our paradigm slightly to have 'post' mean all content types then we
 will reap the rewards of our past laziness in that the new content typing
 system can be semantically meaningful and internally consistent, while
 also avoiding huge deprecation conversions.

 The problem, of course, is the naming conflict created with the old
 'posts' when 'post' is used for all content. What are these 'posts' in the
 new system?

 A 'post' (in the old sense) is a post (new sense) with a post_type of
 'post', which on some level equates with being a post with post_type
 DEFAULT. This is awkward but we can easily imagine the historical
 explanation: Until very recently WP was a blogging tool, and it definitely
 was only a blogging tool when the db was first designed. In that frame of
 mind there was only one content type 'BLOG POST', since the software was
 the 'blog' the content were 'posts', and they had 'blog post' properties
 like time-sensitivity, categories and an author.

 As WP matured other content types were added, specifically 'pages', along
 with the post_type field to define them. IMHO the logical thing to do at
 this point would be to say that both types were posts, as implied by the
 DB structure and because they are both content that gets POSTed. At that
 point we could have '''specifically defined all existing 'posts' as
 post_type = blog'''. In effect that is what they are, posts logged in
 time, blogged. This would have left everything beautiful and today we
 wouldn't be debating at all. There are reasons that this would be a bad
 idea of course, not the least of which is that WP, even with just the
 'blog'/'post' content type, can be used for just about anything if you
 think creatively and know how to hack a theme. "Blog" has social
 connotations that go beyond its technical definition and as such WP has
 done well  to focus on posts rather than blog posts as their core content
 type.

 Thinking of the generic content in WP as posts instead of blog articles
 has a way of helping developers and especially users get over their
 worries that WP is "just a blog" so they can start building their awesome
 website. Going back at this point and changing either the UI or the DB for
 posts to have post_type=blog is almost defintiely a terrible idea, but I
 think accepting the fact that what we call posts are actuall blog-content
 is vital to understanding how 'posts' is a useful generic description of
 all content in the wp_posts table. Consider that '''article''' is another
 useful description of the default content in WP. If we had been using
 post_type=article for them since pages were added then the 'posts'
 metaphor would be perfectly suited to adding more content types.

 When post_type=post we can consider the content to be 'default' post type,
 though keeping the db the same is definitely a good idea. IMHO for 95% of
 projects the blog/article/default post_type and creative theming is all
 anyone needs, so treating it as default makes sense. A post type of post
 basically means 'a post with all the features', which is true except for a
 few page-specific features like custom templates. For people who want
 content with different settings or fields (i.e. different metaboxes in the
 editing UI) then adding new 'post types' is a meaningful and
 understandable concept

 I really like the idea and simplicity of keeping 'post_type' as the name
 and committing to it conceptually going forward.  If anything, I think
 that if we can really commit to 'post type' then changing the taxonomy api
 to use post_id instead of object_id might make sense as well, though its
 certainly not a prerequisite.

 That said I'm still not sure that object wouldn't be a better name for
 general content to avoid confusion. Both ideas are fraught with peril, but
 something has to be chosen so we can work on making its implementation
 excellent.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/9674#comment:92>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software