@timkaye - what exactly do you refer to with “these issues”?
Do you mean the issue that generally one can’t create “object” relations between the distinct domains (user, post and taxonomy)?
What is your use case where you do create such relations that can not already be created with the existing terms to posts “relations” (or what is the necessity for you as a user to connect users to either of the other two domains)?
It will be good to know what for users this actually use (the posts domain relationships are pretty clear, but the other two domains are often unclear and sometimes can already be resolved with existing features, but not always).
I totally agree that of course the implementation should make this works as automatic as possible, which is also why I do not like the current implementation which expects the user to know what relation “type” he is actually about to create connection within and also has no real instance for the relationship itself but only for the connections, and does not make a difference between the domains (user, post and taxonomy) which makes it difficult even for programmers to know how to interact with it (because they ned to know things about the relationship that they should not have to think about and simply should be able to reference them by the relationship name, and not its type, this should be handled by the system behind the scene when “setting up” an actual relationship, within which you then can connect distinct items)
Anyway, I do not want to dig in technicals here lol, I just wonder what your use case is for “cross domain” relationships
I wouldn’t want it to be limited to users and posts. There are other objects such as comments and sites and external tables like invoices.
But I don’t understand how taxonomy fits in there as an object.
I always thought of objects as nouns, with attributes (meta fields), described by adjectives (which are taxonomy terms).
Even if I create a CPT, for instance a plant, the term green can be applied, but there is no relationship between the plant object and the taxonomy or its term. The term can be changed at any time, such as when the plant dies it is brown, or when we translate it to verde.
There already is a term meta table, in case you need to add attributes to terms.
I think if you have additional information, you haven’t defined the object correctly.
Assume an author. Author have not just names and bodies (posts). They may have a lot more data, usually defined in fields and terms. So authors are posts, where you can add that information, and not terms, where you have more trouble to add that information, and even less users, where adding such information is also more tricky (yes all have fields, but only posts have terms, which for an author could be… preferred writing style? genre? provenience? etc)
And to relate them to their books, which again can have more information, you would use a relationship
It’s a repository of faculty publications. Each publication is a post, but there are no custom post types on the site. However, each post is categorized by year, and then is also in at least two of the following custom taxonomies: authors, editors, and publication types. Each of those taxonomies is also replicated in postmeta. So then publications can be listed on category and taxonomy pages, but also each post can call its own metadata.
There’s also a ton of other metadata attached to each publication as well as another custom taxonomy that’s used only on the back-end.
I understood this sentence. The rest was lost on me. I don’t think you need a relationship for this. I did it with movie reviews, that you can find all the movies by year, actor, director, genre, film theme.
Like Tim’s example, each review is a normal post and the only custom field is the year. Custom taxonomies do the rest.
As I said - you often do not need relationships of this kind
Neither die a recipe and ingredients if you really want, you can do all that with posts and fields and terms
But it’s the point of wether you need to add more data to your genre or book or movie than just a name and a “body” or description, where relationships come in handy because you can relate posts (which in turn then can have fields and terms) to each other rather than just connecting posts thru terms
What would you use a relationship for?
I’ve seen you mentioning comments. But that for me is one of those things I don’t see a need for relationships… they belong to one post, always.
The uses cases will be helpful to know, on all examples, I think…
So far, I don’t see anything I would use personally. But clients often come up with other ideas.
I only mentioned them because the original petition comments contained that, and the proof of concept allows for any object_type with comments as one of the predefined ones.
Get CP to recognize “object types” and create standardized names for them (although many already exist): post, user, comment, site, network, table, and so on.
Possibly, you could have a multisite that wanted to highlight various famous comments on one page (hot topics or something), where you would need the relationship to include the site and post to get the comment.
This brings to mind whether there is any distinction between static relationship (entered by user) and dynamic relationships (calculated by a plugin), because as things change on both sides of the relationship it could get to be performance intensive with possibilities of recursion in the many-to-many type.