[wp-trac] [WordPress Trac] #14513: Time for a wp_post_relationships table?

[WordPress Trac]

#14513: Time for a wp_post_relationships table?
-----------------------------+----------------------------------------------
 Reporter:  mikeschinkel     |        Owner:                
     Type:  feature request  |       Status:  reopened      
 Priority:  normal           |    Milestone:  Future Release
Component:  Post Types       |      Version:  3.0.1         
 Severity:  normal           |   Resolution:                
 Keywords:                   |  
-----------------------------+----------------------------------------------

Comment(by mikeschinkel):

 Replying to [comment:14 scribu]:
 > You mention that using a taxonomy would be hard because you have to keep
 post slugs syncronized. I have tried that approach in the past and,
 indeed, data got corrupted pretty fast.
 >
 > That's why I use the post ID instead. Since the ID never changes,
 keeping things consistent is a lot easier. You just have to delete the
 term when the post is deleted.
 >
 > Take a look at the most recent version of my plugin to see what I mean:
 >
 > http://plugins.trac.wordpress.org/browser/posts-to-
 posts/trunk/core.php?rev=271772
 >

 That's what I'm already doing (using a post ID) as seen in
 [http://gist.github.com/507345 the code I posted yesterday to gist] for
 Lox. The problem I have been running into is ensuring that adding of a
 term doesn't fail because of a pre-existing slug that has been added for a
 post tag. Sure I can just add a "-2" or whatever, but the client is very
 anal (as most clients are, and just like me :) and they want the taxonomy
 slugs to match (if we are using taxonomy then we should be using the
 taxonomy system URLs, etc.)  It's basically a rock and a hard place. So
 while I agree using taxonomy is useful in lieu of having a better method,
 it is non-optimal.

 Using taxonomy for this requires telling your client "''No, sorry, we just
 can't do that''" and I'd rather have a system where I can always say
 "Y''es, of course we can do that (it might cost more, but we can do it if
 it is important to you.)''"  BTW, I think this is the same reason
 prettyboymp became disenchanted with using the taxonomy system to relate
 posts.

 Replying to [comment:15 jane]:
 > @Mike. We don't put everything in core. It's meant to be the must-have
 stuff, and extensible for specific use cases. A use case that is growing
 is not the same as one that is applicable to all. Get a good plugin out
 there that makes the table you want, see how many people adopt it. If it's
 an overwhelming number that would make the case. Adding tables that most
 of the 20 million+ users probably don't need doesn't make sense. When it
 gets to a point that it looks like a majority of them really do need that,
 as shown by plugin stats, that would be a good time to consider it.

 What Denis-de-Bernardy said. :)

 Seriously, using that same argument we would not have gotten custom post
 types because most of the 20 million+ users don't (realize they) need
 them. (Precedent set. :) Future, post relationships are infrastructure not
 a feature.  Features are plugin territory, infrastructure is not.
 Actually, this is simply rounding out missing functionality from the
 evolution of post types, not as a feature in-and-of itself.  Honestly I
 think maybe you have an automat'''''T'''''ic (pun intended?) Pavlovian
 response to any new features: '''First''' say "''No, make it a plugin''"
 ''Then'' actually understand the proposal. (I say that in good natured
 jest, please take it that way. :-)

 By analogy, consider [http://wordpress.org/extend/ideas/topic/threaded-
 comments the idea for threaded comments]. Mark Jaquith's
 [http://wordpress.org/extend/ideas/topic/threaded-comments#post-165
 suggestion of 3 years ago] was for people to roll their and he points out
 that the field "`comment_parent`" was there for them to be able to do so.
 Had `comment_parent` not been there, his answer would have needed to be
 "''Add your own table''" which I think most of us agree is not something
 to encourage, right? This is much the same, we need a robust place to
 store post-to-post relationships. Adding a table may not be the right
 solution, but a solution is needed even though not all 20 million people
 will benefit.

 Another analogy would be if I asked for the state to build a road between
 Macon and Columbus and you petitioned against it on the grounds that few
 people not traveling by car between the two cities. Clearly that's a
 chicken & egg problem; people don't travel by car between the two as
 frequently as say between Macon and Savannah or Macon and Valdosta because
 there simply isn't an easy way to get there. If there were a road there
 you can be certain more people would travel between the two. That doesn't
 mean it makes sense to build the road just that the justification for not
 doing so would have been faulty, same as in this case.

 OTOH if WordPress had a built-in system to allow a plugin dev to "require"
 other plugins and then automatically and transparently have them
 downloaded and activated maybe I'd be able to agree with you but right
 now: "''What Denis said''."

 Now, can we get on to discussing an optimal implementation for post
 relationship and also when (and even if) it makes sense to add to core? :)

 Denis, another idea besides a specific table could be to simply add a
 `parent_id` to `wp_term_taxonomy` and overload it to allow for post
 relationships?  I don't know if doing so will have unintended consequences
 with normal usage of the taxonomy system as the `nav_menu_item` post type
 did for plugin queries and such, but it might be manageable?

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/14513#comment:18>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software