[Resolved] display certain number of published posts in many-to-many cpt view

[Author]

Posts

[jimP]

Greetings! I'm working with a view that queries an intermediate CPT in a many-to-many relationship between a post and a contributor; this view will be inserted into a contributor summary view. In the summary view, I would like to display a certain number of published posts only. I can't find a good way to do this:

(1) If I were querying the post directly, I could readily add a query filter for post status = publish, but my view queries the intermediate CPT since it's inserted into the contributor view, and all intermediate CPTs are status = publish, even those that point to unpublished posts. So, currently I pull all (published + unpublished) posts via the query, then when displaying them I use a conditional:

[wpv-conditional if="( '[wpv-post-status id="$post"]' eq 'publish' )"] loop content here [/wpv-conditional]

(2) I can, in this view, readily choose to display only a certain number of posts via Limit and Offset, but this number represents all posts, not just published posts, so this doesn't work with the code above: it just identifies say the first 3 posts, then checks to see if each has been published.

I suppose, as an alternative to Limit and Offset, I could somehow create a counter inside the conditional code noted above that iterates up to the desired number of posts...but I don't know how to do that within Toolset shortcodes. (Can I possibly do this via wpv-item inside wpv-conditional?)

Any help would sure be appreciated; thanks!

Jim P.

[Beda]

If I get it correctly you want to return only a certain amount of Posts (parents) of the desired status.

You already have successfully restricted to the correct status but now need to limit and eventually offset the output, correct?

Since yo can't address the Queried Post type (Child Intermediate) for the given reasons, I also would go with a Conditional, but that will not be possible.

See, you can not use a ShortCode in a wpv-for-each to call a parent's field, and it's only to use for Post Meta fields.
https://toolset.com/documentation/views-shortcodes/#wpv-for-each

wpv-item also will iterate the current post, it has no argument for querying or iterating a Parent Post Field
https://toolset.com/documentation/views-shortcodes/#wpv-item

Perhaps it can help you, as if you add it in the conditional you use now, it will only iterate the CHILD (intermediate) posts where the parent post status is published, but it will NOT iterate the parent!

So what you need to do is set the correct Post Status to your Intermediate Post Object and then return in your View only the Published ones, iterating with the Views Limits and Offsets filters.

If that's not possible, a additional Field must be added to your Intermediate Post Object, where you define a custom "publish" status.

Thank you

[jimP]

Thank you, Beda. I understand your recommended solutions, but each will involve additional manual steps on the part of my users (e.g., editing post status of intermediate posts, which they actually never see; or adding/editing a field to this intermediate post). I have also tried nesting wpv-item inside my conditional, and indeed it does not work correctly for the reason you provided.

Here is how I'd like to do this, and outside of Toolset it would be simple...inside of Toolset it involves nested conditionals, which appear possible:

https://toolset.com/documentation/user-guides/getting-started-views/part-6-conditional-statements-in-views/

It would also, I imagine, involve a custom function in the conditional, which is also possible:

https://toolset.com/documentation/user-guides/conditional-html-output-in-views/using-custom-functions-in-conditions/

The steps would be as follows:

(0) Initialize a custom counter function outside of wpv-loop, setting it = 0.

(1) Enter wpv-loop

(2) Enter the conditional I've presented above. If the parent post is published, the intermediate post passes to step (3) below; if it is not published, wpv-loop iterates to check the next intermediate post.

(3) Iterate the custom counter function, setting it to current value + 1.

(4) Enter a second conditional, checking to see if the custom counter function is ≤ some target number of posts. If true, the parent post-link etc. are displayed. If false (i.e., we have exceeded the target number of posts), wpv-loop iterates to check the next intermediate post. (This is not an elegant feature of the code; would be nice to escape the loop at this point, but I don't think we can do this in Toolset shortcode.)

(5) Close the second conditional.

(6) Close the first conditional.

(7) Close wpv-loop, thus iterating back to (2) for remaining intermediate posts identified via the query.

If the above is doable, then I just need to figure out code for a custom counter function, and steps (0), (3), and (4); I'd imagine this custom counter function may be helpful to other Toolset users as well.

Many thanks for your support.

Regards,

Jim P.

[Beda]

The Custom Functions work in Conditionals, this is correct.
But we do not code this functions.

This feature is intended to be for Developers who have their Custom Functions and use them in conditionals.

You register them only for security reasons and pas them through our own preprocessor.

What you need is a complete Custom application logics that customizes the Views Query and Loop output.

I do not suggest this approach. It will invoice to much Custom Code that we can not debug in cases of troubles.

What you might to is, create a Custom Query, with a Limit and Offset, that gets the Parent Posts of the Current Posts (in Views Loop)
This could be returned as a ShortCode inside your conditional check (is parent post published)

Since you already would craft a Custom WP Query you could also already limit this to published posts only in the Query Function.

The Documentation of WordPress on how to do this is here:
https://codex.wordpress.org/Template_Tags/get_posts

This can be returned in a ShortCode following this DOC:
https://codex.wordpress.org/Shortcode_API

But this requires advanced Custom Coding, which we can not provide.

I could help you achieve this with another approach, perhaps using a Front End "admin" section, created with Views and CRED.

With this you could actually decide, if the submitted posts are published or not, which you can not, yet, in your Admin, when you create a Child Post type.

Thank you

[jimP]

We've decided to edit our summary view, since accomplishing the desired result proved difficult as documented above.