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

WordPress Trac wp-trac at lists.automattic.com
Thu Aug 5 05:20:03 UTC 2010


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

  * status:  closed => reopened
  * resolution:  wontfix =>


Comment:

 I guess I forgot to check "cc" because I didn't get any emails about
 discussion ticket.  Even though it was closed I'm reopening it so I can
 respond.

 Replying to [comment:1 scribu]:
 > You don't really need an extra table, as demonstrated by my plugin:
 >
 > [http://wordpress.org/extend/plugins/posts-to-posts/ Posts 2 Posts]

 Sure you can do it that way.  But it's not a great, general purpose
 solution for reasons discussed on wp-hackers and below.

 Replying to [comment:2 nacin]:
 > Wondering if we can create a viable API for this increasingly used case
 by internally leveraging postmeta.

 As Denis said, using postmeta would require either doing lookups on a 768
 byte key field or storing the relation twice in two different meta fields
 and thus increasing likelyhood that one of them will get updated by a
 plugin but not the other and "corrupting" user data.

 Replying to [comment:3 Denis-de-Bernardy]:
 > The above table could be a first step to merging posts and taxonomies,
 however.

 By "above table" I assume you mean the one proposed?  If yes, +1. :)

 Replying to [comment:4 scribu]:
 > There's no point in creating the table if we don't provide UI and APIs
 to go with it. So the feature request should actually be "Enable many-to-
 many relationships between posts".

 I completely agree.  Sorry I didn't mention that explicitly; at the time
 it seemed obviously implied but now seems like not mentioning it was an
 oversight on my part.

 Replying to [comment:5 Otto42]:
 > We already have many-to-many relationships between posts. You can relate
 a bunch of posts to other posts by simply giving them all the same term in
 a taxonomy.
 >
 > I say put this on hold while the discussion happens on wp-hackers. Maybe
 we can come up with a better solution.

 We don't already have many-to-many relationships in a manner that
 reasonable people agree on the implementation.  Taxonomy requires either
 to much overhead to do lookups and/or to many joins and it requires
 maintaining many records in a consistent state across many tables. Too
 many places where data can get changed a corrupt the data at the user
 level (and I'm referring to both post_title/name and post_name/slug.)

 Replying to [comment:6 jane]:
 > This seems to be straightforward plugin territory to me. Fairly niche
 use, etc. I would support whatever is needed in terms of hooks to make it
 easy, but I can't see this as a real candidate for addition to core, given
 that the bulk of users would probably never need this. If I'm wrong,
 someone creating a plugin for it and showing wide adoption stats would
 convince me to reconsider.

 I think you may be unaware how widespread the need for post-to-post
 relationships really are. Yes for the blogging use-case most people are
 not going to use it (though I believe many of them would if the benefits
 were explained to them).

 But when using WordPress as a CMS I would be hard pressed to envision a
 site that would not explicitly need post-to-post relationships. Let me
 give you an example. You blog a lot about WordCamps. You could add a
 WordCamp post type where you have city, dates, venue, photo of venue, etc
 as custom fields. In addition, you could add a post type of "Featured
 Presenters" to your blog which would include their photo, their bio, their
 session topic(s), their company, their twitter name, etc. These features
 presenters could be keynoters or others that are "notable" in a Wikipedia
 kind of way. Then you could relate all your featured presenters to each
 WordCamp and have a generic post relationships widget that displays
 upcoming WordCamps and their Featured Presenters. The widget would be
 plugin territory but the table that stores that data and the "Related
 Featured Presenters" metabox in the admin UI (aka "Related %post_types%")
 that allows you to relate the two would be generic and triggered by a
 "supports" arg of the register_post_type() function and they should IMO be
 in core.

 Also your mention of offering hooks implies you may not understand the
 scenario.  The hooks to support this are already in WordPress; I've
 already implemented a plugin to relate posts. What we need are not hooks
 but instead a table to store the data. My plugin could add its own table
 but I loathe writing plugins that add tables to WordPress because that
 means WordPress doesn't have what we need for common use-cases. And if I
 add a table it's almost certain nobody else will write functionality for
 my table but if it was added to core there is 100% certainty that many
 other people will (which is one reason I'm advocating for it.)

 Of course Otto42 and scribu claim that the taxonomy system is sufficient
 but I and at least prettyboymp disagree. However I had to explain the use-
 case to Ott42 and (thus it's clear to me) he hasn't actually implemented
 any sites that use taxonomy for this use-case and so his advocacy for
 taxonomy hasn't been tested by the rigors of real-world experience.
 prettyboymp has deployed a large site and came to the conclusion that
 using taxonomy for related posts was not workable and I'm coming to the
 same conclusion on a large plugin for CMS use-cases I'm trying to
 finalize. scribu just yesterday changed his plugin to use taxonomy from
 postmeta so it seems he hasn't tested it "in the field" either.

 Does anyone else thinks post-to-post relationships are fairly niche?
 Surely not scribu, he wrote a plugin to address the use-case.  Nacin
 points out that it is an "increasingly used case." Denis seems to imply
 that he believes it would be a viable use case (true?)

 Unless a reasonable number disagree the point of this debate is not
 whether it is "fairly niche" (it's not) but instead:

 1.) Should a table to relate posts as well as basic supporting UI
 functionality be added to core? (I think so, prettyboymp thinks it's
 useful but that we should wait to include in core, and others may agree or
 disagree with including in core) and

 2.) If it will be in core how should it be implemented? (Otto42 and scribu
 this taxonomy is fine, prettyboymp and I disagree.)

 ''Postscript:'' Yes I'll be disappointed but otherwise I'll be fine to
 learn that the majority decide not to include the proposed table or
 anything similar in core. However I will be upset if the decision is made
 based on false assumptions.

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


More information about the wp-trac mailing list