[wp-hackers] Custom Post Types and pending incompatibilities

Edward de Leau e at leau.net
Tue Jul 13 20:28:47 UTC 2010


come in handy. (/

2) probably the concept of "domain specific" could pinpoint the exact scope
of a CPT standard or from an architect level ties with
http://en.wikipedia.org/wiki/OASIS_(organization) BPEL standards

3) As well as some architectural theory on what kind of taxonomies
http://en.wikipedia.org/wiki/Taxonomy WordPress supports and which not

4) And how the complete solution is related to url hacking.

e.g. "movie":

a) I could make it a taxonomy: /movie/ would return nothing /movie/startrek
would return all movies named startrek
b) I could make it a CPT /movie/ returns all posts of that type,
/movie/startrek shows postings on startrek
c) I could make it a custom field attached to a post /movie returns nothing

its still a bit unclear without some architectural guidelines that would be
handy to add in the mix of standardization.

I think the thing is that every software project touching this area is in
the same boat. In drupal once can make these nodes, In wikipedia the
solutions is to display a list of pages which could mean... Webservices
people dream since the 2000 about a world wide discoverable set of services,
object oriented programming should theoretically have led to lots of
reusable objects "event" that every single person would use, but they all
uhm... face some problems.

Personally.... I think the wikipedia solution is the most practical ("not
beautiful but easy to implement"), but I dont know if that is possible with
CPT and the code behind it. see:
specific for tags.

I don't think there is an essential difference between
taxonomies/terms/term-relationship and cpt in terms of what they are. I
really would like some theoretical background on that  to determine when to
use movie as a taxonomy term and when as a CPT and when as a custom field.

So maybe the above is one side of the difficulty "to taxonomize it" and the
other part is the TYPE of relationships it support, which maybe even more
difficult to standardize.

n Tue, Jul 13, 2010 at 7:46 PM, Simon Blackbourn <piemanek at gmail.com> wrote:

> I strongly believe that being open with post type & custom fields rather
> than namespacing them is the way to go in the long term. Closing things off
> and saying "this is my post type - hands off everyone else!" is
> antithetical
> to the whole ethos of the WordPress project.
> But rather than setting up yet more working groups and discussion forum,
> etc, which seems to me over-bureaucratic and unlikely to result in success,
> what if plugin authors simply put the information visibly on their plugin
> page, then over time 'the market' decides and those plugins that don't
> follow the standard set by others will become less popular.
> Clearly stating the post type and custom fields on your plugin page would
> encourage other developers to use the same type/fields in their plugin (or
> not to use the same if they want to avoid conflict). They could then say
> "compatible with the Blah Events plugin".
> So rather than having to dig through code to find these things out, it's
> right there out in the open on the plugin page for all to see.
> It might take a while to get the ball rolling, but once it gains critical
> mass then take-up should grow. Just a few high profile plugin authors doing
> this and writing about it on their blogs should kickstart things.
> Which then raises the question as to whether there should be some
> consistent
> place/format on the wp.org plugin pages for displaying this information?
> (either in the FAQ or Other Notes?)
> --
> Simon
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers

Edward de Leau

More information about the wp-hackers mailing list