[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 mikeschinkel):

 Happy New Year all!

 Replying to [comment:92 jeremyclarke]:

 @jeremyclarke your latest response was really excellent, filled with great
 insite.  If I can paraphrase basically it sounds like you are saying that
 instead of questioning the name of the container (i.e. the "post type") we
 should instead question the name of one type of post, specifically the
 "post" post type. Brilliant.

 This perspective may open up an whole new line of approach being that we
 discard the notion of "post" being sacred and instead think in generic
 terms of arbitrary post types and related capabilities. This could even
 demphasize "page" to address @janeforshort's previously stated concerns
 about that name.

 Consider that Wordpress currently has four "core" post types: Posts,
 Pages, Attachments and Revisions.  If we ignore "Revisions" for the moment
 as a special "meta" case then we find that each of these has an associated
 set of generally appropriate capabilities baked into the 2.9 core
 (ignoring the shared capabilities, and my list is nowhere near complete):

  * Posts
    * Excerpts
    * Tags & Categories
    * Send Trackbacks
  * Pages
    * Attributes (Parent Pages)
    * Templates
  * Attachment
    * Image Editing
    * Alternate Text
    * Caption
    * File URL

 Now envision instead of having all that baked into Wordpress we evolve to
 being able to define a new post type and assign it any of post type
 capabilities, or even all of them if desired.  Then the core post types
 would simply become four default post types provided by v3.0 but where any
 of them could have their capabilities added to or removed, or any post
 type could even be deleted by a site owner if desired.

 Imagine how nice if would be for a online magazine website, for example,
 they could keep Pages and Attachments, remove Posts and add Articles,
 Interviews, and Reviews. A product oriented website may have just Pages,
 Posts and Attachments and add Products.  A SAAS site may keep Pages and
 Attachments and add Services and add Support Requests.

 To avoid confusing with "post" and "post type" we could even deprecate
 "post" and add "blog" as Jeremy suggested (though I think it might be
 better to call it "blogpost", but that's a nit.)

 This approach could really make Wordpress a lot more open in terms of
 capabilities and provide a framework for plugin and theme developers to
 take Wordpress to the next level and I don't mean that to be hyperbole.
 What do you say?

 -Mike Schinkel

 P.S. The post types plugin I'm working on could be the basis for
 incorporating a UI to manage post types into the core, if it is so
 desired. I'm happy to release it as a plugin when I'm done or I'd even be
 happier to contribute the work to the core (assuming some code review for
 Wordpress coding standards from some core developers.)

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