Post to post relationships and the limitations of WordPress


WordPress Post to Post relationships

After recording the WPCandy Podcast last night with Ryan, we had a bit of an after the show show open discussion. I brought up something I remembered hearing a while back on a 5by5 podcast where I believe a guest of Jeffrey Zeldman’s said that WordPress couldn’t handle a website like IMDB, the popular Internet Movie Database.

I wrote down the comment to remember for later, because I had a feeling it was a bit presumptuous. Justin Tadlock, a very well respected WordPress developer, happened to be around the after the show show and was the perfect person to ask about my IMDB WordPress challenge.

He said (in essence) that not only could WordPress handle it, but that it could handle it better than IMDB’s current system (which I don’t know anything about). I was excited about Justin’s answer, because I remembered he has significant experience brainstorming movie-database systems. He often used movie databases as examples for tutorials to help describe custom taxonomies and custom post types, released in WordPress 2.8 and 3.0 respectively.

Justin referenced a trac ticket and his own post on linking terms to posts as references to further learning on current limitations of WordPress Core which need to be worked around to accomplish an IMDB-esque site. The gist of the problem is the ability to relate posts to posts, or one table directly to another. Currently, the custom post type and taxonomy system of WordPress relies on using taxonomies to relate two post types together. As taxonomy terms go from hundreds to thousands to tens of thousands, the scalability of the system comes into serious question.

The trac ticket on the subject is a very intriguing one where some of the brightest WordPress minds debate the need of post to post relationships. Mike Schinkel brings up some excellent use cases to support the need for implementing a major code overhaul to core.  Other users understand the appeal, but maintain the primary goal is to uphold WordPress philosophy to design for the majority, and say that the current system of custom post types and taxonomies handle the majority of use cases.

There are plugins available to help achieve the desired functionality for now, which operate outside of WordPress Core. Scribu’s Posts 2 Posts plugin is probably the most notable of the bunch. And it’s arguable that such a use case is perfect plugin territory. But as Mike Schinkel notes, “each of them is operating as an island and not using a community process to speak of.”

This issue isn’t brand new, but it is getting more interesting. The ticket itself has moved all over the place, and probably isn’t the best place for the discussion to begin with, but in general has spent several months designated for future consideration. Just last week, Schinkel updated the ticket with an opportunity for very serious developers to start contributing to a community solution “Object Relationships Plugin.”

In a perfect world, the plugin would provide an avenue for implementation into future versions of WordPress. As noted throughout the ticket, many consider post to post relationships the last gap for WordPress-the-cms vs WordPress-the-blogging-platform. Dougal Campbell elegantly calls the perhaps-inevitable feature “a natural evolution of WordPress.” He even specifically calls out IMDB as an example of the type of site where such a feature would be needed.

Dougal closed his two cents with a fine summary in my opinion, where he says, “It might be version 3.4 or later before it goes in, but I think that something like this is inevitable. We need to start thinking about implementation. One day we’ll be looking back at some awesome theme, or plugin, or custom site built on this, and saying, ‘Remember when…?'”

So what say you? Is this prime plugin territory, or an inevitable step that must be taken in core to take WordPress to the next level?

Editor’s note: No information taken from WordPress Trac tickets is meant to represent plans for WordPress that are set in stone in any way. This topic is just a discussion, and in no way intended to assume the direction WordPress may take as a platform.

29 thoughts on “Post to post relationships and the limitations of WordPress

  1. What you’re describing here is perfectly possible with the Pods plugin. I believe the upcoming 2.0 release of their plugin is using CPT to their full possibility making it even more like the desired situation described above.

  2. People use custom post types a lot these days. Providing a mechanism to define relationships among different things is essential.

    Heck (shameless plug) we even created our own plugin for situations like this. We handle only one way relationships for the time being but we have some plans for the future. Anyway just bringing this up as an example.

    My vote goes for having this kind of functionality in the core.

    Now though, i am thinking about the ExpressionEngine situation where a custom field with (limited) functionality of this kind is provided and the king (imho) of relationships management (Playa 4, ) is still provided as a 3rd-party plugin.

  3. I would encourage anyone who has a strong interest in this to contact Mike Schinkel regarding his project. The aim is to create a framework which could become a basis for other plugins to build upon, with hopes that one day it could be integrated into core.

    • Ditto to that.

      Right now, most of the core devs think the post-to-post relationship idea is an edge use case that wouldn’t fit the majority of sites. But actually building out the system and making it available might (I think will) prove otherwise. Once it’s built, rolling things into core if desired will be much easier.

  4. @Brian: Thanks for writing about this.
    @Dougal: Thanks for the support:

    And both @Brian and @Gerasimos we would love to have your participation, and anyone else who is interested in this topic.

    It would be especially useful for @Gerasimos and people who are also “rolling their own” to contribute. If we get a lot of people to participate then we can gain critical mass. Yes it would be great to get into core, but the WordPress team has expressed their lack of interest in doing anything in the near term so since so many of us need it now, let’s do it now, get traction, and then it can hopefully be rolled into core.

    Interested? Just contact me via my page (linked to my name here) and I’ll get you a login to the discussion. It’s not an open discussion yet given the discussion and version control systems but we’ll grant access to anyone interested in participating and the plugin will be released on the plugin repository, for free of course.

    • No problem, Mike. Thanks for commenting here. Hopefully a lot of smart developers will join you. I may mention it to a couple that I think would enjoy, but it’s above my pay grade : ) I learned a lot just writing this post.

    • Hi Mike,

      Thank you for your invitation. I will try to find some time to contribute to this as it’s probably one of the most needed features in my projects.

      What i do not understand is why a feature like this wouldn’t fit in the core. I mean personally i haven’t worked in a project in the last 2 years that i didn’t need relationships. They are like, everywhere.

      The idea of making a plugin first looks good to me and if it goes well, i think it can still go in the core in an “add_theme_support” style. You don’t need it? No problem, it is there though.

      As a professional using 2 CMSs in my day to day work (one of them is WordPress) all i have to say is this:
      Provide post2post relationships and custom field groups per CPT and watch the WordPress user base grow even faster.

      Just my $0,02

      • Not looking for any contributions other than your opinions of what we are doing. So not asking for any more time than you are already spending commenting here. 🙂

        I do believe such a feature should be in core, but since they won’t add it any time soon, let’s build it outside of core first. Why wait for them when we can do ourselves?

        > custom field groups per CPT?

        Funny you should mention that… If you want our WordPress user base to grow faster, email me so we can hook you up with this initiative to help make that happen sooner.

  5. I would agree with Luc that Pods allows for this sort of things though it might not be the easy solution for the every day user. I also agree that this might not be the functionality the every day WordPress user needs to know about and wants to have. The core Plugin idea lost some appeal over the past year but such features might be a good idea to bring core Plugin back by allowing “advanced” users to tune their WP install. Great article!

  6. Until it’s needed for some other core feature, I don’t see it making it into core. Core devs don’t have a habit of adding support for bits that they’re not actually using in the core itself. A posts2posts linkage would be one of these sort of things.

    However, when it eventually *is* needed for a core feature, then having an existing implementation, such as a plugin, with strong support behind it will make it an ideal candidate for getting straight up integrated.

    • Exactly, as always Otto! There have been a few plugins already that went into Core, right? I just can’t think of them right now. Hope the development behind such plugin grows!

  7. Scribu’s Post 2 Posts work flawlessly and he has been very good about pushing out updates.

    With a plugin like that available to us, I don’t think there is really any reason for this to be in core (at this time, as mentioned above).

    His plugin owns on so many levels 🙂

  8. while working on a fairly basic corporate site recently for a law firm I immediately came upon the current constraints of WordPress when it comes to relationships between different data entities.
    posts2posts didn’t quite cut it in terms of the reasonably straightforward relationships we were looking at setting up. Pods seemed a step too far. We needed a more elegant solution that hit the sweeetspot between the 2. We didn’t find it. Hopefully this new Object relationships plugin might become this solution. I think this will inevitably end up in core as it’s just too important and intrinsic to modern web publishing. Having said that, it’s easy to fuck it up and make it overly complex. I think the core teams suggestion to let the plugin community innovate around this first is a wise one.

  9. yes , I think there’s a need for this kind of functionality, if you want to have a parent CPT with its attributes and a child CPT with its own attributes. for example, a plugin which would allow to insert multiple image slideshows on a site which could each have different transition effects settings, and different images of course.

    • Hi @Jared and @Markgt – Yes Scribu’s Post 2 Posts work flawlessly and he has been very good about pushing out updates, and Yes the Custom Post Type Relationships a great way to link posts, pages, and most importantly, custom post types. And there is also ZigConnect and Post Type Linking:

      Unfortunately, all of them are different, none are built with more than one developer and none of them can be assume to just exist. We are trying to create a base standard plugin and theme developers can build on, not just some functionality that a site developer can use. Our Object Relationships plugin will also be delivered as an include file that any plugin or theme developer can include and will be able to be versioned if used in that manner.

      Since the WordPress team doesn’t want to standardize it by adding it, we need another mechanism for creating defacto-standard extensions, and that’s basically what this is about. Object Relationships are frankly just the tip of that iceberg.

  10. good to see this open again. to think a rewrite is niche and not needed is somewhat shortsighted… I’ve run into this a lot of very large db sites where it just doesn’t seem feasible to build in WP w/ the high traffic, relations and ultimately the on-site search volume. I’ve resorted to custom codeignitor dev for those. I think it being implemented would help with future use cases of WP and it’ll be more common in the future for more projects. #innovate 🙂

    I have another similar project on the brink and they want to use WP… I’m worried w/ the couple million products and relations/taxonomies/cpt’s etc that need to be built and searchable quickly w/o killing servers is something wp can still handle.

    I’d love for an Open Relationships plugin…

  11. I agree that custom field groups and post relationships are really needed for WP to fully mature. Even sites as simple as a gallery site could benefit from post relationships in ways that go beyond tags and categories. For example, an artist I am building a site for shows work at different exhibits. With better relationships, she could blog about the exhibit and relate that to each of her works (a cpt). As I understand, those works could then indicate what exhibits they have been displayed at. Awesome!

  12. Thanks for writing this post, bringing more light to this issue. For those of us using WordPress to do some heavy lifting, an object relationship plugin would be a big bonus. For me it matters not if it’s in core or not. It just matters that it works!

    I think we should also note that just a post relationship is not enough. We need something that can link buddypress groups to custom post types. Another issue is being able to link users to custom post types or other objects in ways that are not direct ownership.

    scribu’s post to post plugin should be a model on which we can build this more inclusive object relationship plugin. I’m game.

    • “think we should also note that just a post relationship is not enough. We need something that can link…”

      Definitely agree.

      “scribu’s post to post plugin should be a model on which we can build this more inclusive object relationship plugin”

      That’s the design we are starting from.

      Send me an email via the link on my name; we’d like to get your perspective on requirements to ensure any use-case you envision can be addressed.

  13. i tried drupal for creating a movie database. it was too tiring and complicated. then searched wordpress framework. After doing a few search on plugins, i feel the Admin UI interface for CPT along with posts-to-posts will do the work for me. What do you people feel?

    I want to make a database where i have mainly two posts type: 1. Movies, 2. People.
    1. For movies, i will have custom fields like release year, director, actor, genre etc. Fields like year of release and genre will simply use a TAG in its field. But fields like director and actor will use “People type of posts” in its field.
    2. For People, i will have custome fields of movies, wikipedia link (field: url), gallery URL etc. The field “movies” will be linked to “movies type of posts”

    For identifying the kind of “technician” , i will use simple tags like actor, director, producer, singer etc. Now, one person may be an actor, and at the same time may be a singer. Since i will use tags, i can use multiple tags!

    I think this will be sufficient for buiding my database. But since i plan for a long term quality database, i feel that i will wait till a standard functionality comes out. Then i can start my work.

    I really appreciate the work you people are carrying out. Thank you all. This post and all the discussions were highly helpful for me.

  14. You can just use postmeta and json_encode and decode to create your relationships…then use a custom wp_query with post__in to get your data. I can go into detail, but honestly its not that hard.

  15. Yes. Base-standard functionality in the core, but hidden by default for the 95% of users who don’t need it. It can be activated as an addition under settings.

    Glad you’re taking the initiative for functionality that wordpress desperately needs to stay on top the awesome ladder.

  16. Hi, it would be great to read an update on how wordpress and relations are doing in 2013? What is the best practice today when creating sites with related content? Thanks!

Comments are closed.