Problem: I have a nested View structure that shows parent posts in the outer View and child posts in the nested View. In some cases the parent post has no child posts, and I would like to hide those parent posts in the results. The problem is that the nested child post View is filtered. Is there a conditional that tests whether or not a parent post contains these filtered child posts?
Solution: You can solve this without custom code by restructuring the Views. Instead of displaying the parent post information in the outer View, display the parent post information in the nested child View, inside wpv-items-found but outside wpv-loop. Use the item attribute to display parent post information with any shortcodes in the nested View, since the post context in the nested View is the context of the child posts. The syntax for the item attribute is item="@relationship-slug.parent" in a typical one-to-many (O2M) relationship.
Problem: I have a View of custom posts that displays a map with markers, using a distance filter and sorting results by distance. In some cases the distance center is set by a URL parameter, and in others, it is set by a shortcode attribute. I have implemented some custom code in a wpv_view_settings filter to toggle between the shortcode attribute and the URL parameter. In the cases where distance center is set by a shortcode attribute, I am using another custom shortcode to get the User's predicted zip code. That shortcodes an external service to get a predicted zip code based on the User's IP address. The custom zip code service seems to be working correctly, and the results of the View seem to be accurate.
However, in the cases where this zip code shortcode is used to set the View's distance Query Filter by shortcode attribute, the View consistently causes the page generation time to jump by 3 or more seconds. I would like to try to optimize the page load time as much as possible.
Solution: In this case, testing revealed that using the custom zip shortcode inside a wpv_view_settings filter callback was the source of the delay in page generation, for some reason not fully understood. Replacing that shortcode with a hard-coded zip code resulted in a page generation time just a fraction of a second higher than the page without the View present at all.
Optimization of the zip code shortcode is necessary to prevent the latency seen in page generation time.
We document known issues and their solutions in Toolset errata. Save time by checking there first and seeing if what you are facing is a known issue. This list is kept short. We do our best to resolve all known issues with every release of Toolset plugins.
Support Policy
Toolset staff will help you use the Toolset plugins correctly, provide any information you need, help troubleshoot problems and advice on best-practices.
Please make sure to issue only one topic per each support ticket.
