[wp-hackers] Custom Post - implementation specifics
jordi at jcanals.cat
Sat Dec 5 11:00:00 UTC 2009
2009/12/5 Ptah Dunbar <pt at ptahd.com>
> 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, as this makes it more
>> difficult -- or at least more bulky -- to incorporate custom post types.
>> Where previously it would have been intuitive to add a new item or two
>> under "Edit", now to follow the existing structure it would be a case of
>> adding a whole new top menu for each new Post Type, which would get big
>> pretty quickly.
> After custom post types becomes mainstream once 2.9 ships, people are going
> to face the hassle of creating admin menus for them. Going back towards the
> "Action" type menus will make things A LOT more simpler and consistent with
> the WordPress publishing experience. Users wouldn't have to think twice
> about which menu they need to click on to publish content to. They would
> just click under "Write", and available post types will be presented as
> submenu items. This is a major prerequisite before any administrative
> features for custom post types begin.
I agree with that. Going towards to 'Action' type menus will make it more
simpler to code and more easy to use. Creating some custom post types with
'Action' menus would help to manage authors as them will have only a simple
'Add Content/Manage Content' menu instead a lot of menu boxes one for each
post type. I'm thinking on the point of view for an Author or Editor, who
only manage content and do not deal with other settings.
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.
> 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.
Would be really useful to have something like that to easily create new
content types. As soon as we create a new post type, it should create the
corresponding menus in the proper 'Action' menus. If the API also sanitizes
the content (at least a basic sanitize), will help to make the plugins more
secure and robust. I think for a lot of plugins sanitizing is the most
forgotten thing. Handling the new post type default options is also
interesting (I don't know if 2.9 already does it), as we can define all
about categories, tags, comments and so on at the moment we create the new
custom post type.
More information about the wp-hackers