As usual, I'd like to be assigned to a supporter in my timezone, but if that's not possible or will take longer, I'm fine with anyone.
Tell us what you are trying to do?
This is a live site which uses nested views to build a complete table for all the specs in a series...
enlace oculto
This is a staging site for the same system loaded through ajax following user scroll...
enlace oculto
It should be pretty obvious the benefit is a much lower initial load time.
The problem however is that some models in the staging site aren't being filtered by the URL parameters post ajax.
You can see this by clicking on "woofers" the ajax version is showing an 'archived' model that the slower live version is not.
It filters correctly for anything not controlled by URL parameters, so I'm sure those are the issue. So my question is:
Should I be calling something on ajaxComplete to make the views recognize the URL parameters? Some built in function?
Is there any documentation that you are following?
No.
Is there a similar example that we can see?
No. I can share my ajax/php and view structure if needed, but I'm hoping there is something you can point to on this... I didn't even notice this was an issue until I was implementing it on the live site.
What is the link to your site?
See above
Hi,
Thank you for contacting us and I'd be happy to assist.
I tried to view your staging website's page, but it is showing a "403 Forbidden" error.
What you've shared seems expected though. When the view is set to update the results without AJAX and through page reload, the query relies on the parameter values passed through the URL.
However, when the view is set to use AJAX, it relies on the parameters passed through the AJAX request itself and not the available URL parameters.
For this reason, if you're using the AJAX search view in a way that some URL parameters are being added manually (e.g. status=2&global=2 ), you'll need to make the view's query to look for them on subsequent searches.
You can use the "wpv_filter_query" filter for this as it can be used to override all views queries, whether it is with or without AJAX:
https://toolset.com/documentation/programmer-reference/views-filters/#wpv_filter_query
Tip: you can set the view to not use AJAX and then print/dump the "$query_args" to see how the query is set to use those filters for the URL parameters. After that, you can set it to use AJAX and then include the same filters for the URL parameters.
I hope this helps and please let me know if you need any further assistance around this.
regards,
Waqar
I really appreciate this...
I take it then I can't or shouldn't use something like urlParams.get('status'); to pass it from ajax data to php? Even if that were an option, I wouldn't know how to apply what I'm seeing in the example from the documentation going that route.
To start, can you give me an example of:
'you can set the view to not use AJAX and then print/dump the "$query_args" to see how the query is set to use those filters for the URL parameters. After that, you can set it to use AJAX and then include the same filters for the URL parameters.'
Don't know where to start on that, and I'm not finding examples, but I can say that trying this with a simple view...
add_filter( 'wpv_filter_query', 'return_view_query_args', 99, 3 );
function return_view_query_args( $query_args, $view_settings, $view_id ) {
$views = array( 155715 );
if ( in_array( $view_id, $views ) ) {
return $query_args[$views];
}
}
...is producing a mess that has nothing to do with the view.
Thanks for writing back.
You don't need to include custom data into the original AJAX request, since you can short circuit the query using the "wpv_filter_query" filter.
Here is an example of a simple function that prints the view's query in a readable form on the front-end:
add_filter( 'wpv_filter_query', 'wpv_filter_query_func', 1000 , 3 );
function wpv_filter_query_func( $query_args, $view_settings ) {
// skip if blocks edit screen
if ( defined( 'REST_REQUEST' ) && REST_REQUEST ) {
return $query_args;
}
// process if specific view
if ( !is_admin() && ( isset($view_settings['view_id']) && $view_settings['view_id'] == 12345) ) {
echo '<div style=""><pre>';
print_r($query_args);
echo '</pre></div>';
}
return $query_args;
}
Note: You'll replace "12345" with your actual view's ID.
This will give you a better idea of how the view's query works in different cases and with different filters.
For more personalized assistance around custom code, you can also consider hiring a professional from our list of recommended contractors:
https://toolset.com/contractors/
Thank you!
I ended up doing things differently. The $query_args were more complex than I figured and making sense of it for php was intimidating. Since this is a wpv_do_shortcode function, it's easier (for me) to just get the URL params with JS and pass them to PHP, where I can set them as variables in the shortcode attribute. These are then passed to the nested views, which were previously looking for the URL parameters, but now I have them looking for shortcode attributes.
I don't know that this is the best way to do it, and I might end up changing the overall structure, but I have tested this method and it is working without error.
I do sincerely appreciate being able to see the $query_args, and I'm sure I'll used that function again.
