[wp-hackers] Custom Post - implementation specifics

[Mike Schinkel]

On Dec 5, 2009, at 8:13 PM, Stephen Rider wrote:
> On Dec 5, 2009, at 11:59 AM, Mike Schinkel wrote:

> I am against major changes to the Admin UI. There were significant changes in 2.6, and again in 2.7.  It is what it is now, and it would be a very bad idea to *again* make large changes to it any time soon.  "It's a shame" was not meant to indicate that we should change it back.

> 

Agreed, that argument makes sense.

>> While I don't have an extremely strong view against Actions menus I'd suggest considering instead having an API that would add a new top level admin menu for each new custom content type.  For example, I could see "Members" and "Companies" as being two top level admin menus. 
> 
> I think that actually adding the menus should be up to the Plugin.  Depending on the situation, it may make sense to have a new top level menu, or to add a new submenu, or to have a new top level with multiple sub menus with Edit/New for various Post Types.

Once an admin UI is in place in the core to support Custom Post Types I would think it would be very important for the administrator to have the option to specify that an admin menu be added for a new Custom Post Type.  

I think it would be very strange and very difficult to understand if there were an admin option to add a Custom Post Type but then there was nowhere in admin console and that installing a plugin were required to expose it.

> In other words, leave it flexible. 

That said, it would be great if omitting an add/edit menu were an option and/or it were easy to add a customizable add/edit menu option and of course for plugins to be able to completely specify what should be there.

BTW, I realize that the functions you are trying to specify are likely to be a precursor to and even enable any admin functionality.

>> as well as combine any post types into a single admin menu/edit list.  This would give the person setting up a site and/or a plugin full flexibility and to configure a content creation environment that works how they best need and would even let them approximate the approach you suggest above if that is really what they want.
> 
> Interesting idea.  So allow a plugin to set up an Write page that has, say, a drop down listing multiple Post Types.  The "List/Edit" page could be (optionally) show multiple types, and have a drop down with a "Filter" button.
> 
> Note that for the write page, it would only work for two Post Types that have all the same meta boxes -- unless you want the page to reload when changing Post Type.  (Ajax is nice, but we should not be dependent on it for functionality.)

Well, I was thinking more of an interstitial page that listed the content types and then clicking on them would take the user to the correct add page (this is how Drupal does it.)  If the functions were modular enough then they could be assembled to do this.  OTOH, I'm not advocating for a feature that would work that, but believe it would be good if the current features would have the required flexibility to work in that manner.

>> (And while we are add it, can we tackle one of my pet peeves?
> 
> No.

;-p

> Is the existing Menu API really that difficult to use?  One good tutorial should sort that out.  Abstracting it is going to just artificially limit what you can do (or have a ridiculous number of parameters). 

For the record, I'm not that overly concerned about the difficulty of the menu APIs. Yes, I think the menu functional are poorly designed requiring many positional parameters instead of an array containing named arguments but all in all they are usable and besides that wasn't the direction I was trying to take things. I was instead primarily asserting that moving to Action menus would be probably not be a great idea, secondarily having a modular architecture for what you were proposing would be important and finally that basic admin UI support for post types should be in the core.  

I think we are in full agreement except on weather there should or should not be any admin UI for custom posts built into the core.

>> What's more, minimally I think it would be really a good idea in 2.9...
> 
> 3.0, since 2.9 is in feature freeze...

Meh.

>> ...to have an "Post Types" link under the Settings menu that lets user add new post types with nothing more (to start) then just a way to add new types names and see a list of those names.
> 
> I disagree.  In a default install there is no need, and what you describe is too little use without more custom code via a plugin anyway.

Why is there no need?  If I can add a new content type (i.e. an "event" for example) in the UA then I can add-hoc use custom fields for start and end times and I can write custom loops in the theme to pull a list of events.  It's one tiny bit of additional functionality that would enable a huge amount of value. Requiring a plugin to expose such a core feature seems backward.

Besides if that feature is blocked from the core then every plugin is going to (have to) implement the exact same "core" functionality only will all implement it differently.    It'll be the same fustercluck that we had with post images where every image plugin implemented a different and incompatible way to add a post image. Thank goodness that 2.9 finally addressed that issue.
> 
>> In combination, I think having a list of known types for a given site stored in wp_options is really important.
> 
> How is it stored now?  2.9 allows you to register Post Types now, doesn't it?  Where is it stored?

Only in memory.  Post types are not (currently) serialized to disk in 2.9.  Here's the code:

function register_post_type($post_type, $args = array()) {
	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;
}

-Mike