[Barry]

Thanks Rudolf, I’ve reported this and we’ll hopefully get a fix in place in a future release 🙂

[Barry]

Hi Carl,

It looks like you are using Events Calendar PRO in addition to Community Events – so perhaps you could use a new additional field for this purpose?

Beyond that it is certainly possible to do a more involved customization. The following knowledgebase resources don’t explicitly cover the scenario you have described – but they should certainly arm you with a lot of the necessary background knowledge:

• theeventscalendar.com/knowledgebase-category/customizing-community-events
• theeventscalendar.com/knowledgebase/themers-guide

Does that help?

[Barry]

Ah, I see.

So the snippet actually does its job as expected, best I can tell – which is to remove a particular category of events from the general month view.

If I’m understanding you correctly you want this also to impact the “events and activities” section of your site’s homepage – but this is not month view (and actually it does not even look like one of our own widgets).

Is this section of your homepage something you custom built, or something that shipped with your theme perhaps?

[Barry]

I do apologize, Rupert, you are of course absolutely correct.

The same kind of mechanisms that exist in WooCommerce Tickets and EDD Tickets aren’t actually present in the case of Shopp Tickets – but we can probably do something to help even so. Can you try adding this snippet (for instance, to your theme’s functions.php file)?

add_filter( 'wp_mail', 'stop_shopptickets_emails' );

function stop_shopptickets_emails( $atts ) {
	// Safety check
	if ( ! function_exists( 'shopp_setting' ) ) return $atts;
	
	// This is the email we're looking for
	$expected_subject = apply_filters( 'shopptickets_ticket_email_subject',
		sprintf( __( 'Your tickets from %s', 'tribe-shopptickets' ), shopp_setting( 'business_name' ) ) );

	// If it's not the one, let it go out
	if ( $expected_subject !== $atts['subject'] ) return $atts;

	// Cludge to stop the email from sending
	$atts['to'] = '';
	return $atts;
}

Does that help?

[Barry]

Hi Andy,

The important thing is that your site is operating normally, so that’s great to hear 🙂

Are there any known issues that the helper plugin may cause? I just checked some of my other manually created redirects and they all still seem to be working. Just wanted to know if there were any potential issues I should look out for.

None I’m aware of, but actually this is a brand new approach to dealing with the results of this conflict — it may be helpful to others that have similarly been impacted by Series Engine, but you are the first to try it “for real”.

Just to confirm, even when I disabled the Series Engine plugin previously it would not have corrected the problem correct?

Correct – this is the sort of conflict where the damage is done when events (recurring events, in this case) are created – deactivating Series Engine won’t reverse those changes. On the other hand, deactivating it will allow you to generate new, undamaged recurring events 🙂

[Barry]

…One other thing to try, especially if you’re in agreement with my theory re Series Engine, is installing this lightweight helper plugin. Once you’ve uploaded it to your WordPress site you should see it in the list of plugins as The Events Calendar: Recurrence 404 Fallback.

Though I can offer no guarantees, I think it may help you (and your visitors!) to access those recurring events that have already been damaged.

[Barry]

Andy:

Apologies first of all because I completely missed an important detail when you initially posted your system information.

It looks like you have been using Series Engine: this is a known source of conflicts with Events Calendar PRO which can trigger the very problem with recurring events that you are currently experiencing and, if you deactivate Series Engine and generate a fresh series of events, you will probably find those new events are completely unaffected (of course, if you find that’s not so – just let me know!).

The problem with Series Engine is this: WordPress sets the default timezone to UTC and this lets it reliably perform time-based calculations using a system of offsets. Series Engine can and does override this setting under some circumstances and the long and short of this is that when a series of recurring events are generated, the date and time information associated with each can be set incorrectly.

So, as initially suspected, this is essentially the result of a plugin conflict albeit one that can’t be rectified for those events that have already been impacted simply by turning off Series Engine (though that will allow new recurring events to be successfully generated).

Before I go any further I’d like to confirm that my theory is correct: can you now deactivate Series Engine, create a new set of recurring events, and test to see if they function as expected? Once you’ve performed that test, please do feel free to reactivate Series Engine.

[Barry]

Thanks, Andy.

Firstly, yes: I can assure you the information you provided will only be used to track down the problem at hand and we’ll then wipe our local copy of the db and any of the source files you provided.

I have in fact already been able to replicate the problem locally and on a clean installation. While I don’t have an answer for you just yet I hope to update you again shortly once I’ve had more time to investigate.

Thanks again – I hope to get back to you tomorrow at the latest.

[Barry]

Hi Davin,

Unfortunately those URLs do not resolve/time out when I try to access them.

The events from my category are still showing on my home page.

So do you mean your main events page, rather than the blog homepage? It could be worth switching to the tribe_events_pre_get_posts action here.

Then when I get to day view and click another event it jumps from

http://wptest.vetmed.auburn.edu/events/category/src-events/

to

http://wptest.vetmed.auburn.edu/event/society-of-physics-students/

I’m not sure I fully understand the problem, here. Is that final URL not the address of the event you are clicking on?

[Barry]

Hi nothingtodo,

They’re stored in the database rather than in the file system – so I’m afraid going in by FTP isn’t going to be the solution here.

[Barry]

Yes – that should be all I need – since you noted the problem still occurs even with no other plugins but our own running it should make it possible for me to replicate things locally 🙂

[Barry]

That’s possible, too, though it sounds like the issue still stems from another plugin modifying the query (and only on the initial load, not when it is updated via ajax).

[Barry]

Great – and I do wish we could help more with the sharing buttons side of life, but there are so many plugins out there we just can’t offer advice for them all, I’m afraid.

In any case I hope that snippet helps with at least part of the task 🙂

[Barry]

Thanks!

So unless I’m missing something, neither of the plugins you purchased from us (Eventbrite and WooCommerce Tickets) are listed there. Are you certain you installed them/uploaded them correctly?

[Barry]

When the view is loaded initially WordPress will run its main query as usual (and in this case it will of course look for events rather than blog posts).

My guess is that this other plugin interferes with and changes the query whenever it detects that it is the main query (and there is only ever one “main query” in any request).

When you hit Find Events, though, the work happens via an ajax request. Effectively the same query – or something very similar – still runs but it isn’t “labelled” as the main query – and so perhaps Ultimate Member decides not to interfere with it for that reason.

If it works with hitting the button, can’t the regular query be modified in the same way?

We’d really need to twist things to make that happen and it probably wouldn’t be a particularly efficient or maintainable way to approach this problem.

The way it looks, the problem is that the other plugin is modifying a query that it has no business changing – and if that’s correct, the best way to tackle this is to stop it from doing so.

[Author]

Posts