CPT enhancements
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 meta capability handling for custom post types
- Improve the custom post status API, 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 category or tag 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.)
Tom, 
Aaron D. Campbell 5:42 pm on September 13, 2010 Permalink
Opt-in ability to include your custom post type in the main RSS feed. It’s not exceptionally difficult now, but I think it’s going to be a pretty common task.
Andrew Nacin 5:44 pm on September 13, 2010 Permalink
Good call. That’d be part of the other views aspect. My take — When I’ve done these recently, I’ve found that I’ve wanted to prefix the title of certain custom post types, as otherwise they are without context. We’ll be exposing filters on the_title and such so I don’t see that to be an issue though.
Mark Jaquith 2:56 am on September 14, 2010 Permalink
I’m not so sure. If you want it in the posts feed, make it a post. CPTs are for non-post content.
Mike Schinkel 3:30 am on September 14, 2010 Permalink
“CPTs are for non-post content” – I couldn’t agree more. Unfortunately probably half of the examples I’ve seen have written about CPTs show them used for variations on Posts (*not* the WordPress team, but others.) Those articles then influence many others and so you have lots of people using CPTs for things where they aren’t really the best solution. I’m thinking its an education issue, and maybe the stuff that Ryan’s working on (#14746) will give people a more obvious alternative for addressing the needs people have been creating Post-like CPTs.
filosofo 6:03 pm on September 13, 2010 Permalink
That seems like a no-brainer: if a custom post type is public and has that taxonomy (e.g., “category”) registered, it should show up in queries for objects in that taxonomy.
demetris 8:22 am on September 21, 2010 Permalink
Absolutely! Is there a ticket for that?
Victor Teixeira 10:39 pm on September 27, 2010 Permalink
I created a ticket for this sometime ago. See #14589.
Kunal 6:11 pm on September 13, 2010 Permalink
A few more hooks in wp-admin/post.php, edit.php etc. to add the ability to modify bulk action lists and the corresponding actions on posting, place metaboxes before the content area, removing the “Edit | Delete | etc. tags from the Title column value in the post-type table and adding an extra column for it (with CSS hacks to put it back in place) — that way I don’t have to add the corresponding code back when I remove the title from the posts column.
Mike Schinkel 6:27 pm on September 13, 2010 Permalink
> “Opt-in default meta capability handling for custom post types”
Not sure what that means…?
Andrew Nacin 6:33 pm on September 13, 2010 Permalink
#14122
Mike Schinkel 6:31 pm on September 13, 2010 Permalink
It would be nice to have an easy way when defining the post type to say under what menu it should be referenced. For example I might want a Movies custom post type and an Actors custom post type but I want to put the list of Actors as a menu item for the Movie and just let the user go to the Actor list page to add an Actor. Same would go for taxonomies, I guess. I’ve seen several people ask about how to do this on WordPress Answers.
Andrew Nacin 6:35 pm on September 13, 2010 Permalink
Oh, yes, I forgot about that. I’m starting that here: #14145.
Jesse Sutherland 6:39 pm on September 13, 2010 Permalink
It’s my understanding that you can’t use wp_query to filter by post type and taxonomy at the same time. I was told so here. It’s been on the bug tracker before: here and here. As mostly a front-end guy myself, it seemed totally obvious that I would be able to combine custom post types and custom taxonomies to filter with. That would be my enhancement request.
Ünsal Korkmaz 6:54 pm on September 13, 2010 Permalink
Custom attachment types considering? I think its about custom post types.
For example, i want 3 different type of photo/image type for my project and i dont want to see all photos in same gallery.
(sorry for bad english)
Mike Schinkel 5:59 pm on September 15, 2010 Permalink
I don’t think you want different post types for different usages for images. Why not use taxonomy to classify maybe using the Media Tags plugin? Or maybe this #14746 will address?
Stephane Daury 8:03 pm on September 13, 2010 Permalink
#14649 in regards to silent fail when registering a CPT namespace longer than 20 characters. Especially vile when auto-computing CPT namespaces.
Andrew Nacin 8:06 pm on September 13, 2010 Permalink
I don’t think we even perform sanity checks for usernames (related #11959), and we don’t for option names — we’ve generally been independent from the underlying schema. That said, auto-computing CPT namespaces as a use case makes perfect sense. Perhaps these should be tackled at once.
Stephane Daury 9:01 pm on September 13, 2010 Permalink
Sounds reasonable.
Ron 10:04 pm on September 13, 2010 Permalink
I would add something to the register function like supports ‘blog’, ‘archive’ or similar that was the signal to include it what have traditionally been blog queries: searches, tags, categories, etc.
Mike Schinkel 12:44 am on September 14, 2010 Permalink
+1
Nico 9:52 am on September 14, 2010 Permalink
That’s a good news to allow cpt archive to be displayed. I’m using custom post type/taxonomy and regrets that WP doesn’t deal with permalink structure (see this ticket : http://core.trac.wordpress.org/ticket/13889).
Hope it will in next release.
Boone B. Gorges 12:26 pm on September 14, 2010 Permalink
I’d like to see finer-grained controls over what is currently covered by show_ui. Right now it’s impossible without hackery to hide a CPT from the menu but at the same time allow access to the Edit screens for that post type (or vice versa, though it’s harder to envision a use case for that). Maybe show_ui could be shorthand for show_menu_ui and show_edit_ui, so you could get more fine-grained if you wanted to.
Andrew Nacin 3:38 pm on September 15, 2010 Permalink
Boone, I think you’ll find this use case covered by #14145. Specifically the ability to set it to false.
Anna 11:58 am on September 15, 2010 Permalink
The simple way to manage relationship between posts of defferent types.
For example in my project I have post, event and galleries post types and any particular gallery could be related both to posts or events.
I’ve read a various discussions about how to store such relationships using taxonomy or postmetas – but… they don’t seem to be efficient because overcomplicate so simple and commonly needed (in case of CMS) task
The second issue – permalink structure…
For “normal” posts we have simple dialogue under settings menu to customise the structure… but for custom post type – only “rewrite” argument while registering. So you need to add rewrite rules in code if you need something more complex or use some pluging for that.
Mike Schinkel 5:54 pm on September 15, 2010 Permalink
Both excellent suggestions Anna. Here are two trac tickets on the issues: #14513 & #12935 .
Derek Perkins 4:23 pm on September 16, 2010 Permalink
I think that this is the single most important change that needs to be added besides exposing CPT archives. It’s being hotly discussed here, http://core.trac.wordpress.org/ticket/14513, so if you’d like to weigh in there, that would be great.
In the short term however, the plugin Posts 2 Posts (http://wordpress.org/extend/plugins/posts-to-posts/) works great. I’ve been beta testing for scribu, and the updated version that supports metadata about each connection should be released soon. It’s a well coded plugin with a super easy to use default interface.
Anna 9:57 pm on September 16, 2010 Permalink
Thank you, Derek, for your recommendation… I’ve tried the post2posts plugin – but for unknown reason it did not work on this particular project – interface appeared but was not able to detect my posts and could not therefor store relations.
Actually I’ve failed to find what was wrong with that so there was a choice – to fork the plugin or to write something myself
))
Derek Perkins 10:31 pm on September 16, 2010 Permalink
I’d give it a try again once version 0.4 is released. I think you’ll be pleased with the results.
Mike Schinkel 11:26 pm on September 16, 2010 Permalink
JMTCW, and this is no slight on scribu who is an excellent programmer but I really don’t like the non-standard way in why Posts 2 Posts uses the database. It overloads field meaning which in may experience is almost always discovered to be a mistaken down the road. FWIW.
Derek Perkins 7:25 am on September 17, 2010 Permalink
What exactly is non-standard about it or overloading field meaning?
Mike Schinkel 3:38 am on October 19, 2010 Permalink
Sorry I missed your question back when you asked it. When I made the comment you replied to I was referring to the fact that the p2p plugin originally stored it’s foreign key fields in the wp_terms.name field with “p” as a prefix and that’s a non-standard approach for relational database foreign key implementations. At the time scribu was claiming that it was an acceptable approach to use the taxonomy system in that way because it avoided adding a new table. I was arguing against the use of the taxonomy system to relate posts and in favor of a new table (see http://core.trac.wordpress.org/ticket/14513) but I was told it “was an edge case” by Jane and westi. Looking at the p2p plugin now it seems scribu has added two tables; a wp_p2p table and a wp_p2pmeta table so I take back what I said now that p2p has been updated to use (a) new table(s), and I guess my argument regarding the need to add at least one new table made sense to scribu all. Now if the core team would just consider adding something like this to core…
Lee Willis 1:55 pm on September 15, 2010 Permalink
Improvements to how you theme CPTs (& Custom taxonomies for that matter).
http://bit.ly/bFMpTo
Mike Schinkel 6:15 pm on September 16, 2010 Permalink
Here’s another simple one (that I just had a need for for several different things): A “single use” (aka singleton) post type. This would be useful for what we’ve been using pages for use as a “Directions” or “Contact Us” page but where there are one or more custom meta boxes that only apply to the page of that type. It would also be useful or a complex Settings page where the features or a post type (custom fields, featured image, taxonomy associations, etc.) would be very useful
It wouldn’t have a post list or plural labels and would only ever have one instance and It’s default URL would be off the root. When registering it should have a way to indicate under which menu a menu item for it should be linked but by default it could go under a “Miscellaneous” menu section.
This can already be done it just requires lots of tweaking of the values after post type registration. It would be nice if all that tweaking could be done as parameters to register_post_type().
Andrew Nacin 9:18 pm on September 16, 2010 Permalink
I don’t see why these aren’t just pages with special handling?
The admin menu aspect is otherwise handled for post types in an aforementioned ticket.
Mike Schinkel 11:24 pm on September 16, 2010 Permalink
Pages with custom metaboxes is exactly the solution we came to plan on though I haven’t implemented it yet. But it’s inelegant and potentially fragile.
When the add new or edit screen loads in the admin for a Page we’d need a way to identify the correct page type from within the plugin code. I can think of the follow ways:
1.) By post title. This completely fragile and would be least recommended.
2.) By post name (slug). This is not bad but WordPress has a nasty habit of adding “-2″ to post names or a zealous SEO could decided to add keywords to an existing site.
3.) By post ID. This is okay but requires somewhere else to let the user specify it and they might delete the page and re-add it thus severing the connection and breaking the page
4.) By hidden taxonomy term. This is not bad but plugins that don’t realize some terms should be hands off can expose this to end user modification and some code needs to add these.
5.) By a hidden custom field. This is least bad but must be added somehow by some code somehow which requires more knowledge than how to call register_post_type().
Another issues is if the singleton is not being used like a page then all queries for post_type=”post” are suspect and may need to be filtered.
Anyway, was just describing what my client and I identified as another use-case.
Victor Teixeira 11:05 pm on September 27, 2010 Permalink
Take a look at the wonderful fields plugin: http://calce.net/fields/
It allows you to create metaboxes for one specific page and works beautifully.
Daniel Bloemberg 7:53 am on September 17, 2010 Permalink
Possibility to predefine a category (categories) to a CPT. Users using the Movie CPT wont have to remember to assign the Movie category.
John Blackbourn 5:00 pm on September 17, 2010 Permalink
I just found an annoyance with CPTs while working with them today.
Often I’ll set up a WordPress install with a Page as the front page, and a Page at /blog/ to display the blog posts (from Settings->Reading). I’ll then set my permalink structure so it has /blog/ prepended to it – eg. “/blog/%year%/%monthnum%/%postname%/”. This means all blog posts are within /blog/.
When I add a new hierarchical CPT it’s URL gets prepended with /blog/, giving me a URL such as example.com/blog/foo/bar/ instead of example.com/foo/bar/. This means this CPT is behaving differently to WordPress’ built in Pages yet they’re both hierarchical.
So my request is that a new parameter is introduced to register_post_type() which allows you to specify whether the rewrite rule follows the rules of Posts (taking into account anything in the permalink settings) or whether it follows the rules of Pages, and simply works from the root of the site. The former should be the default because it’s the current implementation.
Thoughts? Should I open a ticket for this?
Andrew Nacin 8:21 pm on September 17, 2010 Permalink
Already in 3.0.
register_post_type() takes a rewrite argument. This argument can be true, false, or an array. If an array, you can do some adjustments to the rewrites that are added. Specifically, two arguments: slug (defaults to post type slug), and with_front (default true). Setting with_front to false will have it avoid /blog/.
John Blackbourn 9:14 pm on September 17, 2010 Permalink
Excellent, I hadn’t seen that. Thanks Andrew.
Victor Teixeira 10:56 pm on September 27, 2010 Permalink
The possibility to filter taxonomies by post types with url rewriting.
Ex: site.com/schools/cities/new-york/ would display all schools (post type) on the New York City (taxonomy).
Should be simple as this: if a taxonomy appears after the post type on the url, then it gets filtered by it.
See: #14497 and #14502.
Also another good feature would be the ability to create menus for custom post type archives.
Tom 10:20 pm on November 16, 2010 Permalink
I know that I am late to the party here with this question but I am wondering if there will be a way to add custom post type archive pages to the nav menu? Also will the parent page for custom post types continue to be the “Posts page” or is there the potential that the archive page for each post type might be able to be the parent page and have a class applied as such when the menu is rendered?
Andrew Nacin 1:08 am on November 20, 2010 Permalink
We haven’t really thought about that yet, but I know I’ve mentioned it in #13818 as an option. Patches welcome