Disable Ajax Loading

[Sean]

This is a follow-up for Brook re: this topic.

Brook, just wanted to confirm if disabling Ajax loading for the search queries (when the “Find Events” button in the Tribe Events Bar or “Search” in the Filter Bar is engaged by the user) is possible as well? If yes, any recommendations for where to start?

Sorry for the new topic, but I realized after my last reply that I hadn’t confirmed that prior to the topic being closed 🙂

Thanks and have a great day!

[Brook]

Hello again!

It is definitely possible to alter the Tribe Bar/Find Events button I just updated the script to include that as well.

https://gist.github.com/elimn/308b6a6a6259d4ac3b6b

The Filter Bar is more complicated however. In order to facilitate this you will need to run the jQuery off() function as the above script does for everything else. Then you will need to either write your own submission script that doesn’t use Ajax, or add a submit button and get it working. Unfortunately this is probably going to be rather complicated, not just a script I could provide for you.

Please let me know if you any questions or anything. Thanks Karly!

• Brook

[Sean]

Thanks Brook. Really appreciate you adding the Tribe Bar snippet to the script!

Also thank you for the note on the Filter Bar. I take it that the Filter Bar doesn’t have the same core code as the standalone calendar and that’s why its not as simple as adding this to the snippet to disable the button there? (We had previously disabled the Ajax option in the Tribe options so a Submit button does currently appear on the Filter Bar)

// Filter Bar
		jQuery( 'form#tribe_events_filters_form' ).off( 'submit' );

UPDATE: I actually just gave it a try (disabled Ajax for the Filter Bar button with the above) and it appears to work. Are you aware of any side effects of doing this on the Filter Bar or could I be missing something as to why it couldn’t/shouldn’t be included in the snippet you had created? Just want to make sure it’s not going to break something 🙂

• This reply was modified 10 years, 3 months ago by Sean.
• This reply was modified 10 years, 3 months ago by Sean.

[Brook]

Oh awesome! I actually thought they had done away with that noajax submit button on the backend so I did not mention it. Happy to see I was wrong

I am not aware of any side effects off the top of my head. There are a couple of things I would test. Try selecting multiple filters and multiple items from the same filter (for example multiple categories). If that is working good then you should be setup.

• Brook

[Sean]

Hi Brook,

So it looks like everything works, except for the location search (due to, as you previously mentioned, the Google Map requiring Ajax to function correctly). The workaround to fix most of this is to use the built-in TEC option to remove the “location search field from the events bar on all views except for map view.”

However, that doesn’t resolve the issue with the Submit/Find Events buttons still “breaking” the first page of events returned on Map View. Is there any way we can modify the snippet so that disabling Ajax for the submit buttons only applies to the other views (List, Month, Day, Week) and not Map View?

		
// Tribe Bar
jQuery( 'form#tribe-bar-form' ).off( 'submit' );
		
// Filter Bar
jQuery( 'form#tribe_events_filters_form' ).off( 'submit' );

[Sean]

Ah, another item that gets broken is when viewing Previous events. Engaging the “Next Events” navigation clears the previous date from the Tribe Bar, thus the the 2nd page of events returned is for future dates. So it looks like this will unfortunately be a bit more complicated than it originally appeared.

With that said, I’d still be interested to know if there is a way to disable Ajax for the submit buttons only only certain views.

[Brook]

And this is why I was saying out the outset that Disabling Ajax is a quagmire. Hehe. I’m not sure if have only begun down the rabbit hole of issues trying to disable Ajax will cause.

Is there any way we can modify the snippet so that disabling Ajax for the submit buttons only applies to the other views (List, Month, Day, Week) and not Map View?

This will require some specific targeting. You could check the <body> tag has the class “tribe-events-map” attached to it. If it does, don’t run the JS I shared.

Engaging the “Next Events” navigation clears the previous date from the Tribe Bar, thus the the 2nd page of events returned is for future dates. So it looks like this will unfortunately be a bit more complicated than it originally appeared.

That’s going to be a limitation in our plugin that will require our JS cleanup to fix. Basically we rely heavily on JS to generate the proper URLs for previous events, map view, and such. And the functions that generate those URLs are intertwined with our Ajax. IN our cleanup we would like to decouple these, and further make it so the HTML itself always contains the proper link and thus doesn’t rely on JS. But until then I don’t really see a good way to fix it. Maybe a lot of JS hacking could get you there, but its the sort of hacking that is likely to break often with plugin updates.

I wish I had better solution here. Please let me know if I can clarify or be of further help.

• Brook

[Sean]

Hey Brook,

Yes, although it seemed promising at first, it looks like there are indeed still a number of issues that will prohibit disabling Ajax (even with the workarounds to remove the recurring events toggle and restricting the location search to only Map view).

I appreciate all of the insight and suggestions you provided here. Given that this would require so much hacking to ensure there is no broken functionality, I agree with you that it wouldn’t make sense to do so at this time (with it likely additional work would be needed to preserve the hack after each plugin update). Still, I am very happy to hear that, while not in the immediate future, there is a plan to address this further down the line by not relying so much on JS.

Until then, I’ll have to see if there is a way to get Google Analytics to track/record the Ajax events (Next/Previous Events page navigation and searches submitted via Find Event button) as if they were regular page views (so we can get accurate totals for our overall page views, etc).

Thanks and have a wonderful weekend!
Karly

[Brook]

Thank you Karly. I appreciate you’re patiently working with me through this. I wish our ending was a bit more fruitful.

Cheers!

– Brook

[Author]

Posts