[Barry]

Hi Kevin,

I’m afraid it did not make it (and actually Events Calendar PRO was not included in our last round of updates).

https://gist.github.com/barryhughes/44a277f7472ba633db1ee2ea0f91c60f

You could try the above snippet, which could be added either to a custom plugin (preferred) or else to your theme’s functions.php file.

It might help as a temporary workaround until we do get an official release out (if it doesn’t you can simply remove it and wait on the substantive fix).

Thanks for your patience so far!

[Barry]

Hi Dan,

Thanks for your patience.

https://gist.github.com/barryhughes/1b9b2d48fcaf441c5a6cd62058e67820

The above snippet (which could be added either to a custom plugin (preferred) or else to your theme’s functions.php file) works by detecting a change in order status.

Once an order is set to “refunded” it will identify any attendees associated with the order and delete them. By itself, the snippet does not attempt to handle re-stocking/inventory adjustments but you can ask WooCommerce to handle that side of things.

I hope that helps or at least serves as a starting point for further work on this 🙂

[Barry]

Hi there @ccisatnu,

Apologies first of all for the delay in responding. Unfortunately, this slipped through the cracks.

I realize it’s been a while so possibly you have already resolved this … I also need to highlight that very technical customization questions such as this one are any case somewhat beyond the scope of support we can generally provide.

That said, it does come to mind though that you can alter the queries used to fetch the data returned by the REST API pretty easily:

function modify_rest_request_query( $query ) {
	remove_action( 'tribe_events_pre_get_posts', 'modify_rest_request_query' );
	// @todo modify event query according to meet your needs
}

function listen_for_rest_request( $pass ) {
	add_action( 'tribe_events_pre_get_posts', 'modify_rest_request_query' );
	return $pass;
}

add_filter( 'rest_dispatch_request', 'listen_for_rest_request' );

So, if the REST API is what you want to use, that’s one avenue you could follow. If along the way you identify opportunities for us to make this sort of customization easier, perhaps by adding additional hooks to our own REST API code, do let us know 🙂

[Barry]

Thank you first of all for flagging these problems.

We take security very seriously and are always keen to investigate reports like this one as promptly and thoroughly as we can — so we greatly appreciate you taking the time to share these notes.

I’d respectfully ask in future though that if you encounter anything else like this you approach us privately (by making using of our facilities for creating private topics, or else by using our contact form): proceeding with care and discretion in this sort of scenario is important if we’re to be able to address the problem early and with the least amount of disruption to our user base as possible.

Additionally, before we continue, I want to highlight the following article as a useful resource in situations like this one: codex.wordpress.org/FAQ_My_site_was_hacked

All I have is my hosting company telling me the name of your plugin kept coming up so they sent me the backdoor they opened.

We only know what you’ve shared with us, but as Brian highlighted those specific files are not actually distributed with our plugin. Based on the notes you’ve shared so far, there actually isn’t much evidence of a vulnerability in our code – in fact, very often, the actual ‘bad actor’ will modify other components (such as our plugin, or WordPress itself) rather than draw attention to itself.

That to say, although malicious files/code were added to our plugin (in the context of your site only, just to be super clear), that does not mean it is the source of the vulnerability. If your host or anyone else you’ve been working with has evidence to suggest otherwise then it would be great if they could share it: to that end, if you can put us in touch with them that would be appreciated (and details of any reference numbers for support tickets you might have created on that side could be useful, too).

Hi, I found this thread because my security plugin SecuPress Pro just warned me to delete the Events Calendar Pro due to vulnerabilities. Just checking to see if the team at Modern Tribe has patched it yet, or are working on it?

Hi Regina, thanks for getting in touch.

There’s not quite enough information for us to provide you with a well informed response at this stage. Your screenshot suggests there are specific details you can access (by following the link in the warning message) … are you able to do that and share further screenshots of what you see there?

I do want to be clear that, at this time and to the best of our knowledge, there are no known vulnerabilities in our plugins. False positives can and do crop up now and again however because security plugins and scanners, like any pieces of software, can get things wrong.

Last but not least, I want to be transparent that I am changing the title and URL for this converation. I’ll reach out to you both by email to ensure you have the updated URL, so you can continue to track things and add updates, but I felt this was an important change to make because the original topic title was somewhat alarmist and implied a situation that isn’t necessarily true.

Thanks again and please don’t hesitate to let us know if you have further details that might be helpful here.

[Barry]

This reply is private.

[Barry]

Sorry to hear you were also impacted by this, but I do appreciate you sharing that workaround. As before, we’ll be sure to update you both as soon as the fix is deployed 🙂

[Barry]

I can’t guarantee anything, as it can sometimes happen that issues emerge forcing us to delay the release of certain pieces of work. However, in the best case scenario the required change will be deployed within approximately the next week.

Again, I’d emphasize that is not a “definite” 🙂

[Barry]

Hi @theamua,

I’m really sorry to hear this and wanted to pop by and see if I could help further (Jaime is out this week, though will be back soon).

Please check the site again.

I did and can see the problem you are describing, but at least initially I cannot replicate the same thing locally. I’ve got a few questions for you that might help to develop our picture of the problem:

• Were these particular tickets created before you upgraded to 4.7? Have you noticed if the same problem occurs with any new tickets created after that point?
• What are the stock settings for those tickets (for example, are they “shared capacity” or something else?
• Have any refunds been processed in relation to any ticket orders?

Additionally, if you were happy to provide a database dump (plugins like Duplicator provide one pretty easy way of doing this and often a web host will be happy to provide the same) and are happy to share it, I’d definitely be interested in taking a look – this might give us the insights we need.

Note that database dumps/the output of Duplicator is often pretty large in size, so it may be best to upload to a service such as Google Drive or Dropbox in the first instance and share a link with us via a private reply.

Can I just get a refund? I’ve tried those things, and I’m not changing my theme to accommodate this plugin.

We’d really love to work with you to resolve this, but if you do prefer to request a refund you can apply for one via the form on this page.

You are outside of our 30-day refund window, but we may be able to make an exception in this case (please do reference this topic in your refund application so that the team have the right context).

Thanks!

[Barry]

Excellent — glad we could help 🙂

I’ll go ahead and close this topic, but of course please don’t hesitate to open new ones as required should we be able to assist with anything else.

[Barry]

My apologies: Jaime is out this week and though I replied to you yesterday, that post seems to have disappeared into the void.

In short, though, there is a bug within our Event Aggregator service that appears to be behind this problem. The team are aware and are already working on the fix, we just didn’t initially connect the dots and join up what you are reporting with that piece of work.

That’s now happened and as soon as the fix has been deployed we’ll be sure to update you from within this conversation.

[Barry]

This reply is private.

[Barry]

I’m curious: if you visit WordPress’s General Settings screen, what is the Time Format currently set to?

[Barry]

OK, I’ll look out for your update 🙂

This doesn’t seem to be a widespread problem, nor can we replicate it – so it certainly has all the hallmarks of being a conflict of some kind.

theeventscalendar.com/knowledgebase/testing-for-conflicts

One other thing you might look into: occasionally strange caching issues have caused Javascript problems that are hard to pin down, because older versions of Javascript files are served to some or all visitors even when they shouldn’t be.

To that end, if you use caching plugins or if your hosting provider offers caching at their level, try clearing it. Ditto if you use a service such as CloudFlare … try wiping the cache (in the case of some services, it may be there is a delay before this takes effect).

[Barry]

Hi AJ,

I think I understand what you mean.

It’s worth noting that the calendar purposefully does not do this by default and, to that end, making it happen would require some small amount of custom code to be put in place.

In general we’re limited as to how far we can go with requests like that, but I’d be happy to offer you a possible starting point:

add_filter( 'posts_where', function( $sql, $query ) {
	global $wpdb;

	if ( 'list' !== $query->get( 'eventDisplay' ) ) {
		return $sql;
	}

	$start_field = "{$wpdb->postmeta}.meta_value";
	$start_date  = esc_sql( $query->get( 'start_date' ) );

	return "$sql AND $start_field > '$start_date' ";
}, 1000, 2 );

The above snippet could be added either to a custom plugin (preferred) or else to your theme’s functions.php file and should do what you want, but note that:

• It only targets the upcoming list view
• It is not extensively tested, so I’d recommend some testing before rolling out on your live site

I hope that helps 🙂

[Barry]

Sorry for the delay, @baypromtoeam — Jaime is out this week and we weren’t able to get back to you before now.

Looking at your system information (you may by now have reconfigured things, however) it looks like within the Events ‣ Settings ‣ Imports screen you have configured an import date range limit of 72hrs, which is pretty conservative.

Is that still in place and could you try limiting by the number of events instead, setting it to something suitably high (perhaps 300 to start)?

Let me know if that helps with this 🙂

[Author]

Posts