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

 '''''@scribu object_type sounds better than content_type.'''''

 ''Pros for object_type'': Consistent with certain other internals.

 ''Cons for object_type'': Too generic and abstract for most end users to
 grasp.

 '''''@ryan: Getting away from post type would be good because of the
 conflict with the notion of post templates'''''

 Mind if I ask you to elaborate on why this is an issue?  Not being a core
 developer I'm not aware of why it's a problem.

 '''''@ryan: because the functions that play with the post_type field
 already suck up some of the good *_post_type function names.'''''

 Can you give examples of these functions names you need?

 I'm particularly interested in this topic because 1.) I so badly need it
 and 2.) I am working on a plugin to manage post types and I don't want to
 build an orphan.

 FWIW I'll restate, if at all possible I think you should stick with the
 term "post type."  You can refer to them as "Custom post types" which
 handles the distinction between core (post,page,revision,attachment) and
 user defined. But adding another name will cause far more confusion that
 it might resolve if experience in Drupal is any indication.

 That said, if you ''must'' rename it I'd propose ''item type'' or ''record
 type'', in that order of preference.  Most computer users have some idea
 what those terms mean vs ''object'' which I believe mostly only
 programmers understand.

 '''''@scribu - You have to register a new post type first. See post-
 type.php'''''

 Yeah, the custom post types plugin I'm working on registers post types
 during the init hook for types defined by the user in the admin console.

 I've actually run into a problem with it from the standpoint of
 persistence; if I persist to disk them reload them I have to decide which
 takes precedence; the deserialized version from the database or
 $wp_post_types?

 '''''@scribu - The plugin should stay a plugin, IMO. Just like there's a
 plugin for managing custom taxonomies from the admin - Simple
 Taxonomies.'''''

 Maybe, but my jury is out on that one still.  However, what we definitely
 need in core is more infrastructure. For example (as I build the plugin I
 realize) ''we need a standard way to persist post types''. I'll throw out
 this strawman: let's save wp_post_types to wp_options as 'post_types'
 using save_post_types() and load_post_types() functions, as simple as
 this:

 {{{
 function save_post_types() {
    update_option( 'post_types', $wp_post_types );
 }
 function load_post_types() {
    global $wp_post_types;
    $wp_post_types = update_option( 'post_types');
 }
 }}}

 Then add a "$persist" parameter defaulted to true to register_post_types()
 so that save_post_types() runs at the end by default like so:

 {{{
 function register_post_type($post_type, $args = array(), $persist=true) {
    global $wp_post_types;

    if (!is_array($wp_post_types))
       $wp_post_types = array();

    $defaults = array('exclude_from_search' => true);
    $args = wp_parse_args($args, $defaults);

    $post_type = sanitize_user($post_type, true);
    $args['name'] = $post_type;
    $wp_post_types[$post_type] = (object) $args;

    if (save_post_types())
       save_post_types();
 }
 }}}

 Next change create_initial_post_types() so that it loads at first then
 saves only once. This will allow core post types to be (re-)registered if
 need be. This of course needs to run prior to any plugin
 register_post_type()s can run (I assume that is already the case?)

 In addition I added another global $wp_core_post_types so that plugins can
 know which post types are sacred to Wordpress core.

 {{{
 function create_initial_post_types() {
    global $wp_core_post_types;
    $wp_core_post_types = array('post','page','attachment','revision');

    load_post_types();
    register_post_type( 'post', array('exclude_from_search' => false),
 false );
    register_post_type( 'page', array('exclude_from_search' => false),
 false );
    register_post_type( 'attachment', array('exclude_from_search' =>
 false), false );
    register_post_type( 'revision', array('exclude_from_search' => true),
 false );
    save_post_types();
 }
 }}}

 We might also want to add a standard "property" to the post_type array
 like 'is_core' and/or 'user_defined.'  Or maybe 'can_delete?' Not knowing
 exactly how post_types will be used by everyone I'm trying to figure out
 what standard property(s) would be useful so that one plugin's use of
 post_types doesn't step on anothers. Clearly I haven't figured this one
 out yet.

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