WordPress 3.0 and Custom Post Types
There’s been a lot of talk about custom post types, and I know many people are looking forward to it. Unfortunately, I think some (perhaps many) of those people are going to be disappointed. Custom Post Types might not be what you think they are.
I blame the naming, really. “Custom Post Types” makes the implication that these are “Posts”. They’re not. “Post Type” is really referring to the internal structure of WordPress. See, all the main content in WordPress is stored in a table called “wp_posts”. It has a post_type column, and until now, that column has had two main values in it: “post” and “page”. And there’s the big secret:
“Custom Post Types” are really Pages.
Sorta.
For a long time in the early days of WordPress, it just had Posts. But hey, no big deal, because it was just running a big Blog anyway, right? The Posts appeared on the Blog page (and in the Feed) in reverse chronological order. Each Post could appear on its own URL, using the Permalink structure.
Pages came along and changed that.
- Pages don’t appear on the Blog. Or in the Feed.
- Pages don’t even really have dates and times on them that usually get displayed.
- Pages have their own URL at the root of the website, outside the Permalink rules.
- Pages even have hierarchy in their URLs, if they want.
Pages, however, do live in the wp_posts table. So post_type exists to handle that. When WordPress is building the Blog, it looks for post_type = “post”.
Bring on the “Custom”.
Now we have these Custom Post Types. Or rather, custom post_types. Instead of “page” or “post”, we can have “custom”. Or “fred”. Whatever we like.
But how do these new post types get displayed? What do their URLs look like?
Well, these are custom, and they can be customized. You can give them their own space on the website. So if I want them to live at /custom/page-name, then I can. If I want them to have hierarchy, then I can do so. Justin Tadlock explains how they can be made to do this quite well.
But they are still not Posts.
They do not show up on the Blog.
They do not appear in the Feed.
This is a matter of definitions, really. See, the Blog is a reverse chronological order of the Posts. That it what it is defined to be. The Feed is basically the same thing, in feed form.
So all of you thinking of a custom “Podcast” post type, you’re in for a disappointment.
So what’s the big deal?
Well, all that said, custom types can have their own systems of doing things. They are custom, and as such, they are customizable.
If, for example, you wanted to have them appear on their own “blog” area, or in their own “feed”, then sure, that’s entirely doable. You can make a function to produce your custom feed. You can then call “add_feed” to add your feed. You can create single-type.php templates in your theme that will be used for your custom type. You could even make a “blog” out of your custom type.
And doing it the other way is possible too. You can adjust the “Blog” to show your type. You could change the “Feed” to show your type as well.
But these things are NOT the default way of doing things. There’s no code in there to do that, and there’s very likely not going to be. If you want your type in the Blog, in the Feed, then you have to do it yourself. The URL is NOT easy to customize and play around with. The rewrite system is unforgiving, and you have to stick within a set of rules for things to work well.
However, should you? Let’s say you make a “Podcast” custom type. You can go to the effort of putting them in the feeds and making them show special on the blog… but you could already do that with a “podcast” category. And it’s much easier to do a category and customize categories than custom types will ever be.
Something like 80% of the uses I’ve seen for “custom types” would be better served by making normal posts and using some existing method to separate them or to otherwise mark them as special.
So what are they good for?
What if you could install a forum on your site? bbPress is pretty good. But it could get all complicated to set up and such. Well, plugins are pretty easy. But all those forum posts have to go somewhere…
Custom Post Types is a way for plugins to define types of content for themselves.
A bbPress forum could store every post in the forum as its own custom post type quite easily.Or a wiki plugin could store each of its own pages as a custom post type. Things like that.
See, they’d get their own URL handling automatically, and they wouldn’t need weird database handling tricks.. It makes things much simpler and easier for those plugins to do their thing when they have the backend support for it in the core.
Some of you are thinking “Okay, so plugin authors can make better use of them. I won’t have to write a lick of code, I’ll just install a plugin that makes my type and handles the stuff for me.” And yeah, you can do that.
But then you’re wedded to that plugin. WordPress doesn’t know about your custom posts. If you remove the plugin, your custom posts are still there, but now they’re completely invisible. Can’t be pulled up, seen in the admin, the URLs all stop working…
Wrap it up, son…
Using custom post types right now is, for most people, a bad idea. Only specialized usages really exist for them… for now.
For the long term, WordPress will probably use them a lot more extensively. And plugins can make great use of them for all sorts of things. But you, as a user, probably don’t need to be messing with them. Not if you’re just creating a website or writing a blog. Not right now. Wait for the plugin and core development to catch up to the potential. Using them early leaves you open for a world of confusion and grief.
Thanks. I came into contact with your article through delicious. It is very usefull to get clear and practicle insights into wordpress (i bookmarked it for later use).
Wow, just the kind of commentary I’ve been looking for. I’ve just become aware of Custom Post Types and I’m thinking they may be what I need. I like the idea that they act more like Pages rather than Posts. I’m developing a site that I had anticipated might have several thousand Pages (not Posts) and was concerned about architecture as well as speed issues. Basically using WordPress as more a CMS than straight blog but still using the normal blog/category/tag setup fairly extensively. Should be a large site in time. I do like the ability to make these custom posts hierarchical.
I would like to know more about how WP 3.0 treats these ‘posts’ such as how they are organized (archive pages, integration into navigation, etc.) and permalink issues. Particularly how the Custom Post Types would compare to Pages in overall site efficiency and user experience.
I’ve searched quite a bit and haven’t found much on the above – maybe I’m just looking in the wrong places. Or maybe it’s just too early since it’s still in beta. Any recommendations?
Thanks
Otto, thanks for writing this article. I think a lot of people are confused about what custom post types are for, including myself until I read this. While WP 3.0 and the new default TwentyTen theme don’t have “podcasts”, they do have two “custom” categories for gallery items and asides. The theme simply displays the posts differently if either of those categories is specified. I was curious about why they handled those things that way, but it makes perfect sense with how you’ve described things here.
Now I do wish that custom post types would be more flexible. Why not have parameters that tell WP to include the post type in the main blog or in the main news feed or whether it should have its own blog or news feed. Then in your examples above, custom post types could be used for both “podcasts” and for plugins to store their own data and expose it or not. Custom post types do already let you specify whether the posts should show up in the site search or not.
I have been wanting to write a simple forum plugin for WP that primarily gets its features from the core WP itself. In my case, I want it to be easy to make a post and have it show in the blog and also in a forum. I also would like the forums to have their own RSS feeds.
At first, I was thinking of just creating categories for these “forum” posts and having a custom category template in the theme to display the “forums” in a more tabular layout like a traditional forum. When I first read about custom post types just before WP2.9 came out, I started thinking custom post types would be perfect for what I wanted to do. However, I couldn’t make a single post that was both an article and appears in the forum and I would have to create my own RSS feed in addition to all the index/forum/post/reply page layouts. So it really doesn’t make this any easier to do.
So in its current state, it does seem that the custom post types are most useful to plugin developers that would normally store their data in completely custom database files and this is a much easier and standardized way to handle that.
The reason it doesn’t have that sort of thing by default is because it would be rather useless to do so. You already have a post type that can go into the blog and the feed: “post”. There’s no advantage in defining another one to go in there. If you want to separate different kinds of posts, then that’s exactly what a taxonomy is for.
See, what you really want is not a podcast post type, but a taxonomy that separates podcast posts from other posts. Categories is the easiest taxonomy to use for that sort of thing, but it’s entirely possible to make custom taxonomies as well.
“Post type” defines the type of the data. A taxonomy separates similar types into different categories. Taxonomies are way easier to work with for most people’s purposes.
I gotta say I think that’s a marked lack of imagination. What if I want a Podcast type to appear in wp-admin, and what if I want the edit screen to contain boxes to fill out for Title, Audio File, Description, Length, and Format Type? And what if I don’t need the tag and category boxes on that screen? And what if I still want them to appear in feeds alongside blog posts? If you know your way around code, custom post types let you do that.
Sure, the old way, you could hack your way around with custom fields (although try explaining those to a client — I once had a guy who couldn’t find his “news” section in wp-admin because it’s called “posts”) and try to use posts and categories for *everything*. But for more complex sites that amounts to a series of inelegant hacks.
WP hasn’t fleshed out the functionality of custom post types yet — they need a long way to go, including easy feed integration and easy archive pages. And if I had my way the entire table would be renamed wp_content and we’d be calling everything a “custom content type” to end the “posts” confusion. But it’s the future. It lets you actually structure sites the way you want instead of hacking your way through WordPress’s older, limited, blog-centric system.
What you really want isn’t custom post types, it’s custom taxonomies. Defining new post types just to get an admin space for them is a pretty poor way of doing things.
I would have to agree, and yet, disagree!
I think your right, 80% of people are using custom post types for things that are really “posts” and better served with category taxonomy. But to be honest, the way that you separate posts by different categories with all of the custom templates etc, is JUST as difficult IMO.
If your running the website yourself, and are at least a front-end web guy, no problem. You can easily remember to check off the appropriate check boxes, template files, custom meta data etc.
People build wordpress sites for clients. By the jillions. The reason so many people are loving it, is for the clients. Custom Post Types much more “intuitive” and distinctly separated in the admin panel.
Technically I get your point, and it is really true. But practically is where I disagree.
Take say a post type called “Articles”. Technically, just a post with a particular taxonomy right?. But practically it is VERY different from a “blog post.”
I’m new to WP, and have been playing with custom post types, and these babies is really the ONLY reason I’m porting a project over to WP. I agree that once core catches up on some key features that are currently missing, they have HUGE potential. I definitely could be blowing smoke, as I’m much more a front end guy, but sometimes ya gotta chime in.
CPT FTW!
/rant
If it’s difficult to use categories and such, then you should look into creating Custom Taxonomies instead.
Separation in the admin panel is not a good reason to create a whole new “type”. Not if what you really need is to separate existing posts by some other factor. That’s what taxonomies are explicitly designed for.
Go ahead, do what you like. But when you encounter all sorts of difficulties and problems, don’t say I didn’t warn you.
Thanks for this article. This is the only place I’ve seen this very important point spelled out so clearly. You’ve saved me some precious time that I was about to waste setting up a Custom Post Type where it was not needed!
Having said that, I have to agree with some of Andrew’s comments. It would often be very useful to have a custom UI for different “Post” types beyond simply creating custom taxonomies.
For example, say I have a site that publishes reviews for games, books, movies, etc. I want each review to appear in typical blog format on the homepage and in the feeds. For movies, I want a category to specify MPAA rating. For videos, I want a similar category for ESRB rating. For book reviews or non-reviews blog posts, I don’t need either rating.
Without custom “Post” types, I have to include both taxonomies on the New Post form, whether they are needed or not, plus another taxonomy just to specify whether it is a movie, book or video game review. The way most people (at least based on the blog posts I have read) are conceiving of Custom Post Types, this is exactly the sort of problem they should solve.
And Andrew’s point about making the interface more intuitive for the non-technical user should not be shrugged off so dismissively. Based on much past experience, I GUARANTEE you the first dozen movie reviews posted will have an ESRB rating checked but will not have the “movie review” category checked.
Edward Murphy (of Murphy’s Law fame) originally stated, “If there’s more than one way to do a job, and one of those ways will result in disaster, then somebody will do it that way.”
The take-away lesson is: Don’t give your users the opportunity to make mistakes.
Thanks to you, I will not be making the mistake of using Custom Post Types. But I will be constantly wishing I could!
I have to agree pretty much completely with you Doug. So many “names” in wordpress are politely bashing people because they are trying to use Custom Post Types in the wrong way, but really that is how it should work in the first place. Otto says “Separation in the admin panel is not a good reason to create a whole new “type”. Not if what you really need is to separate existing posts by some other factor. That’s what taxonomies are explicitly designed for.” But he didn’t understand what the problem you were trying to describe was in the first place. It wasn’t about taxonomies like everyone wants to turn around and point out, it’s about having true custom post types that work inline with normal existing posts.
Like you said, if you have ever designed something for an client, and not personal use, you would see completely how this would be an extremely useful feature. Right now we are stuck with using custom fields and trying to explain to the client in explicitly detailed instructions how to properly define key pairs for specific post types that all still need to be displayed inline with the regular “blog”. Why is it so hard for people to understand that being able to use custom post types as an ability to specifically define certain REAL post submission meta boxes and separate them out in the dashboard is a useful thing.
People keep spouting off about taxonamies, but that’s not even what we are talking about. If I have a category in a clients site called “Portfolio” and another called “Quotes” that I want to be able to display inline with normal posts and not completely separated and aside, then I want to be able to post a thumbnail, description, and specific custom meta data in the submission panel for the Portfolio post type. For Quotes I want to show a Quote Author and actual quote field. If I have a custom taxonomy for those type of posts, I only want to show that taxonomy for those posts. What I don’t want is to have a generic “Submit New Post” page filled with irrelevant meta fields and taxonomy options in order to cover each post types needs. Or just as worse, using custom fields on that same global submission page and trying to explain to the client how to actually use it.
Custom post type works perfectly for this, but the in-ability to treat these the same way we do normal posts is mind boggling. If I want to “opt out” and have my custom post type be absolutely separated from normal posts, with a completely separate taxonomy, (ie: custom content types aka the way “custom post types” really work right now) then I should have that ability. But that should be an opt out, not the default settings.
WordPress hasn’t done anything in pretty much as long as I’ve been using it that remotely aggravated and disappointed me as much as this. I’m not saying I don’t see a use for the way custom post types currently work, because I absolutely do, but I definitely think they dropped the ball on it and forgot to include a extremely important use for it.
But that’s my point. You don’t need to create a new post type to do any of what you’re talking about. What you want is just to create a new panel in the admin area with specific fields. You don’t need to create a post type to do that, you can do it with stuff that’s existed ever since WP 2.6 or thereabouts.
If all you want is a separate space to create posts, then create that space. Don’t try to create a whole new type just for it. It’s overkill.
This might be a good place to start:
http://codex.wordpress.org/Adding_Administration_Menus
I’m familiar with the adding administrative menus and the current ridiculous amount of code it takes to create a custom write panel. I still don’t understand how you don’t see the difference in how easy it is to register post types and have it automatically create very specifically defined write panels, compared to how much coding is required for a regular post write panel.
Compare: http://wefunction.com/2009/10/revisited-creating-custom-write-panels-in-wordpress/
——-> http://codex.wordpress.org/Function_Reference/add_meta_box
To: http://kovshenin.com/archives/extending-custom-post-types-in-wordpress-3-0/
I’m not trying to be argumentative or rude, I really love your site and you always have extremely informative posts, but I don’t understand how you don’t see how much of a significant difference it is, or the value in being able to do it so easily. Maybe I’m still just missing something and it’s not clicking for me, you definitely have far more wordpress knowledge than I do. But again, from where I’m standing there is just a big difference in how easy it is to create a custom post type compared to the wordpress knowledge it takes to write a custom write panel. Creating a new post type to do this only overkill because of the way they implemented custom post types in the first place, which is pretty much the point you seem to be missing. The current method of creating a basic custom write panel for a regular post seems like overkill to me compared to how incredibly easy the custom post types method is. Again, I’m not saying I don’t see a use for the way it’s implemented because I definitely do, but there is still a huge difference in what’s required, which is exactly the reason so many people are incorrectly trying to use custom post types and getting so frustrated with it in the first place.
I’ve got a few ideas on this topic, and I feel a new post coming on. I’ll write a new post or two about it this weekend. Hopefully.
BTW, you’re not argumentative or rude. I see your point. Sorta. I’ll explain later. When I’m sober. 🙂
BTW, emailing me to remind me about the topic helps. My memory may be crap, but emails last until I read them and take action. You may have noticed that I haven’t been responding on this blog a lot recently… Reason: too many emails. 😉
Otto, I hear what you’re saying, but it (from my not-terribly-well-informed perspective) that an option to make podcasting much easier seems to be presenting itself in Custom Post Types and that it meets a need (UX-wise). Your argument sounds like “it’s just not ‘right’; use custom taxonomies.”
Is there a way to use custom taxonomies that meets the need of making it very simple for a novice to handle posting podcasts without needing to learn “obscure” settings?
[…] WordPress 3.0 and Custom Post Types » Otto on WordPress […]
[…] WordPress 3.0 and Custom Post Types is a level-headed explanation and assessment by Otto. […]
Thanks for explaining what custom post types are and are not. Good Post.
Now that I know, it helps me put in perspective the different conversations I’ve heard about how earth shaking this new release is. Honestly, and disappointedly, I have to say, custom post types… big deal. I’m sure they will be great for a number of uses but they still have the same limitations and default fields as posts and pages. I was hoping for something that allowed building a new content type with a new set of fields, or at least make custom fields simpler for end users.
Don’t get me wrong. It can be awesome. But one step at a time, you know?
I just wanted to say thanks for writing this. I can’t tell you how many times I’ve had to explain to people that what they really need to use is simply the “post” post type. People are trying to do all these weird and complicated things for something that already exists in WordPress.
Custom post types can be a very powerful tool, but first you have to grasp the concept of what they are. Usually, that comes with an understanding of what taxonomies and custom fields are as well.
[…] Otto has an equally good overview of what should and should not be a custom post type and how to use […]
[…] of the cool things they can do. He also explains how to implement them within WordPress.Likewise, Otto has an equally good overview of what should and should not be a custom post type and how to use […]
[…] Otto has an equally good overview of what should and should not be a custom post type and how to use […]
[…] Otto has an equally good overview of what should and should not be a custom post type and how to use […]
thanks Otto, I’m currently building a new blog and thought I’d create a custom post type for separating it in the backend to make it easier for the client. But then I started to have doubts, as I started to understand how it works ,and you just confirmed that all I need is the custom taxonomies and leave the custom post types alone
cheers!
While I don’t confuse custom post types with posts and don’t expect them to show up with my other WordPress posts in the blog or feed unless I customize them to do so… I can see how others might get confused.
I think part of the problem was calling them custom post types. Really they are Custom Content Types. They just happen to be stored in the post tables, but so are Pages and people don’t confuse Pages with Posts. I think had theyncalled them Custom Content Types it would have been a better term and less blog oriented as they can be used for anything and most people are using them for non-blog related content.
WordPress is a CMS not just a blog application. Its time they started using terminology that was more in line with a CMS.
I think the OP misunderstood the power of Custom Post Types. I agree with you, we should start calling them Custom Content Types.
Pages are posts. Period. There is no difference in the data, except the “post_type” column. The only difference is how WordPress handles them by default. Any theme coder can customize template files to handle pages like posts, with an index of pages, sort by dates, or create a custom feed template for pages. You could even easily have pages included in the index.php loop. You wouldn’t want to of course, because that’s not the purpose of a “page”.
Likewise, you can create index templates for custom post types, and you can even make feed templates for custom post types. Right now it requires a little bit of coding in functions.php or the use of a plugin, but it’s totally doable.
The OP used podcasts as an example of what can’t be done with Custom Post Types. I’ll counter that I’m working on a client site with a “Podcast” type, complete with a podcast index and an iTunes-ready RSS feed. All of that independent from the regular blog posts and blog feed. THAT’S the power of Custom Post Types.
I’m not saying that it can’t be done. I’m saying that it’s the wrong way to do it.
Sure, you can make a podcast type, and make a page to display and style them, and even make them into a feed… But why? It’s a lot of work to go through, for virtually no gain. All you get is a separate admin area for it, which you can do yourself much simpler.
Why would you want a separate “post” type for podcasts? That question almost answers itself. Podcasts are completely different from blog posts. They require (not just allow) an audio file to be uploaded. They have completely different tagging requirements. They have completely different content requirements (you can’t/shouldn’t put a photo gallery in a podcast). You probably wouldn’t want them to show up in the main blog feed (though it wouldn’t break anything if you did). You probably would want a separate feed for just the podcasts for iTunes and other software to use.
Why would you want to have an audio-file upload tool always present on the New Post form? Why would you want to train users to always click the Podcast checkbox under categories when creating a podcast, and to not click any of the podcast-related checkboxes when creating a normal blog post? (Okay, that last question was a little off, but I gave better examples in my earlier comment.)
If there is an easier way to set up different post types that are actually posts, please let me know.
Philip, did you have any success with getting your custom post type (podcasts) setup with an iTunes-ready RSS feed with mp3 enclosures? I’m struggling with the same thing. I’ve used podcasting plugins before, but now that I created a custom post type for podcasts, they don’t work on custom post types.
Excuse the typos in my comment above… It happens when you type on the iPad LOL
…nice article, it definitely sheds some light on the whole custom posts and taxonomies buzz.
What would you suggest for a scenario where you might need 40+ custom fields per post, not all containing data for a large number of posts? I’m trying to figure out what the best way to accomplish this might be; although I’m not sure wordpress is the solution. If you have any recommendations I’m all for it…
[…] gone, including all sorts of fancy share buttons and tweet trackers and whatnot. Additionally, in a gross misuse of custom post types, I plan to emphasize links a lot more. I think this will keep my content fresh and, honestly, […]
[…] by the active theme which could cause problems, but I am sure they have their uses. In fact OttoPress has stated just this rcently, indicating that they are often misunderstood. Using custom post types […]
[…] Na enige tijd van drukte heb ik eindelijk weer eens tijd om verder te gaan met de ontwikkeling van DDJ en ik ben begonnen met testen van Custom Post Types. Eerder ben ik hierover redelijk voorzichtig geweest, omdat de locatie van de definities van het Type in functions.php in het template mijns inziens niet juist is. Custom Post Types zijn mijns inziens niet template afhankelijk en daarom horen deze definities daar niet thuis. Nu 1,5 maand na de release van WP 3.0. zie je toch dat dit vernieuwende onderdeel wel goed wordt opgepakt; en dus doen wij dat ook. Otto beschrijft nog eens waarom Custom Types geen Posts of Pages zijn. […]
[…] and ‘Tags’ only).Custom Post Types in WordPressA Refresher on Custom TaxonomiesWordPress 3.0 and Custom Post TypesFirst Impressions of Custom Post TypeCreating Custom Taxonomies in WordPress 3Introducing WordPress […]
Check out this article on Custom post types and RSS http://www.wpbeginner.com/wp-tutorials/how-to-add-custom-post-types-to-your-main-wordpress-rss-feed/
I love WordPress. Really. But the volume of, and confusion levels, around this topic are a clear indication that some changes need to be made somwhere.
Confusion …
Like many, I WANT to use custom posts because end-clients (who are often less CMS savy than you and I) simply DO NOT understand or instantly recognise what a “Post” is, or what they’re supposed to do with it (within the WordPress admin). This alone is a significant reason is why so many developers are using CPTs.
IMO …
WordPress need to either modify or personalise the “Post” term. Or give us the option to (easily) do so. Take Twitter for example – the entire World understands what a tweet is, and if they were asked to “tweet” something, they understand the action (even if they don’t understand the technology or how it works!). Ask them to “post” something ….. (insert the same 20 question every client you configure WordPress for ask you).
WordPress today IS a viable website CMS; it’s not *just* a blogging platform anymore. But while the term “post” is concreted into the admin, it will continue to create confusion for non-tech clients. So (of course) developers will continue to use WordPress features (CPTs) out of context, because frankly it’s embarrassing to have to explain to EVERY SINGLE CLIENT what a “post” is! [In the non-web World, explaining a “post” to a client translates something like this ……. “Umm, I’m using a blogging-specifi platform to house & home your business/company/ website, so I’ll just need to explain some things to you, because ….. well, it’s not really designed to house or home websites – just blogs. So some things won’t make sense”. (insert embarrassment here)
Just having the ability to edit the “Post” labels (admin labels only!) would help in most cases – just to something that’s relevant to the clients industry. If it’s a newspaper website, we could change “Post” to “Stories”. If it’s recipe website, change it to “Recipes”. Just some sort of choice.
WordPress – if you don’t want to be *just* a blogging platform, you need to drop the pure-blogging connotations.
Brand It …
Why not change the default “Post” (label only) aswell? It’s possible to brand this without worry about the Trademark Dilation (good read here: wpgarage.com/news-views/wordpress-in-domains/). How about “Press”? You know, it’s alreay a part of you – word[Press]. Press is a verb already, everyone understands it, and it cannot possibly be any worse than “post”.
BTW …. Is it possible to modify the Admin “post” lable outside the core files?
[…] Otto has an equally good overview of what should and should not be a custom post type and how to use […]
This is also very usable plugin http://wordpress.org/extend/plugins/custom-post-type-archives/
I really enjoyed your article Otto.
This super important! If Custom Post types can be selectively put into the feed via a user interface (Or WordPress Template Tag) Would save you a lot of headache that as you suggest would be a pain.
To use or not to use. This is really baffling me but your logic makes perfect sense. I realize you wrote this over 4 months ago. Do you, Otto, still think it’s early to use custom post types? I do but your opinion matters more to me. I’m starting a new WP project and want to lay the proper foundation.
There’s plenty of good reasons to use Custom Post Types. As long as you’re not using them as, basically, categories. Which a lot of people seem to want to do.
If you want to make something that shows up in the “blog”, then don’t use a custom type for it. Just use a normal Post.
If, on the other hand, you want to make a new type of thing, which maybe has its own area for it and won’t be part of the blog, then a custom type makes sense.
I am building a travel site which will include hotels, attractions, businesses, articles, etc. Based on your response, I think you are advising me to create a custom post type for hotels, attractions, and businesses. Then keep the articles as posts.
Of course using posts and categories (hotels, attractions, etc) are what I’m comfortable with. If you were to building this travel site, is this how you would structure it?
That sorta depends. Will these “hotels, attractions, businesses, articles” be in the “blog”? And by “blog” I mean the main continuing stream of content…
If you want them to be more like Pages than Posts, then custom post types for each of them might be a good fit.
But if you want them to be in your site’s normal stream of content, then they really should be normal Posts.
Since I want the “hotels, attractions, businesses” to be more like Pages than Posts, custom post types seems to be the way to go.
Thanks for taking the time to address my questions. Hopefully, my scenario is helpful to others.
[…] WordPress 3.0 and Custom Post Types by Otto […]
[…] WordPress Custom Post Types Die Bedeutung von Custom Post Types erklärt von Otto on WordPress. […]
[…] help think it really was a wrong decision. Otto also suggest ththat CPTs are not a great idea in his article on CPTs, and I give a lot weight to his opinion on all things WordPress. I wonder out loud why the CP ad's […]
Thanks. Great post and I will not be using custom post types anytime soon as I misunderstood them completely.
seems like a custom post type in name only. custom post types (content type?) one expects to see custom data types, aka varchar, int, float,. moreover attributes: indexed, notnull, default value, blah blah
something offered by a Data Definition Language.
and the few plugins ive seen on custom post types, appear to support your argument that a trad post can accomplish.
check out the plug in and vid: http://wordpress.org/extend/plugins/custom-post-type-ui/
this custom post plugin relies on another plugin to restrict (not define!) the content. http://wordpress.org/extend/plugins/custom-field-template/screenshots/
wordpress is great, but this is where it might unravel.
post should really have been the first content(?) type from the getgo.
Not really following you on that one. It’s not a data type. It’s a post, but not a capital-P “Post”.
Big-P-Post implies that it shows up in the blog. Big-P-Post implies that it obeys the post-permalink structure. These are not the case, in the same way that a Page is a post-type but has its own rules with regard to these sort of things.
I was only pointing out that it’s important to keep in mind the difference. Custom Post Types are *custom* and don’t obey the normal Post rules, just like Pages and Attachments don’t either.
what should be the permalink of custom post type for performance and scaling?
if i have 2 custom post type(tvseries,movies) registered and we make daily 300 article in each post type..wordpress provide default permalink is http://www.domain.com/tvseries/post-name..and /movies/ for movies post type… in wordpress database table wp-posts it save post-type=’tvseries’ in post-type column….but it take time in query…please can you suggest me permalink for scaling purpose if i have thousands of article on my blog..
[…] found this article […]
I am wondering if I can do a particularly “custom” thing with custom post types. I have a table (separate from the wp tables) with rows of clients. Of course (and I think this is key here) that this table has incrementing id’s.
I want to turn this table into a custom post type so that essentially each client becomes a post.
I am wondering if I can tell the custom post type during its initialization, to use this table and somehow map all the fields to .. meta fields I suppose in the custom post type.
Does this make sense?
Once this is done a client cant be granted privileges to edit his/her own “post” and thus the custom fields in the post map to the table fields.
Easy/Hard/Imposs ?
MG
[…] of people. Custom Post Types are’t posts they are post types.Otto wrote a very nice primer on WordPress 3.0 and CPTs which points this out. Nearly a year later, people are still getting it wrong becuase they refuse […]
I view CPTs as just the solution for incorporating categories into pages…Maybe I’m simplifying things.
In reference to: So all of you thinking of a custom “Podcast” post type, you’re in for a disappointment
The soon to be released PowerPress 3.0 will allow you to associate a PowerPress Podcast Channel to a Custom Post Type. It is a very powerful feature for anyone wanting to podcast with custom post types.
[…] Otto states that “There’s no code in there [WordPress core] to do that [e.g., have custom post types appear in the blog/feed], and there’s very likely not going to be [in the WordPress core].” Though I don’t believe WordPress should write the code to make everything happen as that could be a massive undertaking, I do believe that WordPress should incorporate an argument for feed/loop in the register_post_type that could be boolean types if set to true would add the custom post type into the “blog” and feed. The code to incorporate the custom post type into a blog is fairly simple as Justin Tadlock has demonstrated: […]
[…] by the active theme which could cause problems, but I am sure they have their uses. In fact OttoPress has stated just this rcently, indicating that they are often […]