[wp-hackers] Custom Post Types and pending incompatibilities

[Mike Schinkel]

On Jul 12, 2010, at 4:24 PM, Peter Westwood wrote:
> Personally I would recommend against people "reserving" post types - you are creating mines in which your data will be stored which won't make it easy for other plugins or themes to interact with without breaking arbitrary rules:

I'm not 100% clear what you mean when you say "reserving" post types.  Do you mean creating a namespaced post type?

> I would rather recommend that if you are creating a plugin which allows people to create "Events" you use a post type called "event" and you write your code in such a way that if some special piece of post_meta you need is missing you have a default for it which you use.
> 
> That way when I decide to switch from your Events plugin to this new kid on the block I can still manage and use all those events I already created using the new plugin.

On Jul 12, 2010, at 4:31 PM, Andrew Nacin wrote:
> I don't want my products/books/events to be wiped on an uninstall hook, as I
> worked hard to cultivate that data.

Agreed in theory.  

I fear in practice we are likely to find people will get to "keep" their event posts but none of the meta will line up.  So in essence these "kept" posts will be orphans in limbo until someone edits each and every one. (Sure most anyone on this list can run SQL queries to clean it up, but our collective SQL skills are <1% of the user base.)

We'll never "solve" this problem completely and I'm not suggesting we can.  But we might handle a useful percentage if we have a well-known place where people who are interested in "Event" post type can collaborate on ensuring compatibilities for the naming that most everyone needs.  Not proposing any "requirements" here, just a forum for discussion and a place to write down the current state of agreement. (That's why I suggested me updating the codex in that regard but am waiting for some feedback before I steam ahead.)

On Jul 12, 2010, at 4:24 PM, Peter Westwood wrote:
> Basically a plugin using Custom Post Types should follow Postel's Law: 
> 
> "be conservative in what you do, be liberal in what you accept from others"

Big fan of Postel's Law. But in the context  there are just some basic fundamentals that must to be coordinated to ensure interoperability. For example in Postel's world: HTTP status codes, standard HTTP Headers (vs. "x-" headers), standard content types (vs. "x-" content types), schemes (i.e. "http", "https", "ftp", etc.) and so on.  A well-known place to discuss and docuement "fundamentals" for post types, minimally a core defined set of custom field names and behaviors, would be helpful IMO.


On Jul 12, 2010, at 4:28 PM, The WordPress Web Warlock wrote:
> And even then, some standards can have many different implementations, so it's hard to stick just to one. How do we do ratings? Unless you store score AND scale, the "five-star-scale" and the "0 to 10 scale" can be pretty incompatible. (If you add score and scale, though, you can even compare ratings in different scales; just store the rating in a common scale, say 0 to 1, and convert it for display).

That argument can be made for practically every standard or potential standard in human history. Rather than give into the urge to believe it can't be done, I ask can we think in terms of the subsets for which it can be done.

The original HTML was successful (IMO) not because it was perfect but because it provided significant usability while putting a stake in the ground around which everyone could operate. From there improvements were made.  So (IMO again) address the common subset most reasonable people can agree on is a much better starting point than just chaos.  Or let one proactive person propose a standard and if it is good enough to gain adoption, work from there.

One thing is a problem, and that's over-architecture.  There can be multiple "standards" to address different use-cases.

> So, I'd leave it as "if there's a standard of any kind, use it, dangit!"
>> (...) With custom post types and taxonomies, we have really opened up the types of web-apps for which WordPress can be the backbone.
> I disagree with that, but not entirely. There are lots of things that have been mentioned as "now we can" with post types that, from my experience, are best done with regular categories and posts. Books are quite an example, as real estate and movies, at least until some major enhancements are done to taxonomies/WP_Query.

> 

> I'll put you an example with books. Suppose we're to add ShakeSpeare's Sonnets: we'd have the "book" post type, the "genre" taxonomy, some "publisher" and maybe "collection" taxonomies.
> 
> AFAIK, it's a real mess to query althogether for genre=poetry AND author=william-shakespeare AND post_type=book. Last time I worked on it, the query var for taxonomies was just a rewrite for taxonomy and term. And adding another taxonomy query (say, "publisher" or "collection") meant adding another instance of the taxonomies table. So I went for another, more scalable and API-using approach instead.

That's off-topic, but not using CPTs because of lack of built-in query functionality is throwing the baby out with the bathwater.  I've had no real problems with this.  Yes, I've had to use hooks but I plan to propose the code be added to WP core when I get time to package it all up.

> Also, taxonomies are not hierarchical (and by this I mean "taxonomies cannot be children/parent of other taxonomies", I'm not talking about taxonomy *terms*). Categories (or terms for a hierarchical taxonomy) are. You can list both your books, magazines, comic books, fanzines and AD&D boxes all together, or separately, as you need to. Hey, I worked for a roleplaying publisher that issued a box with the books, a T-shirt and a character miniature... And a post can belong to *many* "content_type" categories, but can be of only one post_type. So, SuperSoaps INC. could be listed as being a book, and a bundle, and a T-shirt, and having goodies, and miniature. (Well, the game was actually called "SuperHeroes INC.", but it got the soap nickname... guess why :) ). I'm not sure if SuperSoap is a "book", but I do have it in my (book) library, not my DVD library. (BTW, in my DVD library I've some digitized comic-books...)

That's because you are thinking about CPTs too granularly (IMO.)  What you have is not a Book, it's a Product (or "Saleable Item.") But it's not a Post and keeping it as a post will hoist all those same limitations on you.

> My approach is...

Your explanation has gotten too complicated for me to follow. Without seeing what you've done it's really hard to tell if it's overkill or the best approach. (I'm not soliciting you to send me your stuff, but making a rhetorical statement.)  Anyway, point is you may have something that is simply too custom for your needs to be appropriate for shared post type definition.  Or if not, then having many heads design it would be preferable to having one.

> But I'm pretty sure the estate folks will like to know how many two-story buildings with garden and two bathrooms are availabe in the SpringField area in the price range of US$ whatever.

This can totally be done with CPTs and CTs.  I'm doing similar on three projects and it is working swimmingly.

> Or, also, do something like the Codex: is it better to add the post_types of description, return value, usage, examples, version since, see also, related, &c, and query them... or just add some categories (of the 'wp_content_type' "glossary") and do a rewind_posts? If you add the evil option page to allow the user to specify which category is to be used as what ("this is description, this is return value..."), you won't have any of the compatibility among post_type "description", "usage" issues. Problem solved: if it doesn't work, it's user's fault :D, not plug-in's nor core's.
> 
> Anyway, though, as I said (didn't I explicit that already? my fault), it's true that custom post types do add LOTS of potential. But I'm thinking more about, say, Flash game wrappers that add highscores and game data as postmeta, private messaging for users, or using the "link" post type and being able to use your "regular" terms for links too. But adding all that API just to automatically add some custom fields and nothing (or little) more is IMHO a bad idea, at least until you can use term__in, term__and, term__not_in &c with the same nice scalability that using only "regular" terms have. So, yes, IMHO there are some doors that've been opened with all the new 3.0 stuff (half-opened earlier); just not those of library management, but for RPGs & a whole bunch of other interesting things.

CPTs are not as "comfortable" as the older ways yet because we haven't figured out all the related design patterns. 
CPTs are new and the supporting infrastructure for them has not been as fleshed out as the older systems. A good PHP/MySQL dev can get around those issues, and ultimately contribute their solutions to core or as plugins. That doesn't make the older systems better in all cases, just means that time will improve CPTs as time improved what came before it.

One final point, CPTs are not-panacea, but they are immensely useful. To repeat Michael "With custom post types and taxonomies, we have really opened up the types of web-apps for which WordPress can be the backbone."

-Mike