[Jon Chabun]

Also: has anyone looked at the issue that started this thread (recurring event exclusions are no longer being respected)?

[Jon Chabun]

Hi Brook,

I appreciate the offer of a refund, but the site is completely dependent upon the plugin, with no budget to build a custom system, so we still need an active license. If you wanted to extend an olive branch, I’m sure my client would appreciate an extra year of licensing – they’ve been pretty patient with me as we worked through the issues, but they’re not happy and I don’t blame them.

[Jon Chabun]

My developer’s on Xmas holidays already, so no – not much I can retrieve at the moment – and I’m starting hols as well so I’ll have to circle back to this in January. However, I was able to find a workaround of sorts – partly thanks to Abigail’s discussion of permalinks: First, I globally set the post timezones to ‘use local timezone for each event’. This fixed a few of the rogue events, but not all (no idea why this should matter, but at least it worked). Then I went to each event that was still giving us trouble and manually altered the permalink for each one, which fixed those.

I can see this could easily start happening again as the client creates new events, but for the moment this gets us through the holidays with the currently-published events.

[Jon Chabun]

I see in the readme file that there is a line under the 3.6 updates (line 766):

* Fixed an incorrect redirect when visiting an event with the wrong date in the URL

Can you tell us where that issue was in the source so we can take a look and see if that’s causing our problem?

[Jon Chabun]

I’m still waiting for a reply.

I’ve been doing more testing on my own and discovered that the problem seems to be related to start time – all of the problematic events (so far as I’ve tested – we have over 500) begin at 6 or 6:30 pm. When I change their start times to something else (I’ve tried 1:30pm and 8:30 am), the redirect loop no longer occurs. As soon as I change it back to the correct time, it loops again.

I urgently need to get this fixed; currently about a third of our events are not accessible to users.

[Jon Chabun]

Hi Brook,

I do appreciate what goes into building good software – I worked for a software company for 4 years.

Our host auto-updated before I could vet the new version. My frustration just got the better of me.

Still, I think my expectations with paid software are for more rapid responses from tech support – when it’s a critical piece of a major client install, we’re the ones the client looks to for answers, and ‘we’re waiting for a response from someone else’ is hard to sell, and waiting a full day in between responses (which may come late at night, further adding to the delay) is seriously frustrating. I suggest some kind of escalation protocol that can include real-time chat or something – even if that’s another $100 add-on…

Matt

[Jon Chabun]

This reply is private.

[Jon Chabun]

Rolling back to 3.x on its own didn’t solve this problem, but rolling back and then changing the time zone back to Vancouver (after we’d changed them all manually to Los Angeles as per this thread: https://theeventscalendar.com/support/forums/topic/event-times-changed-now-all-incorrect/) resolved this problem (for now). But this is getting a bit much – I’m spending hours and hours of time I can’t charge my client for to try and resolve this. Not cool.

[Jon Chabun]

We had to roll back to the last of the 3.x series to fix the other problems, but the redirection issue is still happening. So for this event: http://esquimaltmfrc.com/event/away-cafe/2015-12-16/ it goes instead to http://esquimaltmfrc.com/event/away-cafe/all/

Here are the settings for that event:
oculusdesign.ca/Clients/MFRC/Redirection-RecurrenceSettings-01.png

[Jon Chabun]

We’re using version 4.0 of each plugin.

It seems to be sporadic.

What is the best way to send you screengrabs?

Thanks for your time and attention.

[Jon Chabun]

Hi There,

I think we are having a similar issue. It would appear that the links for specific events are also redirected to /all in some cases, and the permalinks for any particular event in a recurring event set are inaccessible. Does it sound like this is the same thing?

Please advise if/when this issue is resolved. Thanks!

[Jon Chabun]

That didn’t work either, but it looks like this did:

<?php
add_action( 'parse_query', 'tribe_fix_tag_query' );
function tribe_fix_tag_query( $query ) {
	if ( $query->is_tag && (array) $query->get( 'post_type' ) != array( Tribe__Events__MAIN::POSTTYPE ) ) {
		if ( empty( $query->query_vars['post_type'] ) ) {
			$query->query_vars['post_type'] = array( 'post' );
		}
		if ( ! ( $query->query_vars['post_type'] == array( 'post' ) || $query->query_vars == 'post' ) ) {
			remove_action( 'parse_query', array( 'Tribe__Events__Query', 'parse_query' ), 50 );
			remove_action( 'pre_get_posts', array( 'Tribe__Events__Query', 'pre_get_posts' ), 50 );
		}
	}
}
?>

Do you see any problem with referencing Tribe__Events__MAIN::POSTTYPE instead of Tribe__Events::POSTTYPE? Is there anything in particular we should test to see if that would break something?

Cheers,

Mike

• This reply was modified 10 years, 5 months ago by Jon Chabun.

[Jon Chabun]

Nevermind – it’s working now – perhaps it was the CDN acting up. Will advise if we have any further issues.

Cheers,

Mike

[Jon Chabun]

Absolutely! Thank you for looking: http://mfrc.yourdevsite.ca/events/

• This reply was modified 10 years, 5 months ago by Jon Chabun.

[Jon Chabun]

Hi Geoff,

I think that’s probably close, but I get the following error message on that page with that snippet in our functions file:

Fatal error: Class ‘Tribe_Events’ not found in /Users/mikelathrop/Dropbox/1work/www/mfrc/wp-content/themes/bms-barebones/inc/custom.inc.php on line 55

In my editor, I see when I highlight Tribe__Events on line 5 of the gist, it wants to autocomplete with a number of other classes that start with Tribe__Events (Tribe__Events__Abstract_Deactivation, Tribe__Events__Activation_Page, etc, etc). Is it just a matter of finding the right class with the POSTTYPE array in it that we’re after?

[Author]

Posts