Thank you for the great WP plugin! It helps a lot and is rather intuitive. However, I have a problem that I don’t find a straightforward way to solve, so I’m asking for help here.
We have this catalogue where we have books and authors (accessible at https://italy-elt-archive.unimi.it). We’ve managed to create collections (among which books and authors) and filters for their relevant metadata.
I’d like to be able to filter books by author’s metadata, e.g. profession (type of author) and author’s country of origin. Is there a way to do this without duplicating the corresponding taxonomies from the authors collection to the books collection?
I’m glad that you are enjoying the plugin. It is nice to see some project from Italy coming up
To be direct, there is no way to filter other relationship metadata than the title. This is because it would mean, in practice, a double search (looking for data in a collection by looking into data in another collection). It could also bring some performance issues.
That said, we’ve faced this before… And in a very particular project we figured out a way of duplicating the relationship metadata via a sort of internal metadata. It is not an easy hack and not something we recommend. But I can show you the code where this was implemented and give you some tips if you are willing to create something similar. However, that would require considerable knowledge of PHP for you to adapt to your scenario.
As an extra note, while you cannot filter, you can at least view some of the relationship metadata via the “Displayed relationship metadata option” in the Relationship metadata settings form.
Thank you for the quick response. I suspected that this is currently not supported, but wanted to check for recommended solutions. I would appreciate any code references you might share. I do have experience with PHP, even if it is not my preferred choice.
I’ve also considered the possibility to duplicate the metadata in the other collection. Since we are working with an bibliography that is being provided by a limited number of maintainers, this is doable. It is, however, clearly undesirable.
We are still weighting our options. I also hope that inspecting the code you might share with me, could help me evaluate a third unlikely, but theoretically possible option: investigating that a feasible solution could be done through adding DB views that simulate the duplication of data.
We do have filtering as a hard requirement, but thanks for the viewing tip. I will discuss it with the internal clients in our team.
Ok, so here we go… I’m sorry about it being poorly documented, but this was a very specific solution made for one among many institutions that we have worked on. I’m not the one who implemented it, but I kinda get the idea…
First, you might need an overview of WordPress/Tainacan development background. We have some documentation here:
But to summarize a few concepts that you must know:
Tainacan Collections are Custom Post Types, so their items are basically posts of a post type like tnc_col_123_items, where 123 is the ID of the collection. They are thus stored in the wp_posts and only contain fields that posts would contain (title, creation date, excerpt, author, etc);
Each new Tainacan Metadata register new Post Meta, which is the WordPress way of adding custom fields to Custom Post Types. Their values are all stored in the wp_postmeta table;
You can think of Tainacan Metadata types as different layers to interprete data inside the wp_postmeta. Because for WordPress, everything is a long varchar. For each metadata type, we have validation layers to see that metadata value as a short, long text, date, number, taxonomy terms or… IDs, which is the case of the Relationship type;
Tainacan Filters are basically WP_Query builders, who are aware of the binded metadata type to decide if a query should be numeric, textual, date, etc;
There is a “special”, “hidden” type of metadata type in Tainacan that we call “control” metadata type. This metadata is not meant to be edited by the user, but to “interpret” some information existed in the Item or in the Collection as if they were in fact data registered via post meta. Three examples:
“Has thumbnail” is a control metadata because the item thumbnail itself is an information stored as attachments and this data should only inform if there is or not such value associated to the item. Because it exists, we can have a filter for that;
“Document type” is a control metadata because this information is stored directly in the item, not as a postmeta. We can then have a filter that displays if the item is an image, audio, pdf, etc;
“Collection” is a control metadata because the relationship between the Collection and the Item entity is also stored directly in the item (and per definition, as it defined the item post type);
SO, the idea is to create a new option for Relationship Metadata to decide whether its filters should be “expanded”. Including an internal “control” metadata type in the Tainacan API, which stores the data of each related metadata so that facets of the filters that include them can be generated.
The source code that I shared makes use of a series of filters and actions that are made available by the Tainacan plugin to change its default behavior:
tainacan-api-response-metadatum-meta: filter that allows you to change the value of the api’s response when the metadata is queried;
tainacan-insert-tainacan-metadatum: action that is executed whenever the value of a metadata is changed;
tainacan-delete-tainacan-metadatum: action that is executed whenever the value of a metadata is removed;
tainacan-insert-Item_Metadata_Entity: action that is executed when linking a metadata value to the item;
tainacan-fetch-all-metadatum-values: filter that allows you to change the return of a query by all metadata values;
tainacan-api-prepare-items-args: filter that allows you to change the arguments passed to all queries to the Tainacan item API;
With this set of tools, the logic is created to store the relationship metadata information in the internal “control” metadata, hidden from the user, in the related collection. This makes it possible to create filters that search for this information.
