Timeline for Grandchild nodes (of a nested taxonomy term) on node page
Current License: CC BY-SA 4.0
9 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 21, 2019 at 4:37 | comment | added | prkos |
If you have both solutions working individually, then they should work together with the "Views Contextual Filters OR" module. Did you enable "Contextual filters OR" in your views? Did you test the two options individually? Did you combine them correctly? You can test individual Contextual filters if you have more than two by using the "all": in Preview enter all/ID or ID/all to test the second one or the first one.
|
|
| Jan 20, 2019 at 23:35 | comment | added | Benjamin | Hi prkos, in your first comment you mentioned "combine the 2 solutions... isn't so easy". I managed it in deed to make a block work the one or the other way round. But as you predicted, when trying to combine the the 2 individually working contextual filters with "Views Contextual Filters OR" (a module that helped me a lot), I get no result result at all. This makes me extremly curious: Why does it not work? | |
| Sep 23, 2018 at 17:16 | comment | added | prkos | If you have reused the same Term reference field in two content types that can actually make things easier in Views, depending on what you're trying to achieve. You can unrequire any Relationship, the first solution will still work. You may get it to work if you play with it, try to combine it. I don't have your structure replicated so I can't test, it's hard to imagine what the outcome might be. You can add another Title field, make it use the last Relationship while keeping the old Title field, that might list all the nodes, but there may be repetition, and they will show in the same row... | |
| Sep 23, 2018 at 16:08 | comment | added | Benjamin | I did not manage it, but I think that it was not very clever give the field in the nested term the same name as the reference field in the nodes of the other content type. Nevertheless, if it is in anyway complicated to combine the 2 solutions easily (I imagine because of need of usage of "Require this relationship"), I will use it that way. You made me very happy with the upper solution in anyway - the other thing would only be the cherry on the cake. (The only solution I found before was displaying the field ID in the path) | |
| Sep 23, 2018 at 14:54 | comment | added | prkos |
It takes some learning and trying things out but it doesn't take that long once you realize relationships just connect different tables in the database. You already have B terms available through step 4, now you add relationship Content using field_c to introduce those nodes into View. To test showing them edit the Title Field and change it to use that Relationship. You should now see only the nodes referencing B term that is the grandparent to the current node. With that working, you need to combine the 2 solutions, but that isn't so easy. Can you use two blocks one below the other?
|
|
| Sep 23, 2018 at 13:01 | comment | added | Benjamin | Although you answered my question 100%, I have an additional question to this topic, on how to continue after step 4 if I would like to show the nodes of another content type that references directly field_b/vocabulary B. But I will try to figure that out by myself first. | |
| Sep 23, 2018 at 12:40 | comment | added | Benjamin | Wow. I do not know if I would have figured that out ever. Thank you so much. | |
| Sep 23, 2018 at 12:39 | vote | accept | Benjamin | ||
| Sep 22, 2018 at 19:51 | history | answered | prkos | CC BY-SA 4.0 |