Let’s use this topic as a place to list potential use cases for the Object-Relationships project.
This will serve as a way to identify the actual needs/problems that have to be solved.
And as a result, we will gain a better insight to design the solution. Extend the existing Query APIs or create a custom one? What kind of UI? …
Discussion about design should take place on separate and specific topics, so we stay organised.
User favorite posts
Allow creating a relationship between users and their favorite products, songs, recipes, …
This is a one to many relationship between user:post
Related posts
Not always all related posts fall under the same taxonomy. In this case, a many to many relationship is required between posts and posts.
User groups
A social-network like platform could need User Groups. Something like Facebook groups.
To solve this need, a one to many relationship is required between a CPT “Group” and Users.
That is, a one to many between post:users.
Ingredients for recipes
For example, a site could have listed ingredients (CPT), with nutritional facts and so on.
And then each recipe (another CPT) could call those ingredients in the form of a one to many post:post relationship.
This would be a many:many relationship. The quantity and unit (and probably the order i.e. whether this is the first, second, or last ingredient in the recipe) could be stored as metadata for the relationship itself.
This one seems like a good example for demonstrating the full capabilities of post-to-post relationships. As another example, many recipes have multiple “sections” where the cake has one list of ingredients and the sauce has another list of ingredients. This would also need to be indicated somehow.
Done.
I would tag all of these threads with #object-relationships also.
I’d use this for conferences. Then you’d have relationships between events and venues, speakers, attendees, sessions, accommodation, etc, and you’d also need metadata about the venue such as meals, and about the attendees such as dietary requirements.
Sessions might be a category or taxonomy rather than a post, with individual presentations within a session being posts.
A series of posts could be linked together, maybe?
Isn’t this simply a user taxonomy?
As far as I know, there isn’t a trivial WP way to add a Taxonomy for Users. If you look at the docs for register_taxonomy(), it accepts $object_type.
$object_type is the name of the object type for the taxonomy object. Object-types can be built-in Post Type or any Custom Post Type that may be registered. Default is None.
Anyway, the fun thing about relationships is that they are not attached to a single object. You can create the relationship between whatever object types.
Yes, but if you can leverage existing code and tables, why not do it?
If you add a column for table name to the taxonomy table, wouldn’t it be fairly easy to have taxonomies for any object? And that starts to sound a lot like what the relationship table is.
Thanks, exactly this is the purpose of this topic: To propose use cases to find out the best solution to the relationships problem. I think this particular conversation (“can this be achieved with an extra column to the current taxonomy system”) should be done in a separate topic to make a decision.
The Taxonomy system is like a set of boxes that you can create to throw objects into them, be it in a hierarchical way or not.
That can be used to create “groups” of objects, but it’s not a real relationships system, because not all relationships consist of groups of things.
For example:
But discussing that implementation idea (“add an extra column to the current taxonomy system to convert it into a relationships system”) is not the scope of this topic. Could you please open a new topic with a proposal of the implementation you have in mind? So others can leave feedback just there and keep stuff organised.
Closed decisions are better than open ideas, and the more ideas get converted into closed decisions, the closer we’ll get to a result. Keeping the “open idea to closed decision process” in independent topics helps pointing to them when someone else comes with the same idea in a few months.
Display a certain banner in a list of mixed post types
Let’s say I want to display a certain banner in a chosen list of posts (mixed post types, not only blog posts). For example, to promote something in my site, which wants to be promoted only in certain places.
I would need to create a relationship to relate said banner with that list of posts.
Let’s say my site contains Movies, Games and Books CPTs. And I want to promote a special event only in specific movies, games and books (because maybe I wanna target people who are consuming Harry Potter stuff, be it movies, books or games…).
A simple taxonomy would not work, since it’s restricted to one type (the $object_type).
That’s not true. The register_taxonomy function takes an array of types. Taxonomies can be “shared” across types.
I’m not sure where this “add an extra column” came from. Tim’s conference example seems to fit perfectly into the existing base plugin implementation for object relationships.
I’d probably use a taxonomy for this. Part of this exercise should be to make sure we understand how to use the existing features well (like taxonomies) and where they fall short.
The most use cases I have seen so far are:
These examples are taken from thousands of sites I have seen built during support of a tool that does amongst other things exactly that (implement relationship), they are not my personal opinion, but based on what WordPress users do.
The main point of using a relationship versus taxonomies or fields (most relationships can be done with existing tools like fields and terms) is that you want additional information that you can’t add to a meta field or a term, such as a location can have an address and also a name, capacity, age, safety etc etc. The location is holding events, and those events again can have additional data, and folks attend events or perform at events, and again they will have data that is stored in form of either terms or fields for those “objects”
In the numerous years helping, supporting and building such sites for clients/users, the most often used relationship is between post types.
User <> Posts is the second most requested and can usually be replaced by mimicking a user in a post type.
The third, and almost never requested group of relationships is taxonomy <> users or taxonomy <> taxonomy or users <> users or taxonomy <> posts.
This might be just because almost no tool offering relationships actually has relationships for Terms and Users, most focus on post types, but also because there are just not so many reasons to actually have relationships (which do not already exist, like tagging a post is also a relationship) of this kind.
The Users <> posts comes up then and when for folks who want to allow sort of “co-authorship” of posts, but again, mostly that can be solved with other means. Relating terms to terms might be useful, but the question is also how to query that data, how could it even be used, I have yet to come across the use case for this (not ever requested actually) type of relationship.
user <> terms (as a relationship) would likely just be to allow taxonomies for users, like you can have meta fields for users (or terms).
Note that it is often overkill to use relationships. Very often, a term or field is much better solution and much faster to do as well (and faster to retrieve and work with later).
The real use case of relationships comes really in when you need that additional room for editing and data, which you don’t have in fields or terms.
In support, we used to use a rule of thumb that first you check if a term is enough, then you check if you might be able to achieve the same with a field or group of fields, and only if that does not lead to the desired results, use relationships.
And again here, first check if a simple (1:1) does the trick, and from there work your way up to M:M, which is the least desired type of relationship (not because it is bad, but because one wants to keep things simple, and relating content gets extremely messy under circumstances, where users quite often end up in a limbo of “this relates to that but that relates to this which relates to another that and that other that relates to more this”. At the end you don’t know anymore what relates to what and all you have is a spidernet of connected items (which might look cool but gets awful to query, maintain and keep organised and make a sense of))
Public librariessites. Publications’ catalogues where there are relationships between users, objects, meta and taxonomies to build the network of info that correlates media (books or whatever this publications are or even a mix), authors, topics, publishers, designers, translators, timelines and the like.
Basically try to look at “how to build a library system in WP” - there is only a very outdated plugin that needs custom code to work as intended to manage the relationships (that is because the effort of writing a solution to this is not “one-man-show”, to be really implemented in the correct way many people have to work together - like it’s happening now).
For library system I mean that CMS the librarians worldwide use to connect their books on shelves with something that makes it easy to manage them. At present very few little libraries handle this with WP. Think of small clubs owning “some small amount of books” that are a closed pool.
If this thing really is developed you can use it to launch a real library system with many libraries being related. At present in Italy national libraries use a custom software that is a nightmare everytime it needs updating because it puts entire portions of the system offline.
I know that because I had an insider look (took a course for a job and worked at a library for a while… During one of the software updates. And I mean the national public library network that not only connects to all Italian libraries, but shares data with the foreign librarian networks too!).
Basically it’s the most complex use case I can think of.
If we need to develop that, better do it in a way it is able to take on the more complex jobs IMHO, so that it can handle the easy ones without hiccups.
I have typically worked around these issues by having a post (or user) match a taxonomy and/or metadata. Then it’s possible to go from taxonomy to post to metadata. But obviously this depends on ensuring that everything is kept in sync. A purpose-built object relationships database table should provide that automatically.