[wp-hackers] Custom Post Types and pending incompatibilities
The WordPress Web Warlock
wordpress at web-warlocks.net
Mon Jul 12 20:28:07 UTC 2010
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
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
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.
More information about the wp-hackers