[Resolved] Views: wpv-items-found and wpv-no-items-found not parsing

[Author]

Posts

[laneV]

I have 2 views that are nearly identical. They act on different CPTs but both have similar filters to query via a relationship in a URL param.

"States" in a country view: hidden link
"Locales" in a state view: hidden link

Both worked exactly as I wanted earlier today. The only issue I had was that if a wpv-relationship-filter query param was not passed the views would show everything rather than nothing. I added a custom function to return the value of that param if it existed via a shortcode so I could use it in a conditional:

add_shortcode( 'value_relationship_filter', 'value_relationship_filter_func' );
function value_relationship_filter_func () {
if ( isset( $_GET['wpv-relationship-filter'] ) )
return $_GET['wpv-relationship-filter'];
else
return '0';
}

I added the conditional statements to both views. The "States" view works as expected with the conditional. However, with the "Locales" view the conditional seems to work but nothing within the wpv-items-found and wpv-no-items-found sections of the loop will output anything.

I've attached a screen cap of Winmerge showing the critical parts of both views are identical. I can't find anything to suggest why the States view completely works but the Locales view does not.

If I remove only the conditional around the wpv-layout-start / wpv-layout-end blocks in the Locales view loop editor it will output the contents of wpv-items-found / wpv-no-items-found fine, but it does not like the conditional block around it.

Since one view works and the other does not, and they are nearly identical, I can't find a reason to believe this is another plugin conflict or theme issue.

I have a duplicator archive available via OneDrive link if you'd like it - the support form will not let me provide it (probably because the URL doesn't end in .zip?). Let me know if you need it.

Thanks in advance for your help on this!

[Waqar]

Hi Lane,

Thank you for contacting us and I'd be happy to assist.

A shortcode parsing issue like this can be experienced if long content is enclosed inside the conditional shortcode block "wpv-conditional".

You'll note that the main difference between the two views is the amount of content that is being loaded through the loop item's content template.

This limitation is not something specific to Toolset plugins, but it is related to how shortcodes are parsed by WordPress in general and the server's PHP configuration. A note about this is also included on our documentation at:
https://toolset.com/documentation/user-guides/conditional-html-output-in-views/

When this is only happening on a specific server, you can follow these steps to fix this:

1. You can try further increasing the allowed memory size in PHP settings of your server.

2. If that doesn't work, you'll need to disable the "PCRE JIT" via php.ini (pcre.jit=0). For more info you can check out the following links or consult your host's support team:

hidden link
hidden link

3. If for some reason, options 1 & 2 are not possible or don't work, you can follow a simpler workaround of hiding the content using a special div wrapper, which can show or hide the view's content conditionally:

Example:

[wpv-conditional if="( '[value_relationship_filter]' eq '0' )"]
<div class="hidden">
[/wpv-conditional]

[wpv-layout-start]
.......... everything in between ..........
[wpv-layout-end]

[wpv-conditional if="( '[value_relationship_filter]' eq '0' )"]
</div>
[/wpv-conditional]

As a result, the view's output will be wrapped inside a special hidden container, when the "wpv-relationship-filter" URL parameter is not set.

Additional note: To get the value of the URL parameter inside the view, you can use the builtin "wpv-search-term" shortcode too, which will save you from registering a new shortcode like "value_relationship_filter":
( ref: https://toolset.com/documentation/user-guides/views-shortcodes/#vf-214940 )

Example:

[wpv-conditional if="( '[wpv-search-term param="wpv-relationship-filter"]' eq '' )"]
URL parameter "wpv-relationship-filter" doesn't exist
[/wpv-conditional]

[wpv-conditional if="( '[wpv-search-term param="wpv-relationship-filter"]' ne '' )"]
URL parameter "wpv-relationship-filter" exists
[/wpv-conditional]

I hope this helps and please let me know if you need any further assistance around this.

regards,
Waqar

[laneV]

Hi Waqar,

Thank you very much for the detailed response. I missed the details in docs about the wpv-search-term shortcode, I'll definitely change to use that instead.

From the options you provided I have some comments/questions:

1) I can play with this a bit but leary of pushing it too much as my server needs grow more quickly with traffic gains.

2) From the Toolset perspective, what is the impact on efficiency in disabling pcre.jit? I personally don't use overly hairy regex but I don't know what Toolset is doing under the hood.

3) Once all is said and done, I'll end up with tens of thousands of locations, thousands of regions and locales. I'd really like to avoid having to serve up all that data if the wpv-relationship-filter value is not passed. Simply hiding the data means it still has to be transferred to the client app or browser. Do you know of a better way I can accomplish this? Worse case, I could do an htaccess rule to catch specific page loads without the param in the query string but I'd prefer to keep it within WordPress/Toolset so there are less places to go look when something is not acting correctly.

Thank you!

[laneV]

1) Even quadrupling memory_limit up to 1024M did not resolve the problem.

2) Disabling pcre.jit did not resolve the problem.

3) If there is a way to catch the missing param in the query string via toolset that would be ideal. Pushing thousands or tens of thousands of locations out when the param is missing is far from ideal.

In case it helps someone else, I was able to use htaccess to identify the missing param and redirect to my first level page:

# CATCH EMPTY QUERY STRINGS ON 2ND AND 3RD EXPLORE LEVELS
RewriteCond %{REQUEST_URI} ^/(explore-state|explore-city)
RewriteCond %{QUERY_STRING} ^$
RewriteRule ^(.*)$ hidden link [R=302,L]
# END CATCH EMPTY QUERY STRINGS

If there is no toolset solution I may end up passing a query string param to the explore page so I can surface an error message to make this more user-friendly.

[Waqar]

Hi Lane,

Thank you for sharing the update.

Since this issue varies with the server's configuration and the amount of the data that is involved, I won't be able to test this on my own website and suggest a concrete workaround. But I can suggest the following alternatives to the htaccess rule ( since it does sound like an overkill ):

1. Instead of using the condition to check the presence of a URL parameter inside the view, try to use it around the view's shortcode, that is being used to call it on the page:

Example:

[wpv-conditional if="( '[wpv-search-term param="wpv-relationship-filter"]' ne '' )"]
[wpv-view name="slug-of-the-view"]
[/wpv-conditional]

2. If option 1 doesn't work, you can test this with a new custom shortcode which checks for the "$_GET['wpv-relationship-filter']" value and only if it exists, calls the view's output using the "render_view" function:
https://toolset.com/documentation/programmer-reference/views-api/#render_view

3. Another alternative is to use the "wpv_filter_query" filter, in case the query filter for the relationship is not present in "$query_args":
https://toolset.com/documentation/programmer-reference/views-filters/#wpv_filter_query

Tip: Print/dump the $query_args and you'll see how it works.

I hope these suggestions will help.

regards,
Waqar

[laneV]

Thank you, Waqar, great feedback! I really appreciate the time and thought you put into your suggestions. I'll work with these to find the best resolution.