[Josh]

Hey Herman,

I can’t give a set date for when the fix will be available. We currently in the middle of our QA process for our 4.0 release so the updates are currently locked down for that release. The earliest we can expect a solution for this one will be a maintenance release (4.0.1) which should be available in early December.

Thanks!

[Josh]

Hey Matthew,

No problem. I’ll go ahead and close this thread for now. If you have any further questions, please don’t hesitate to open a new thread.

Thanks!

[Josh]

Hey Jacob,

Sounds good. Let me know if anything comes up in those tests.

Thanks!

[Josh]

Hey Lara,

Thanks for following up. We’ll leave this thread open in case the duplication comes back up.

Keith, thanks for bringing that other thread to our attention here. I’ll ensure that this thread gets included in the conversation around the Facebook duplication issue.

Thanks1

[Josh]

Hey Troy,

It’s possible that there could be a query that is modified that is causing it to require a little more memory than usual, particularly if there are a large number of events in your calendar. However, if it were a significant resource bleed due to the update, we would expect to see a lot more users reporting this similar issue. If you try increasing the limit just to the 512 and the issue persists, it is possible that there might be a configuration issue that we may need to address.

Going forward, I know performance and efficiency will always be continued priorities and to this end I do know that several issues that have been reported on an enterprise level (sites maintaining tens of thousands of events) have already had solutions submitted and included in the next round of releases.

Let me know if this helps.

Thanks!

[Josh]

Hey Frode,

Thanks for reaching out to us!

For the Community Events login, we utilize the “wp_login_form()“. So, if you utilize a social login that will work to replace that form it will replace the default form used in our template.

Let me know if this helps.

Thanks!

[Josh]

Hey Karl,

Thanks for reaching out to us!

It looks like you’re experiencing an issue related to a known bug that we’ve seen with translations and category archives. I’ve added this this support thread to our internal ticket for tracking this issue. You’ll be notified here as we make progress towards a solution.

I apologize for any inconvenience this has caused. Let me know if you have any further questions.

Thanks!

[Josh]

Hey Dirk,

Thanks for reaching out to us!

I just did some testing in my local environment on the latest versions of the plugin and unfortunately wasn’t able to replicate. If you update to the latest versions of the plugin that were released late yesterday, does the issue persist for you?

Thanks!

[Josh]

Hey,

Thanks for reaching out!

Unfortunately I can only send our response to a different email address if the address is changed on the actual account associated with this thread.

As an initial couple of steps for testing:

1. Have you tried the Testing for Conflicts procedures to ensure there isn’t an existing conflict with another plugin or the active theme at play here?
2. When setting up the recurring import, can you ensure that there aren’t any limitations being set on the import that could be preventing the other events from coming over? https://cloudup.com/c3vcXL2D7Kr

Let me know if this helps.

Thanks!

[Josh]

Hey Aaron,

Thanks for reaching out to us!

I definitely understand the frustration here. Based on what I’m looking at for our current schedule, it looks like the update for this issue is tentatively scheduled to be released for early December. I’ve added this thread to our internal ticket for tracking this issue and you’ll be notified here as we make progress on the issue.

I apologize for any inconvenience this has caused. If you have any further questions, please don’t hesitate to reach out.

Thanks!

[Josh]

Hey Courtney,

You can update the content via code but how it displays will be updated using the CSS route.

Thanks!

[Josh]

Hey Herman,

Thanks for doing the tests and following up with us here. I did some further tests and it appears that this is happening with both the beta and current versions of the plugin. I apologize for the inconvenience of this issue.

I’ve created an internal bug ticket for tracking this issue. You’ll be notified here as we make progress on this one.

Thanks!

[Josh]

Hey Jacob,

Thanks for providing the link. It looks like there are a couple of javascript errors in the console preventing the calendar from functioning properly. Have you tried following the Testing for Conflicts procedures to see if you can find the root of the issue?

Thanks!

[Josh]

Hey Troy,

Thanks for reaching out to us!

As an initial step, have you tried following the Testing for Conflicts procedures to ensure there isn’t an issue with other code, particularly try switching to a default theme to see if the issue persists.

A general “solution” for something like this is to increase the memory limit within your server’s php.ini file. You could try increasing it to a 512mb, but any more than that could end up causing whatever the conflicting code is to completely run through the existing memory for the site.

Let me know if this helps.

Thanks!

[Josh]

Hey Matt,

Thanks for reaching out to us!

Doing some further research on the header image on the ticket, it looks like the image ID may be failing to be returned in a previous function within the email template. Will need to do some further tests there to verify.

For the cc / bcc, our emails are just an extended class from the WooCommerce WC_Email class. For that there is some good information here which will show some of the steps/options for adding additional email addresses to the notifications.

Thanks!

[Author]

Posts