[Cliff]

Hi, Cynthia.

This is a bug with WordPress core: https://core.trac.wordpress.org/ticket/40293

Please keep an eye on it there.

To make the error not happen until that bug is fixed, I’d recommend unchecking the box or changing its value to something other than zero: https://core.trac.wordpress.org/attachment/ticket/40293/40293-how-to-reproduce-divide-by-zero.jpg

Please let me know if you have any follow-up questions on this topic.

[Cliff]

Hi, Iván. Thanks for your interest in our plugin suite.

Our Filter Bar add-on is perfect for this, whether or not you have our Events Calendar PRO add-on in addition.

You can see Filter Bar in action at our demo site: http://wpshindig.com/events/

Last but not least, we have a pretty great Refund Policy so you can buy one or many of our add-ons and thoroughly test them.

I hope this info helps. Let me know if you have any follow-up questions.

[Cliff]

Hi, Jason.

I’m glad you got this sorted out. Thanks for letting us know.

Enjoy WP Engine!

[Cliff]

Thanks for your effort here. I’ll await your reply, but, in the meantime, this article may be helpful: https://theeventscalendar.com/knowledgebase/using-one-license-live-dev-sites/

[Cliff]

If we were to dequeue our Select2 only while using the Customizer, do you think that would solve the issue?

Or is this issue happening outside the Customizer somewhere, too?

[Cliff]

It will require code changes to both our EA server and the EA client that’s bundled into The Events Calendar… so there’s no code snippet to do this at this time. I’ve passed along your request for timeliness on this.

[Cliff]

Thanks for your patience.

After investigating your database, it looks like your events were imported prior to our releasing a fix for author of zero and empty post_content. Additionally, we added even more robust protection against this happening just now.

We put together a plugin for you to try out in your staging environment (of course, we always recommend restorable database and file backups before modifying anything on your production or staging site): https://cl.ly/3b3p0G0p2F2N

It should find all the duplicates, based on the imported iCal event’s UID. All you do is activate the plugin (again, in your staging/testing site first), and it’ll delete the duplicates in batches (so it doesn’t bring down your site). Then see if its deletions look legit. If yes, do the same to your actual production site.

Then, going forward, Event Aggregator should be able to pick up where you left off — for future events — including filling in any missing information (Event Description or otherwise).

===

An alternative method is to wipe out all events — especially if they were all created via EA import and none were created via manual entry in wp-admin — and then just let EA do its thing going forward, since our current code shouldn’t be creating duplicates (since September).

Please thoroughly review these options and get back to me with any thoughts, questions, or report back how things worked for you.

I’m looking forward to hearing back from you.

[Cliff]

Thanks for your patience.

After investigating another user’s database, it looks like duplicates were created by imports from September or earlier, which would line up with the fix we pushed out in September to address this bug.

We put together a plugin for you to try out in your staging environment (of course, we always recommend restorable database and file backups before modifying anything on your production or staging site): https://cl.ly/3b3p0G0p2F2N

It should find all the duplicates, based on the imported iCal event’s UID. All you do is activate the plugin (again, in your staging/testing site first), and it’ll delete the duplicates in batches (so it doesn’t bring down your site). Then see if its deletions look legit. If yes, do the same to your actual production site.

Then, going forward, Event Aggregator should be able to pick up where you left off — for future events — including filling in any missing information (Event Description or otherwise).

===

An alternative method is to wipe out all events — especially if they were all created via EA import and none were created via manual entry in wp-admin — and then just let EA do its thing going forward, since our current code shouldn’t be creating duplicates (since September).

Please thoroughly review these options and get back to me with any thoughts, questions, or report back how things worked for you.

I’m looking forward to hearing back from you.

[Cliff]

Thanks for your patience.

After investigating another user’s database, it looks like duplicates were created by imports from September or earlier, which would line up with the fix we pushed out in September to address this bug.

We put together a plugin for you to try out in your staging environment (of course, we always recommend restorable database and file backups before modifying anything on your production or staging site): https://cl.ly/3b3p0G0p2F2N

It should find all the duplicates, based on the imported iCal event’s UID. All you do is activate the plugin (again, in your staging/testing site first), and it’ll delete the duplicates in batches (so it doesn’t bring down your site). Then see if its deletions look legit. If yes, do the same to your actual production site.

Then, going forward, Event Aggregator should be able to pick up where you left off — for future events — including filling in any missing information (Event Description or otherwise).

===

An alternative method is to wipe out all events — especially if they were all created via EA import and none were created via manual entry in wp-admin — and then just let EA do its thing going forward, since our current code shouldn’t be creating duplicates (since September).

Please thoroughly review these options and get back to me with any thoughts, questions, or report back how things worked for you.

I’m looking forward to hearing back from you.

[Cliff]

Here’s the database postmeta table for one of your upcoming events: https://cl.ly/0D1O2v0K0t2G

Notice the _EventEndDateUTC field is the only one on Saturday, November 25, which is why this event is appearing on both the Friday and Saturday filters.

I marked this thread as Pending Fix, which means it should receive a reply once the applicable fix has been released. I cannot guarantee when it will be fixed as it’s in the development team’s hands now. They need to assign it, code it, test it, and schedule it for release.

I apologize for this issue and appreciate your understanding and patience.

[Cliff]

Looks like we posted at the same time. 🙂 Please read my previous reply and get back to me.

[Cliff]

That screenshot gives the URL to CSS files but not JS files.

Either way, yes, I’d guess there’s a conflict. We have it on our to-do list to transition to the latest version or its successor, SelectWoo.

At this point, I’d say it’s just a conflict between our plugin and their theme.

It might be weeks or months before we complete this transition, as it’s a large to-do.

If we were to dequeue our Select2 only while using the Customizer, do you think that would solve the issue?

I marked this thread as Pending Fix, which means it should receive a reply once the applicable fix has been released. I cannot guarantee when it will be fixed as it’s in the development team’s hands now.

I apologize for this issue and appreciate your understanding and patience.

[Cliff]

Sure thing. We can’t take zip files here, but you could share a link to Dropbox, Cloud App, Google Drive, etc.

[Cliff]

Awesome! And thanks for letting us know 🙂

[Cliff]

Hi, Matteo. It looks like that other thread experienced some conflicts with either displaying a recurring event in a slider or a general conflict with WPML or its settings.

Might either of those two situations be applicable in your case?

[Author]

Posts