Scroll To Div on Filter 'View As' Change

[Ryan]

Hello,

We are in development now and our home page has a list of featured events (using the events widget) and then has the filter bar with the ‘photo’ view set as default. We enabled (2) other views (MAP & MONTH).

The issue we have is when we change the ‘View As’ to MAP or MONTH the page refreshes and we are then at the top of the page again, so the user needs to scroll down to see the changed view.

Obviously this is not a bug and is the correct functionality, but is there a way to scroll to the appropriate anchor when the view is changed so the user doesn’t get confused as to why they changed views and don’t see the changed view immediately?

I can use jQuery and check if the body has a class (ie. tribe-events-map) and if so, scroll to the appropriate part of the page. This works fine, but using this technique means anyone who hits the landing page would be scrolled to the same div as if they changed to the ‘photo view’ since the default ‘tribe-events-photo’ class is being used on the home page due to the default view being photo.

Any suggestions?

Thanks in advance.

[Brook]

Hello Ryan,

That is a great question. I would love to see that area loaded via ajax, but there are some technical trade-offs towards implementing that.

Have you seen our Themer’s Guide? Using a theme override as outlined there, you could override /the-events-calendar/src/resources/js/tribe-events-bar.js . Inside that file you will see tribe_events_bar_change_view(), near the end there is this line:

window.location.href = ts.cur_url;

Replace that with:

window.location.href = ts.cur_url + "#tribe-events";

You might need to enable the WordPress constant “script_debug” to see these changes. By default our plugin loads the minified versions of files, but with script debug it will load the unminified ones which are easy to modify.

Does that all make sense? Will that work for you? Please let us know.?

Cheers!

– Brook

[Ryan]

Hey Brook,

That seems like the perfect solution. I wasn’t sure how to append the # on the URL as it was dynamically created so that should work perfectly and will only fire when the view is changed which is perfect. I will implement this and test this afternoon and comment back if I have any issues or if we’re all good.

Thanks for the great solution!

Matt (Ryan’s Developer)

[Ryan]

Hey Brook,

Can you point me in the direction on how the file structure should work in my child theme for that file since it isn’t in the ‘views’ folder in the parent theme? I can’t find anything related specifically to that, but I may be missing something.

Much appreciated.

Matt (Ryan’s Developer)

[Ryan]

Hey Brook,

I was enable to get this working by dequeue-ing the ‘tribe-events-bar’ script and enqueue-ing my modified one and putting the script_debug constant in place per your suggestion. Here is the code:

add_action( 'wp_enqueue_scripts', 'mw_enqueue_fonts' );
function mw_enqueue_fonts() {
     wp_enqueue_style( 'google-fonts', '//fonts.googleapis.com/css?family=Lato:100,300,400,700,100italic,300italic,400italic,700italic|Roboto:400,700,500italic,500,400italic,300italic,300,100italic,100', array(), CHILD_THEME_VERSION );
     wp_enqueue_style( 'font-awesome', '//maxcdn.bootstrapcdn.com/font-awesome/4.1.0/css/font-awesome.min.css', array(), CHILD_THEME_VERSION );
     wp_dequeue_script( 'tribe-events-bar' );
     wp_enqueue_script( 'pondhole-tribe-events-bar', get_stylesheet_directory_uri() . '/js/tribe-events-bar.js', array( 'jquery' ) );
}
define( 'SCRIPT_DEBUG', true );

I’m guessing that leaving the script_debug constant in place is not ideal. How can I go about dequeue-ing the minified version of the tribe-bar script and enqueuing one that I minify?

I’m just about there!

Thanks,

Matt

[Brook]

I’m guessing that leaving the script_debug constant in place is not ideal. How can I go about dequeue-ing the minified version of the tribe-bar script and enqueuing one that I minify?

That’s a good point Matt. You can disable it, then dequeue …/js/tribe-events-bar.min.js instead.

Your method of dequeueing works great. I would stick with that so that you can disable script_debug and not have to worry about anything.

Does that answer all of your questions? I am really happy you were able to get it working.

Cheers!

– Brook

[Ryan]

Hey Brook,

What is the handle to dequeue the minified version of the tribe-events-bar. I can’t seem to find any reference on how to target the minified version.

I disabled the function to dequeue the ‘tribe-events-bar’, removed the script_debug and ran another script to show all the handles of the js files and it shows ‘tribe-events-bar’ but no reference to a handle for the minified version so how can I go about targeting the minified one?

Just about there! Thanks for the continued support.

Matt

[Brook]

You are very welcome Matt!

The handle is actually the exact same. You can still dequeue it with tribe-events-bar. All you have to do is disable script_debug, and then tribe-events-bar becomes the minified version. So you can keep this line and you should be up and running:

wp_dequeue_script( 'tribe-events-bar' );

Did that work?

– Brook

[Ryan]

I guess I was just overthinking it, huh?

That almost did the trick. I needed to comment out two instances of this line as I was receiving console errors the the map wasn’t showing:

dbug && debug.info( 'TEC Debug: tribe-events-bar.js successfully loaded' );

Once that was done we’re all good. No console errors and it is functioning properly.

Thanks for all the help!

Matt

[Brook]

Oh interesting. I did not think about that. Thank you very much for sharing the solution! Good luck with the rest of your site. Let us know if you ever need anything else.

– Brook

[Author]

Posts