BuddyPress.org

A lot has already been written about URL/URI design, the new WordPress 3.0 enhance support for Custom Posts and Custom Taxonomies so I leave it to the reader to “Google-Upon” it to find out out more about it.

The new WordPress additions bring WordPress a step closer to a real CMS system. A step closer since it will bring many new WordPress applications enabled by these new options but it also makes it apparent that it is really in the core a system for building weblogs.

In CMS systems very roughly spoken we have something called nodes which is a very generic “thing” often tied to a unique URL. So /animal/goat is the node about a goat.

To be honest I’m currently totally LOST with regards to the architecture behind WordPress with these new custom posts and taxonomies enhancements.

I just take a little outtake on what’s now present:

So… the core thing I don’t understand:

– why is there the difference made in all these types of content while they could have just become the same thing.

In the example above you can decide to make a custom taxonomy for movies e.g. if you write 100 posts about startrek1 an 100 posts about startrek 2 you could make a term “movie” and a taxonomy “startrek1” and “startrek2” to label your posts with. When you then type /movie/startrek1 you get all posts about startrek1. Sadly when you type /movie you do not get all posts where you used a taxonomy related to that term.

In the example above you can also decide to make a custom post type “movie” you can then write a custom post of type movie called “startrek 1” and the benefit is that with /movie/startrek1 you have unique url to your startrek1 postingS(!) and with /movie you get all your movie posts. Nice for url hacking.

In the example above you can also decide to make a custom field “movie” to tie to your e.g. blogpostings. So you write a post about startrek1 and then fill you custom field “movie” with “startrek1”. In this case you do not get any url support…

Is there any difference here what you try to achieve from the point of the social graph/urls? Nope.

Reading through the forums you can now e.g. also see questions about comments. When you tie in buddypress you even could say that /movie/startrek1 could involve your forum or group you wanted on that page.

In short: both in the database storage and is the url representation of “objects” and/or “taxonomies” and/or “whatever” I don’t understand which way all of this is heading.

Because in my viewpoint all of this is much simpler when I look at it from the viewpoint of a url (and url hacking). An endpoint of a url is simply a node, whatever on that node is. It “represents” something that could just as well be the “term”.

I think that (custom) fields, (custom) posts, (custom) taxonomies are all of the same. If I would be a facebook person I would say that /movie/startrek1 is an endpoint for everything around that movie. What I would want is say /contact/edward.de.leau is the node for “me”. and /contact/edward.de.leau/addresses shows then all my addresses. While /address/mystreet_63_amsterdam shows my address and /address/mystreet_63_amsterdam/contacts shows all persons living on that address.

I would expect not only url handling doing this (so everything is clickable) but also the database structure underneath e.g.:

Taxonomies versus Custom Post Types example 1

Suppose you have –whatever- relational database (just pick one) and you want to represent the records as custom-post-types of type

. No problem. Just loop through the list of tables and add them as custom post types (register_post_type(‘ ’,$args). The fields of the records then become custom fields which you attach to this custom post type via e.g. a nice meta box on the right hand side.

So /wp_term_relationships/record_1 would display the contents of that first record another one would be /wp_posts/recorcd_23

The problem is now how you are going to represent the relations between the tables (hence relational database). What you want to indicate is e.g. that with 1 record within a table there are 3 related records in another table e.g. wp_term_relationship –> wp_posts. A nice thing is that /wp_term_relationships shows all records of that table.

Laying the relation now is more difficult since you can not lay relations out of the box. You have two choices here. Since we have two relations outgoing out of the custom posts types either via custom fields or via a custom taxonomy.

1. via custom fields you would have to code a custom field that does a query on all custom post types of a certain record and then pick the ones that are related. In the gui you then would have to make them links to the correct custom post type object of the related item.

2. via a custom taxonomy you could create a custom taxonomy per record e.g. wp_term_relationship_record_1 and then “tag” the records that are related with this custom taxonomy.

In terms of work it is the same: you have to go to the specific record and then click either the custom field relations or click the custom taxonomy entries.

The advantage of the taxonomy direction is that it becomes a hyperlink and brings you to a record 1 page where it shows all related records. Unfortunately this is not the custom post record 1 page, so you have to code something for every entry to show to custom post on top (or something likewise).

The advantage of the custom fields is that the items will be more or less more easier to select via your own written selection system. The disadvantage is that they will not be clickable in the gui. So you will have to write that link to the custom post type object yourself AND you will have to add a loop on there yourself showing all related records.

So in this example:

/wp_posts/ : shows all records out of the box IF using custom fields otherwise shows nothing if using taxonomy
/wp_posts/record23 : shows the record23 posting but the related records you will have to add yourself (when using custom fields) or visa versa: shows all related records but not the custom post object of record 23 itself (when using custom taxonomy).

I don’t know yet which is the easiest way.

One in-the-middle-solution could be to also “tag” the initial record with the custom taxonomy of the relation and then define that one to be “sticky” so that it appears on top and when coding against it so you know which one is the “from” and which ones are the “to”.