Ok awesome!
The Content Template thing we just did?
Content Templates are like Toolset's version of Oxygen templates. You can design a template and apply it to a single post or an entire post type, and the template will override whatever you place in the posts contents. Or, you can put arbitrary content in a Content Template and insert that Content Template in a post or another template somewhere. That template will be rendered in place. That is what we are doing here to get around the problem where nested shortcodes inside shortcode attributes are not supported by the Oxygen template elements. Toolset's Content Templates support nested shortcodes inside other shortcode attributes.
View 3 I almost can wrap my head around.
The View is configured to show the Photoshoot taxonomy, and the Query Filter filters by term ID, using the shortcode attribute 'terms' to supply that list of term IDs. The shortcode attribute 'terms' is used to provide the list of term IDs in a dynamic way. We could just as easily use a hard-coded list of IDs like this:
[wpv-view name="view-3" terms="1,2,3,1,,3,2,2,1,3,1"]
That would give you a formatted list of term ID 1, term ID 2, and term ID 3, but it would drop any duplicates in the list of IDs. In summary, View 3 just says "give me a list of term IDs in a shortcode attribute called 'terms' and I will produce a formatted, sorted list of terms, without duplicates, for you." We use this because the other two Views produce a list of term IDs that include some duplicate IDs in an unsorted, unformatted way. We need to sort them reasonably and format a list of term names, which is what this View does.
View 1? I get.
Right, this effectively produces a list of related Photograph posts for the current Character post:
Photograph A,Photograph B,Photograph C
But we do not output the Photograph titles, we loop over those and for each Photograph post we insert the results of View 2. So each time View 2 is executed, it is executed in the context of a different Photograph post (why View 2 Query Filter is set to the "current post", which is the current Photograph post in the loop of View 1).
View 2? Witchcraft?!!
View 2 is executed once for each related Photograph post (in the loop of View 1). We do this because we want to get a list of all the terms assigned to each related Photograph post. So if you think about this in the context of View 1, altogether we get something like this nested loop structure:
Photograph A (this is not output anywhere),
-- Term 1 (we output the term ID),
-- Term 2 (we output the term ID),
Photograph B (this is not output anywhere),
-- Term 3 (we output the term ID),
Photograph C (this is not output anywhere),
-- Term 1 (we output the term ID),
-- Term 2 (we output the term ID),
-- Term 3 (we output the term ID),
This is why there can be duplicates in the list of term IDs, why there are some empty commas, and why they are not in any logical sort order. because Photograph A and Photograph C might have the same term assigned. So Views 1 and 2 together produce a list of term IDs, something like:
,1,2,,3,,1,2,3,
Then we feed that list of term IDs into View 3 using a shortcode attribute, and get the final output something like:
Term 1, Term 2, Term 3
