[Resolved] Sorting by intermediary post type fields does not work

[Author]

Posts

[Nigel]

Sorry for the delayed response, I was off Friday.

The copy of your site I have updated is now missing the View that was added to the Kliniken post ID 756, so I'm going back over our discussion to refresh my memory about what it contained.

From the outset I've been a little confused about what you are doing, given that you added the View to show related employees directly to a single Kliniken post rather than to a template for all Kliniken posts, complicated by not using the block editor for those posts.

Given that what you are doing is not working for some reason that is difficult to determine, I think it would be a good idea if you could re-state to me in words what your intention is without focusing too much on the details of the implementation, and then I can propose and test a solution that hopefully meets your objectives.

Let me re-state the basics: you have Kliniken posts connected to Mitarbeiten-inner posts. The order that the employees would be output when shown for a particular clinic should be determined by a custom relationship field.

Starting from clinic posts (is it all clinic posts, one clinic post, some clinic posts?) you want to display a grid of related employees (ordered by the indicated custom field), which should include certain fields from the employee posts, including the featured image.

Is that it in a nutshell?

Where is it important which choice of editor you use? You want to use Avada to edit the clinic posts?

[haraldO]

Hey Nigel,

that is all correct, yes. I need Avada for the clinics themselves. Thus the view is inserted via shortcode. Block Editor for Views and Content Templates would be nice but I can also work with HTML/CSS.

In here both my view and your view are inserted, Avada's live builder isn't always showing them, so you might need the backend builder - but on the frontend both listings/views show up: hidden link

I also managed to get the Featured Image to be available in Block Editor's dropdown, but it just will not show up on the frontend. The src path is wrong. I suspect the DB query is being messed up somewhere which makes this problem so difficult.

Best
Harry

[Nigel]

One thing you didn't answer was whether the View would be displayed on all clinic posts, some of them, or just the one.

I tried to get this working on your site with a new template and View, and it proved a frustrating experience. Frustrating and ultimately unsuccessful.

One thing to be aware of generally with dynamic sources is that the current post (when you design the output of a View it may output many posts, but the first one is used to specify the design and is used as the source for the sample data) must actually have a value for the field you are trying to set as source.

So for the Image block, you can only set Featured Image as the source if the current post has a featured image.

It is a potential gotcha, and I did stumble across some employee posts that do not have a featured image, but even when ensuring that the first post returned by the View does have a featured image, I still ran into the same problem of being able to specify it as a dynamic source.

So I resorted to creating a View with the legacy editor. That doesn't try to generate live previews as you are editing, and is more robust.

I had no problem creating such a View, which I inserted at the end of the post with ID 756, after the existing Views.

If you visit that clinic on the front end you will see it working (the design is rudimentary).

As an interim solution, so that you can continue to work with the block editor, you could—in place of the problematic Image block—use a shortcode block to insert the wpv-post-featured-image shortcode.

From my classic View you can see that the full shortcode with the attributes required to reference the related employee post (rather than the current intermediate post) is:

[wpv-post-featured-image size="thumbnail" item="@klinik-mitarbeiter.child"]

See https://toolset.com/documentation/programmer-reference/views/views-shortcodes/#wpv-post-featured-image for more details about that shortcode.

Finally, a note on Views and the block editor.

With legacy Views there is a dedicated editor, and you can create a View directly at Toolset > Views.

But when designing a View via the View block the context must be the block editor, which is why you ordinarily create a View by adding a View block to the page where the View will be shown. (The View has to "live" somewhere that uses the block editor.)

Where you might re-use a View in various places it may not make sense to create the View in a specific page, and in that case you might want to create an empty unassigned Content Template (which provides the block-editor context) to host your View, and then wherever you want to insert the View you actually insert its host template.

I think that might help here, as I'm having problems editing Views where they have been added on pages or posts using the Avada editor.

If this were a more generic problem that I could reproduce then I would be escalating these difficulties to the developers, but we are not able to reproduce them on the sandbox site and the problems appear to relate to some specific but hard-to-determine circumstances with your site.

[haraldO]

Hi Nigel,

thanks for digging in to this. It is very frustrating for me as well. The view will be inserted in all clinics but at different places, it depends on the pagebuilding and the contents of the clinic. The clinics are too individual for a generic template.

I understand the dependencies better now with your explanations, thanks. The context is important, that is also why I created most views directly as a post of the custom post type where I need it. I am completely at loss as to what the issue could be on the site because on your demo everything worked fine and on my page it didn't despite disabling all other plugins and the Avada theme. The only difference - as far as I can remember - was that my clinics have multiple relationships with other post types.

Finally, thanks for providing a workaround (or rather even two!), feels like a happy end for me 🙂

One last question: Is it possible to enable revisions for content templates?

Thanks
Harry

[Nigel]

There is no setting for that available, no.

But when post types are registered in WordPress it is possible to intervene and override the settings.

The view-template post type is probably registered pretty early, so it would be a good idea to add the code to modify the settings to a Must-Use Plugin.

So add this code to a file (call it whatever you like, e.g. view_template-revisions.php) and then save the file in the folder wp-content/mu-plugins/.

Note, I haven't tested this. In principle it should add support for revisions, but that is no guarantee they will work very well: they may not be enabled by default for a reason.

<?php
/*
Plugin Name: Modify View Template Args
Description: Add support for revisions to Toolset Content Templates
Author: Toolset Support
Version: 1.0
*/
add_filter('register_post_type_args', 'modify_view_template_args', 10, 2);
function modify_view_template_args($args, $post_type) {

    if ($post_type === 'view-template') {

        $supports = $args['supports'];
        $supports[] = 'revisions';
        $args['supports'] = $supports;
    }

    return $args;
}