Skip Navigation

[Closed] [wpv-post-body] does not render post content using template on WPViews 1.5.1

This is the technical support forum for Toolset - a suite of plugins for developing WordPress sites without writing PHP.

Everyone can read this forum, but only Toolset clients can post in it. Toolset support works 6 days per week, 19 hours per day.

Our next available supporter will start replying to tickets in about 1.63 hours from now. Thank you for your understanding.

This topic contains 8 replies, has 3 voices.

Last updated by Juan 6 years, 5 months ago.

Assigned support staff: Juan.

Author
Posts
#195993

With the introduction of the output="normal|raw|inherit" attribute for the [wpv-post-body view_template="None"] in version 1.5.1 you defaulted the view_template => 'None' in function wpv_shortcode_wpv_post_body breaking once again default behavior.

The same issue was reported by me and was resolved in support thread https://toolset.com/forums/topic/wpv-post-body-does-not-render-post-content-using-template-on-wpviews-1-3-0-1/

The problem with explicitly setting the views_template is that you can not have a loop that displays posts with different content templates (assigned on each post). May I ask what happens if we rename the content template… do we have to check all of our views to see if we hardcoded it somewhere?

Such a change has a great impact on existing installations. For us, this only meant 5 client sites broken upon automatic update and chasing though code to see what is going on.

Thank you for looking into this

#196089

After spending some time testing, the problem manifests only on a WordPress Archive View where the the [wpv-post-body] shortcode outputs only the content of the post ignoring completely the view template assigned to the post.

On normal views it seems to run ok.

#196097

On a side note (perhaps a relevant bug):

If I change the usage on a specific content template to be used for a Post Archive, then when rendering the Archive on the front end the first item skips the content template while the rest of the items use it as expected.

#196141

Dear Ioannis

You are right, I'm seeing inconsistent behaviour. Let me forward this issue to the developers and Ill get back to you.

Regards,
Caridad

#196636

Juan
Supporter

Timezone: Europe/Madrid (GMT+02:00)

Hi Ioannis

This is Juan, lead Views developer.

Although it may seem so, we have not defaulted the "view_template" attribute in the wpv-post-body shortcode to "None". We added it on a piece of code that is not really used, but in any case the "view_template" attribute is not listed as optional in our documentation, so omiting it might have unexpected results (as you seem to be experiencing, more on that later) and also can change its results on the future. Do not worry too much, I have a solution for your case.

First thing to notice: you are on a quite edge case. Let me sumarize the output for the wpv-post-body shortcode when used without a view_template attribute.

- On a normal View, it will return the actual content of the post.If the post has a Content Template assigned to it, then it will be applied, rendering its content instead. You said it's working like that ("On normal views it seems to run ok").
- On a WordPress Archive, it will never return the Content Template assigned to each single post. Instead of this, it will try to return the content of the Content Template used for that archive page.

So let's focus on archives and let's start with the second issue-bug you are reporting. If you set both a WordPress Archive and a Content Template to be used on an archive page, and then use a wpv-post-body shortcode inside the Archive loop, but without a view_template attribute, you expect the archive to display all the posts with the Content Template asigned to the archive, right? You can do it, but you need to set the view_template attribute to that particular Content Template. If you do not explicitly set the view_template attribute, and because WordPress Archives have a greater priority than Content Templates assigned to archive pages, you really should not expect that Template to be applied at all. In any case, as you reported, the Content Template is being used on every post but the first one. I'll take a look and see what I can do. But as you want all the posts to use the same Template, using the view_template attribute should be the easier way.

Now, on the first issue. On WordPress Archives it has been never possible to use the Content Template assigned to each post to display it using a wpv-post-body shortcode. On those archive pages, we first check if the wpv-post-body has a view_template attribute. In your case, it did not. Then, we check if we have a Template assigned to be used in the archive page (in your first report it looked like this was not the case either, because you did not want to apply the same Template to all the posts). Then, if we are on an archive, that is all and we return the actual post content. There is never a chance to return the Content Template assigned to each invidivual post, and it has been on code untouched since January 2013. So I do not really understand how this can have broken 5 client sites on the latests update.

Now, if you really want to use a different Content Template per each post inside an archive page, you can use the filter "wpv_filter_force_template":
https://toolset.com/documentation/user-guides/views-filters/wpv_filter_force_template/
With it, you can override whatever Content Template being applied to whatever post in whatever kind of scenario. In your case, you would want to return the Content Template assigned to the post (and stored in the post metadata as a a custom field) if the kind is "archive-{post-type}"

As a final note: yes, if you rename a Content Template and you have used its name inside a wpv-post-body shortcode in the view_template attribute, you really need to update that shortcodes. This may seem a problem of design, but it's not really. We needed a balance on usability, and using the Template name as identifier lets us easily recognize which one is being applied on a wpv-post-body shortcode.Using the Template ID would have made it strong on Template title changes, but it would have made it more difficult to know which Template was being used everywhere.

Let me know if that helps you solve your issues and if I can do anything else for you.

Regards,
Juan de Paco

#198552

Hi Juan,

Thank you for your thorough response to this issue.

To clear things up, this issue is somewhat similar to the previous issue that I reported that involved normal views but not the same since this one affects archive views.

Also, the wpv-post-body shortcode was defaulted to view_template="None" from 1.5 to 1.5.1 as follows:

// Version 1.5
function wpv_shortcode_wpv_post_body($atts){
    $post_id_atts = new WPV_wpcf_switch_post_from_attr_id($atts);

    extract(
        shortcode_atts( array(), $atts )
    ); 
...

// Version 1.5.1
function wpv_shortcode_wpv_post_body($atts){
    $post_id_atts = new WPV_wpcf_switch_post_from_attr_id($atts);

    extract(
        shortcode_atts( array(
			'view_template' => 'None',
			'output' => 'normal'
        ), $atts )
    ); 
...

Usually, whenever we use wp-views on client sites, we prefer using normal views and not archive views so that we have finer control on the query.

On several occasions though, we needed to use archive views instead and wanted that dynamic rendering based on content templates applied. We assumed that this would work just like the normal views.(which makes kind of sense) and seemed ok pre 1.5.1. Having different results with normal views and archive views seems odd.

As far as content template renaming is concerned, perhaps using the content template slug could work instead of the title or id.

The issue with the content template skipping the first post in archive views still remains.

Thank you again for looking into this.

Regards,
Ioannis Kappas

#198608

Juan
Supporter

Timezone: Europe/Madrid (GMT+02:00)

Hi Ioannis

Just wanted to ping you: I'm looking into this. Hope to have something to tell you soon.

Thanks for your patience,
Juan de Paco

#200870

Juan
Supporter

Timezone: Europe/Madrid (GMT+02:00)

Hi Ioannis

First of all, I want to apologize for the long delay. We are in the middle of a dev cycle and this issue needed a long look and thought to get this right.

Basically, I see two issues here. Let me start with the last one.

1.When using both a WordPress Archive and a Content Template applied to a post type archive, the first element on the archive page does not get the Content Template applied.

This happens when your wpv-post-body shortcode has no view_template attribute, and I could reproduce this. But this is not the appropriate way of getting what you expect. If you want to use a WordPress Archive and show each post there using the same Content Template, you *must* use the view_template attribute to set this Content Template to be used.

So in this case, the solution to that issue is simple: just set the view_template attribute and avoid skipping it.

2. The shortcode wpv-post-body without the view_template attribute is having mixed results.

In addition to the problems in archives, it sometimes displays (or displayed) the Content Template assigned to the single post, but there are other scenarios where it would be definitely not the expected behavior. For example,think of a wpv-post-body shortcode without any attribute used inside a Content Template that is applied to a given single post. One would expect that this is equivalent to using the view_template="None" attribute and should return just the post body,without falling into an infinite loop.

We can not rely on a missing view_template attribute to use the same Content Template (like in the problem 1) or to use different Content Templates (like in the problem 2). We need to normalize and extend.

As I said before, the view_template attribute has never been officially supported to be left out, and until now we had just workarounds and a mixed results on different places. We are addressing it and making this mandatory and default to "None".

Just a side note. Although we are setting the view_template to be "None" in the first parameter shortcode_atts() function, we are not really enforcing or defaulting this to "None" right now. As the official WordPress docuentation states, the original values passed to the shortcode via attributes are not overriden here:
https://codex.wordpress.org/Function_Reference/shortcode_atts
We then operate always over the original array of attributes passed to the shortcode, so if you do not supply a value for the view_template attribute, we are still not enforcing the "None" value. But we are going to.

--------------------------------------------

Now, you have a quite good and valid point here: there is no supported and documented way of displaying a list of posts with different Content Templates applied to them. It seems a valid request to be able to use the Content Template assigned to each post when listing those posts, right? We need to combine it with our valid (too) idea of normalizing it (so you do not need to rely on a hack with mixed results that is not really supported) and make the view_template attribute mandatory. We really want to make it default to "None". So, how do we solve it?

I've been working on a solution that should be fair for us and should make your installations robust and reliable because you will be able to use a supported and documented method. The main idea is that we will still make the view_template attribute mandatory and default to "None", but you will be able to use view_template"$template" to use the actual Content Template assigned to the current post.

This would work on normal Views, on WordPress Archives and also inside other Content Templates. In fact, this should be the canonical way of showing the post body using the assigned Content Template, allowing you to make it dependent of each post.

Is this something you would like to see implemented? It would require that you update the listings where you want to use different Templates, but this solution would be final and update-resistant.

----------------------------------------------

BYW, you can use the Template name (that is,the slug) in the view_template attribute, not just the title.

Let me know what you think and I can send you a patched version of the last released Views that would pack this new view_template="$template" handling.

Regards,
Juan de Paco

#201134

Juan
Supporter

Timezone: Europe/Madrid (GMT+02:00)

Hi Ioannis

Just a little update. We have gone back to the drawing board and we are discussing the best way to implement this. As far as I understand, the main problems are:

1. The wpv-post-body shortcode without attributes behaves differently depending whether it is used on a normal View (it renders the Template assigned to the current post, if any, or the actual post content) or a WordPress Archve (it renders the Templateassigned to that archive loop but in the first post, if any, or the actual post content). This should be normalized
2. There is no reliable way to make the wpv-post-body shortcode render the particular Template assigned to the current post. The method used on normal Views (omitting the view_template attribute) does not work on WordPress Archives.

We are currently discussing whether we should include an option view_template="$parent" or whether it's better that the wpv-post-body shortcode without attributes always tries to display the particular Template assigned to the current post. This is not so trivial, since it would overwrite the Template assigned to archive loops on WordPress Archives, but in case you want to use that Template to all your archive loop inside a WordPress Archive, you can always set the view_template attribute to use it.

So it's still an open issue. Sorry for the inconvenience this might be causing you, and we would love to hear your feedback on what you would expect on each case. We understand that by now there is some inconsistency and unreliable behavior happening here and we would like to get this right.

Regards,
Juan de Paco

The topic ‘[Closed]

With the introduction of the output="normal|raw|inherit" attribute for the in version 1.5.1 you defaulted the view_template => 'None' in function wpv_shortcode_wpv_post_body breaking once again default behavior.

The same issue was reported by me and was resolved in support thread https://toolset.com/forums/topic/wpv-post-body-does-not-render-post-content-using-template-on-wpviews-1-3-0-1/

The problem with explicitly setting the views_template is that you can not have a loop that displays posts with different content templates (assigned on each post). May I ask what happens if we rename the content template… do we have to check all of our views to see if we hardcoded it somewhere?

Such a change has a great impact on existing installations. For us, this only meant 5 client sites broken upon automatic update and chasing though code to see what is going on.

Thank you for looking into this

does not render post content using template on WPViews 1.5.1’ is closed to new replies.