[Sean]

Hi Geoff,

Thanks for clarifying. With this I was able to get to where I needed. Appreciate your help.

Best,
Karly

[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

[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.

[Sean]

Hello again 🙂

Thanks so much for this suggestion. It got me started down the right path and I was able to target the desired events/posts. Enjoy your evening!

Best,
Karly

[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]

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.

[Sean]

This reply is private.

[Sean]

Okay great thanks again Brian.

In case this helps anyone else using Avada, we added the following to /Avada/includes/class-avada-layout.php which got the sidebar appearing on the /all/ pages.

		if ( tribe_is_recurring_event() && ! is_singular( ‘tribe_events’ ) ) {
			$sidebars = array(
				'global'    => '1',
				'sidebar_1' => Avada()->settings->get( 'ec_sidebar' ),
				'sidebar_2' => Avada()->settings->get( 'ec_sidebar_2' ),
				'position'  => Avada()->settings->get( 'ec_sidebar_pos' ),
			);
		}

[Sean]

Thank you

[Sean]

Hi Geoff,

Thanks for your response and this info. I apologize, but I’m still a bit unclear regarding a few aspects of this. If you can address the following, it would be greatly appreciated:

1. I understand that the tribe_events_mobile_breakpoint filter applies to all mobile breakpoints. Does another filter exist for modifying the Filter Bar’s breakpoint?
2. Can you please confirm if the Filter Bar has its own mobile breakpoint or if there is only one mobile breakpoint for the entire calendar?
3. If we want to set the Filter Bar’s responsive breakpoint to kick in not only when the screen size reaches the calendar’s breakpoint, but also when the size of the container holding the calendar reaches that same breakpoint, what is the best way to achieve that (for a non-developer such as myself)? Should we start by copying the Javascript that calculates the container width and adds a CSS class? Or is another method recommended? In either case, can you please share where the aforementioned CSS and JavaScript files are located?

Best regards,
Karly

[Sean]

Thanks again Brian. I’m not a coder (the developer I hired for a project last month had pointed this issue out to me) so I’ll need to find some additional help in how to apply this conditional to our use case. I’m guessing that once we determine what the exact coding for the conditional statement is, it needs to be added to our functions.php?

[Sean]

Hi Brook,

Thank you very much for updating this for the other compatible views, I really appreciate it! And completely understand that it may break in future versions and that the ability to disable ajax paging on all views isn’t likely to happen in the short term. In the meantime, this snippet will be the next best thing 🙂

Thanks again for all of your help with this!

[Sean]

Hi Brian,

Thanks for recording this. Can you please clarify what the workaround in the meantime is? We do have a sidebar on our single event template, but I don’t follow what you suggested above. Thanks for your help.

[Sean]

Hi Geoff,

Thanks for the info. I had previously read over those docs so I was hoping to hear there was a filter to quickly modify the Filter Bar’s breakpoint. Can you confirm if such a filter exists?

Also, it appears that the events bar breakpoint is set by Javascript: it calculates the container width and then adds a CSS class. Can you offer some guidance on how we could “copy” that and apply it for use in setting the Filter Bar’s breakpoint to also change based on the calendar’s container width? Or better yet, can you check with your developers to confirm what the best way to accomplish this is? The goal is to: set the Filter Bar’s responsive breakpoint to kick in not only when the screen size reaches the calendar’s breakpoint, but also when the size of the container holding the calendar reaches that same breakpoint.

Thanks.

[Sean]

Good morning Brian,

Thanks for logging this in the bug tracker. Yes, I have also found that to be the case.

[Author]

Posts