[wp-hackers] Custom Post Types and pending incompatibilities

[The WordPress Web Warlock]

En/na Michael Pretty ha escrit:
> Sorry if some of this has already been said. I've been out for a few 
> days and am playing catch-up. I first want to say that I somewhat 
> disagree with the idea of namespacing post types. Ideally, content 
> shouldn't be tied to the plugin that manages it. If my site uses 
> events that are either created by a plugin or a theme and I want to 
> switch to a new plugin that manages that content, I should be able to 
> without having to recreate all of those events. There was a wp-hackers 
> thread a little bit ago about standardizing geo-data so it could be 
> shared amongst plugins. I think the fields that shape into something 
> like an event or product should also be somewhat standardized.
If I don't remember it wrong, it wasn't exactly about "sharing amongst 
plugins", but also "using API of external apps", too. It makes a lot of 
sense IMHO for geodata, calendars, & other things that have some "de 
facto" standards — like microformats.
But I don't see it as clear with other type of content —say, books. It'd 
be hard enough to get a common definition of what a book is, indeed... 
(You'll see why I'm saying this.)

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).

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.

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...)

My approach (and I suppose someone else will have done something like 
that) is using "term groups"; not the ones in the wp_terms table, but 
"glossaries" (groups of semantically-related terms) which can be 
children or parent of any number of other term groups/glossaries 
("cities" are a subgroup of "places", as "planets" are). So I have the 
potential of grouping that taxonomies have (to make, say, tag clouds for 
some glossary cats).

I'm using a custom wp_termmeta table for this (and many other things), 
but this can be done with regular wp_options. The glossaries are stored 
taxonomies-like (a global array). Hook to edit tag form, add the field. 
Easily done, too. Want the nice permalinks? Filter the category link, 
and move it to a Page: category.php can double as Page template with 
little effort (yes, the Page ID is another term meta... which can be a 
single option row, too). Using the conditional tags, read the term_id 
either from queryvar or a postmeta field: voilà!, prettiest permalinks 
ever. Meta boxes? Not that hard, neither.

Want to find all your copies of ShakeSpeare's Sonnets? Just do it with 
category__in, category__and, &c. You'll be adding just an instance of 
the term-taxonomy table. No matter how many additional "glossaries" 
you're asking for, it's just the regular query/get_posts, and reading an 
array: scales nicely, uses the API.

All of this could be done even with good ol' 2.9.x version (and surely 
earlier, but I'm relatively new at this). So, nothing really new here, 
save maybe the implementation.

And well, maybe you don't need to know where in your library is your 
copy of Shakespeare's Sonnets in Penguin edition: by this I mean that, 
yes, in some cases, using post types and taxonomies can be the best way. 
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. 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.

Best,

Xavier