Hi Beda,
Re 1: Not a problem, I wasn't sure if they were one in the same issue initially, or related at least, which is why it was mentioned initially in the same thread.
I will keep my eyes out for the Erratum as you have mentioned.
Re 2: I was beginning to wonder if this was in fact a bug that I just happened to be taking advantage of.
Passing the value of the view_template shouldn't be an issue at all: I should be able to simply get the value of the Content Template post-meta field for that post/page (I see the post-meta slug is "_views_template") and pass it into the 'wpv-post-body' shortcode's 'view_template' argument. Notice the similarity between these - _views_template (post meta) and view_template (shortcode attr) - you can understand how I had assumed the output we got was intentional with Views and not a Bug. Regardless, this functionality is easily recreated using a custom shortcode as I'll explain for anyone else following along:
The shortcode [wpv-post-field name='_views_template'] got me the ID defined in the Content Template meta field, however [wpv-post-body] requires the title of the content template, not the ID. Adding [wpv-post-title id="[wpv-post-field name=_views_template]"] does indeed get me the title of the content template assigned to each page/post in the view. Adding that within [wpv-post-body view_template=''] does seem to work, however leaves some leftover closing tags - too many opening and closing shortcodes characters and args inside of eachother of course.
SO I've written a single shortcode that gets the value of the "_views_template" post-meta field, if set, for the current post in the loop. It then gets the title for a post with the same ID and returns it - this successfully gets us the title of the assigned Content Template.
(See code block down below for my [content-template] shortcode script, which can be added to functions.php, anyone feel free to comment if I'm doing something wrong/stupid.)
Adding this new shortcode, [content-template], to the view worked great and showed the Title of the content template that was set for each page in the view.
I also added the shortcode to Toolset Settings > Front-end Content > Third-party shortcode arguments, of course.
However when placed in the 'wpv-post-body' shortcode's "view_template" argument, it still didn't seem to want to work (ie. [wpv-post-body view_template='[content-template]']). I discovered that this was simply due to the names of my Content Templates, which contained what I assumed was a standard dash. The dash character being outputted by my shortcode was in fact the long one, however the 'wpv-post-body' shortcode is expecting the short one, an 'endash'.
I was able to correct the endash issue after discovering there were encoded html characters being used in the titles for Content Templates. Using "html_entity_decode" and a "str_replace('–', '-', ....." resulted finally in the [wpv-post-body view_template='[content-template]'] shortcode combination working great and reproducing the positive results from the "Bug" that we've been exploiting apparently.
Below is the final code for my [content-template] shortcode that resulted from this. When used within [wpv-post-body view_template=''], it will show the page/post body formatted within the content template assigned to that page/post.
/**********************************************************************
* SHORTCODE TO GET TITLE OF A POST WITH AN ID MATCHING THE SOURCE FIELD
*******************************************************************/
add_shortcode( 'content-template', 'dtf_get_views_template');
function dtf_get_views_template(){
// Get the ID of the current post in the loop.
$current_post_id = get_the_ID();
//Safely get the ID from the Array stored in the _views_template post meta field for the current ID
if (get_post_meta( $current_post_id, '_views_template', true )){
$content_template_id = get_post_meta( $current_post_id, '_views_template', true );
};
// If returned post meta value was not an empty, let's try to get the title for a matching post by ID, otherwise return nothing.
if ($content_template_id !== ''){
$content_template_title = get_the_title($content_template_id);
$content_template_title = html_entity_decode($content_template_title);
$content_template_title = str_replace('–', '-', $content_template_title);
return $content_template_title;
} else {
return;
}
}
You can have a look at either of the /test01/ and /test02/ deployments for this in action, logins are still active for you. To be honest, I'm not sure if I'm handling the character encoding issue properly (didn't try with any other special characters in a content template title), but for our purposes this will work fine and we'll avoid usage of such characters in any future implementations.
With regards to our impressions of Toolset Support, we honestly don't have any current plans of walking away from Toolset - we've now spent quite some time working with it and have created some very elegant solutions that would have been impossible without the use of Types, Views and Layouts - however the lack of acknowledgement and understanding of the problem from the support person who was previously handling our thread was becoming quite concerning. We had never had this much trouble explaining a simple issue in the past with Toolset Support, so after multiple explanations and a full video explaining all the display and editing issues didn't work, we became quite concerned with the dependencies we may have created.
However your answers have pointed out, very simply and elegantly, the issues we were having and why we were having them, as well as the direction we needed to move forward in - we couldn't ask for anything more. Your assistance is greatly appreciated Beda and I'm glad we were able to come to a resolution so quickly after coming into contact with you - thanks again for the timely detailed responses. Your assistance has certainly improved our impressions of Toolset Support and I want to thank you for the detailed and thorough answers related to the hangups we were experiencing as well as your willingness to provide ongoing support on this hurdle. Unless you have any comments, recommendations or suggestions regarding the above script/solution, this thread can likely be put to rest now.
As you have recommended, I will keep an eye open for the Erratum relating to the Content Template post-meta GUI and post a new thread if necessary once applied. Until then I will work on updating our custom toolset themes and any deployments that require the new shortcode in order to prepare them for the Views/Layouts updates.
Again, feel free to have a look at test01 or test02 (I corrected the changed layouts and templates to ensure the solution worked in the updated version as well) to see how the Single Page Layout and "Child Pages" View works to dynamically display pages with different Content Templates for each if you have any interest.
Thanks again for your ongoing support,
Cameron
