[Cliff]

Thanks, George.

To clarify, your last response makes way more sense. Previously, what I read here and in other threads gave me the impression that y’all intentionally disabled this functionality, as opposed to it being a bug that was hard to track down.

• This reply was modified 7 years, 3 months ago by Cliff.

[Cliff]

“I ask because in 4.4.x you cannot edit recurring event permalinks.”

Um, seriously? I’m kind of at a loss about this right now. That completely ties up people from being able to control their own data, simply by updating to the latest version of the plugin. It’s not even in the release notes. That’s not OK.

How do I get this control back for my client?

• This reply was modified 7 years, 3 months ago by Cliff.

[Cliff]

Thanks, George!

Is there any way to point me to the commit(s) in GitHub so I can see how it was handled?

[Cliff]

Any updates? I saw a new version get pushed, but didn’t see anything in the changelog related to this.

[Cliff]

I can confirm that it still happens, even with the default theme enabled and all other plugins disabled.

I’m fairly certain the plugin has started making an incorrect assumption about <i>where</i> the plugins directory is on the server, which is caused by not properly following the symlinks. I’ve helped many plugins with this—since doing so is fully supported by WordPress—but this problem is new as of 4.3 with this plugin. 🙂

Things start breaking down with the maybe_get_min_file() function. It’s trying to detect a Windows hosting environment, but that logic doesn’t appear to account for symlinks.

[Cliff]

I’m currently fixing it with something like this, but that’s not sustainable:

add_filter( 'tribe_asset_pre_register', 'myprefix_tribe_asset_pre_register' );

function myprefix_tribe_asset_pre_register($asset) {
	
	$asset->url = str_replace('/home/username/public_html/shared/', content_url() . '/', $asset->url);
		
	return $asset;
	
}

• This reply was modified 7 years, 6 months ago by Cliff.

[Cliff]

For more context, instead of something like

http://example.com/wp-content/plugins/the-events-calendar/common/vendor/jquery/ui.datepicker.css

I’m getting:

http://example.com/wp/home/username/shared/plugins/the-events-calendar/common/vendor/jquery/ui.datepicker.css?ver=4.3

It’s throwing the full path into the URL.

[Cliff]

Actually, I dove in and found how to isolate the issue.

Since all the event handlers and such are put in by the same script that gives the mobile calendar its functionality, the only other solution was to hack up the JS, which isn’t sustainable. Instead, I went through and found the event attachments and then removed them with jQuery. Here’s the crude function:

function fix_ecp_ajax_mobile_calendar_nav() {
	
	echo "
	<script>
		jQuery(document).ready(function(){
			jQuery( '#tribe-events' ).off( 'click', '.tribe-events-nav-previous, .tribe-events-nav-next' );
			jQuery( 'body' ).off( 'click', '#tribe-events-footer .tribe-events-nav-previous, #tribe-events-footer .tribe-events-nav-next' );
		});
	</script>";
	
}

add_action( 'wp_footer', 'fix_ecp_ajax_mobile_calendar_nav', 99 );

A word of feedback might be to find a way to separate these concerns eventually. Cheers!

[Cliff]

Thanks! The AJAX call itself appears to be working (I can see results when I inspect the network calls), but has trouble putting the result in. Again, I think this is just a conflict buried too deep in this set of themes and plugins.

It looks like the handle for the main script I was looking to remove changed to the-events-calendar, so I had to use wp_dequeue_script( 'the-events-calendar' ); instead.

That said, taking out that script also completely disables the ability to select a day or event on mobile. 🙁 Any ideas on keeping that functionality while allowing the navigation buttons to not operate by AJAX?

• This reply was modified 8 years, 4 months ago by Cliff.

[Cliff]

Great! I’ve added what I did in a gist here: https://gist.github.com/logoscreative/1319e493470a5cbfcd83

I changed some of the spacing to make it more consistent, and I believe I also added a check against is_admin() on the pre_get_posts hook.

If you’d like to get this out there but don’t have time, I’m happy to at least release it and then transfer it to you later on. Just let me know how I can best help.

[Cliff]

I ended up going another route and just directly recreating most of the template—it was a bit too granular to dive into further just to save some code.

Thanks for your help!

[Cliff]

Even after going through all the steps to not use $post or the tribe_get_template_part() function, the same still happens to me. tribe_get_events() is still getting filtered by custom taxonomy.

[Cliff]

I went that route because it seems to be the only way to use a given template TEC provides. :/

Can I use tribe_get_template_part() with post data assigned to another variable?

[Cliff]

Sure!

“It” is the TEC plugin, somewhere in Query.php. It’s doing the right thing by filtering events in the query to only include those associated with the taxonomy, but it seems to do so well before it’s needed, thus keeping this from working (you’ll see I currently exclude it when the given parameter is set): https://gist.github.com/logoscreative/970d9a18c9bdf0931549

Basically, tribe_get_events() only returns events that are in the given taxonomy, despite me not explicitly requesting that in the query args.

My guess is that it’s happening on line 357 of Query.php, but I could be wrong. Happy to give more details.

[Cliff]

Boom! Perfect. Thank you!

[Author]

Posts