Recently did an upgrade and see two rather majority backwards compatibility.
1. It appears as if a Content Template was applied by default to some but not all custom post types when that association did not previously exist. I can easily remove the CPT's default association with the content template (which is blank). But it applied the template to all existing posts in that CPT and now I'm having to manually open and change them to NONE. Is there a way to bulk-reverse this?
2. I have custom fields entered in hundreds of posts that were working fine with the "output="raw"" added to the field and also with double-quotes. With the upgrade that field is now not functioning. If I change the quotation marks from double to single quotes and if remove the output="raw" the field functions as expected and as it did before ugrade. I've already spend dozens of hours attempting to locate the errant fields and fix them.
This is bit annoying. I think some reparations are due!
1. It's not clear from your description why templates were assigned to posts where they previously were not, but you can run a script to remove the assignment in bulk.
If you create a code snippet at Toolset > Settings> Custom Code, instead of activating the snippet you can simply run it once, which will bulk delete the content template assignment for post types that you specify in an array at the top.
2. We had some issues a few versions ago where backwards compatibility for the raw=true attribute (equivalent to output="raw") was broken, but not reports of anything similar with output="raw" itself.
If you can give me concrete examples of a a particular field type (with specific values, if required) and shortcodes that worked but not longer do I can investigate further.
1. I only had about 15 of those custom posts so I just manually opened them and changed the template to None. Not sure why it happened but I have bigger fish to fry so let's move on to the next one.
I do however want to confirm that if I apply a document template to all posts in a particular post type, I can then remove the association by unchecking the box and then selectively select the NONE option to switch to other content. Is that right?
2. I'll get back with you in a couple of days with details about what works and what doesn't with regard to how the shortcode is written (with single quotes, double quotes, and with or without the output-"raw". I'm manually repairing the code. Unfortunately I have about about a dozen spots on six different sites I'm having to modify the code on. BUT I WANT TO POINT OUT A NEW ISSUE.
3. I discovered that my output of RESULTS on queries that had pagination weren't working after these recent updates (I think most of this has to do with how Divi was recoded ... ). I didn't notice it at first because the results populate on the initial page rendering. But when you go to any other page using pagination the results disappear. This does not have to do with the filtering or the Ajax refresh. After a few hours of investigating it turns out that the lack of display is caused by using the CONTENT TEMPLATE in the view. When I take the code in the content template and paste it into the Loop Output editor the results display as they should. This appears to be possibly be a bug in the content template coding? Have you had anyone else point out issues with the content templates correctly generating results within a view?
Yikes! This is a bigger problem than I thought. My content templates are not functioning everywhere on my sites. It's causing huge voids everywhere I've used a content template in both posts and in views. Any clue what is causing this? Here is an example of the code in a content template not functioning. The content template contains the Results of the filtered loop. Either click the Next the link to see more paginated results or use the filters to see the content disappear. hidden link
I will send more examples in a subsequent message.
A quick word about assigning/un-assigning content templates to post types, before moving on.
For individual posts the assigned content template is stored as post meta with a key "_views_template", which means that different posts of the same type may or may not be using the same template.
When you create or edit a post type and opt to assign it to existing posts, a script runs that sets the _view_template meta value for all of the posts, and if you add a new post the value of the assigned template will be automatically set.
If you re-assign another content template to the post type and opt to assign to existing posts, the script will run again and update the _views_template set for each post.
There isn't an equivalent script to bulk un-assign templates, which is why I suggested the code above.
Hopefully that clarifies how the template assignment works.
Now, regarding the issue of the templates not showing after pagination etc., I think it would help if I could look at the backend of your site at the specific example you shared above.
So let me set up a private reply for that.
In the meantime, there is one issue where it rings a bell that it works if shortcodes are added directly to the Loop Editor and not in a linked template, and I'm going to have to do a little digging to try and identify it.
Mentioning here that the one ticket I found with a similar issue is that if you create a View with pagination where the posts themselves are designed with the Divi page builder, they will only display properly if the content is added directly between the wpv-loop tags rather than in a linked template, or by adding the attribute suppress_filters=’true’ to the wpv-post-body shortcode that links to the template.
I'm not sure if that is relevant without checking your site.