[wp-hackers] Custom Post - implementation specifics

[Stephen Rider]

On Dec 5, 2009, at 11:59 AM, Mike Schinkel wrote:

> On Dec 5, 2009, at 2:52 AM, Ptah Dunbar wrote:
>> To quote Stephen:
>> 
>>> In a way it's a shame that in Admin we moved away from "Action" ("Write". "Edit") menus toward "Thing" ("Posts", "Pages") menus
> 
> My first reaction is that going back to Action will add complexity to the default use case for blogging, i.e. to work with Posts.

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.

Also, I agree with Mike -- "Pages" and "Posts" menus is easier for the layman to figure out.

> 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.

In other words, leave it flexible.  Plugins can readily add menu items right now.  The **primary** thing I have in mind in all this is making it very easy to write the function that defines the Edit or Add page for a post type.

* Define a Post Type?  Already exists.

* Add a menu item?  Already exists.

* Define the Edit Page?  Possible, but too complicated.  Simplify this.

* Define  the page that lists those posts?  Difficult.  Abstract the existing system to allow custom pages.

> And having their own admin menus could be useful because each content-type could easily have special admin options, i.e. Members could have "Interests" and "Purchases" options and Companies could have a "Contacts" and "Products" options. (Please don't fixate on my examples and debate what WordPress is appropriate for; they were just hypothetical examples.)

Good examples.  Making the point that we should leave the menu additions up to the plugin, and that code already exists.

>> If that's too much abstraction, then consider:
>> 
>> register_post_type( 'articles', array( 'admin' => 'Articles');
>> 
>> Which just creates the write and edit submenus for the Articles post type, and the developer would need to call the necessary add_meta_box() functions for their page elements on the write page.
> 
> I would lean toward something like that, yes.

I wouldn't even go that far.  Registering the Post Type and creating the menu items are two separate steps.  I don't think *two* lines of code is too arduous a demand to put on plugin authors.  ;-)

> Further, I think it would also be ideal to be able to remove both the Post and the Page admin options

Agreed.  I think you can already do this though.  Perhaps a wrapper function to make it easier....

> 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.)

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

No.


;-)

>> All in all, adding administrative features for custom post types should be dead simple. The developer shouldn't have to do the same work required to create custom plugin pages (using the menu API, settings API, handling option sanitizing, etc.) as those are two distinct administrative task.
> 
> 100% agreed.

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). 

> 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...

> ...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.

> 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?


-- 
Stephen Rider
http://striderweb.com/