Here's what I'm going to try next. Remove the map from view, have it render in the modal separately with no results. Use the do_shortcode ajax function on the list view and then run init on modal shown.
My thinking is that the map by itself with no results will take a fraction of the time to load as there is no query, then (hopefully) I can get the results to show on the map via ajax.
I have one view showing the results, and the map is rendered separately in the template HTML.
I tested the view with the map (before setting up Ajax) and it worked fine, as did maps_init. But after setting up in Ajax they won't connect. I added in map_reload thinking that would help, but still not connecting.
I understand the map not loading via Ajax, but I figured I could at least get the view to connect to an already rendered map post ajax. What am I missing?
Not sure, the markers object is empty so that's where I would start digging if no markers are appearing on the map:
WPViews.view_addon_maps.markers
Normally there is information about each marker available here, grouped by map ID. It doesn't seem to be set in your case when I open the map popup (screenshots attached).
I'm guessing it was this way with the other setup, but we didn't notice because we were focused on the map not loading at all.
I really thought I had it figured out when I decided to just bring the results in separately. Never considered that the markers would fail in the same way the map had failed.
I'm not seeing any functions that could be called on ajaxComplete to make the markers show up.
Am I missing or misunderstanding anything? Is there some function I can use to bring these in? Not that it would help, but Markers don't have init or reload. Surely I'm not the first person who's thought to bring in a map view via ajax, but the only other post I found on the topic was left hanging.
If not, what about a way to kill the view's automatic query on load?
At least that way I can trigger query with a user action to save time on page load.
I reactivated the Open Search button (it's in an awkward place at the moment) and using it to search will connect the results to the map. That's a positive development.
NOTE: Use my location doesn't work. When you put in a location in the input and submit, it activates ajax and the map connects.
Even if you have nothing in the input, just clicking submit triggers the ajax and connects the results with the map.
This means I can add a click function to submit on ajaxComplete with nothing else and get the connection. That also slows it down a bit, and means there are two queries instead of one. Problem is somewhat solved, but it's still not ideal. Very open to suggestions.
I'm not seeing any functions that could be called on ajaxComplete to make the markers show up. Am I missing or misunderstanding anything? Is there some function I can use to bring these in?
I'm not aware of any public API available for this, no. That's really the crux of the problem, there is no public JavaScript API available to achieve what you're looking for, so it just involves stepping through code and figuring out how things work. That's outside the scope of what I can offer here - it's essentially asking me to help you understand the plugin's code and create a feature that does not exist, i.e. a public API for implementing a map ad hoc with results loaded from an ad hoc AJAX query. Our support team is not allowed to create new features, per our support policy: https://toolset.com/toolset-support-policy/
I admire that you're trying to optimize this experience as much as possible. Google Maps is pretty well optimized to load over AJAX without render-blocking, so my guess is the main thing delaying serving up this page is the View queries that have to hit the db. Realistically if the key is optimizing time-to-first-byte, a 3rd-party caching plugin that generates a static HTML version of the page and serves that up instead of hitting the database will give you better TTFB results than any optimization of an individual View or Views. Given that there are already several Views on the page, apart from the map Views, and the server has to hit the db to get the results of all those queries before the first byte is served, I would venture to guess that the amount of time saved by a caching plugin would eclipse the time savings from delaying individual Views queries like you're trying to do here. The results of all the queries on the page would be available at runtime in a static HTML page, which will always be faster than a page generated by querying the DB. My guess is you would get better return on your time spent optimizing that caching routine than reverse engineering maps functionality without developer-level support. That's what you really need here, in my opinion, but it's not available. As a practical solution for the page speed issue, I think a caching plugin is the best investment of your time here.
I understand what you're saying. I'm running W3 Total Cache, and it's terribly inconsistent and has perhaps caused more problems than it has solved as some users don't see updated materials.
Putting all of the Table Spec queries into ajax has been a huge speed boost. Turning the map on and off shows me about a 10 point difference on the lighthouse score and that's not easily dismissed when Google is waging war on sites with any noticeable latency.
Last questions... just so I'm not leaving anything unturned...
Is there any way I can I kill that first query on load?
Which is to say, can I do anything to make the first query a result of user action...
ie, let everything render in a view (no ajax), but prevent a default search from being performed...
So that the first search is one which requires the submit button?
Surely someone has looked into preventing a view from loading results until a submit, right?
Alright, that's going to be it, if there's nothing in that direction, I'll close the ticket.
Surely someone has looked into preventing a view from loading results until a submit, right?
Usually some query is performed at load time unless you separate the filters from the results and display the filters on a separate page. Most cases I've seen where clients want to prevent a View from loading results upon page load are intended to prevent results from displaying until the user has chosen a filter or submitted a text search. The solutions are all reliant on some kind of programmatic query manipulation, like setting post__in to -1 using wpv_filter_query for example:
You would replace 123 with a comma-separated list of all the View IDs you want to prevent loading at page load time, and add your own conditional logic to suppress the change to $query_args for the manually-triggered query. This filter does not prevent a query, it short-circuits the other filters for a faster response (in theory...it would worth checking the real TTFB in all scenarios). Filter docs: https://toolset.com/documentation/programmer-reference/views-filters/#wpv_filter_query
Another solution I've seen to achieve an empty result set before filters are submitted is to drop the results of the query using wpv_filter_query_post_process - but as the hook name implies it runs after a query has been performed. It would not be helpful here.
Thank you! I can probably make this work. If I can short circuit the view and then do the search with a click function or scroll function on document ready, then I will have effectively succeeded in what I was trying to accomplish with ajax.
