I’m trying to put together a small but well-defined set of enhancements that custom post types deserve consideration in 3.1.
What I have so far is this:
- Opt-in archive/index pages for custom post types
- Opt-in default metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. capabilitycapability A capability is permission to perform one or more types of task. Checking if a user has a capability is performed by the
current_user_canfunction. Each user of a WordPress site might have some permissions but not others, depending on their role. For example, users who have the Author role usually have permission to edit their own posts (the “edit_posts” capability), but not permission to edit other users’ posts (the “edit_others_posts” capability). handling for custom post types - Improve the custom post status APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways., and make them type-specific
Beyond that, I’m also thinking about opt-in ways to get more than the default post types displayed on other views. As it is now, we currently also allow searching for pages for example, so we would more or less be extending that. You may want to allow a post type to show up on the categoryCategory The ‘category’ taxonomy lets you group posts / content together that share a common bond. Categories are pre-defined and broad ranging. or tagtag A directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.) pages, for example. The API ideally wouldn’t be more complicated than, say, register_taxonomy_for_object_type.
What are your thoughts? Let me know your pet bugs, peeves, and workarounds. (Just keep in mind we’re aiming for small, defined scope here. KISS.)