[Barry]

Thanks for your patience so far, Huiwen.

I also owe you an apology: on asking you to check the WooCommerce error logs I had missed a key step, so let’s try that again.

• We need to add a small snippet of code to enable debugging
• This can be done by creating a small, standalone plugin (or a ‘must use’ plugin) or else you could add it to your theme’s functions.php file – let me know if you need further assistance on that count
• The snippet itself is just one line of PHP code (note the double underscore in __return_true):

add_filter( 'tribe_community_tickets_woocommerce_paypal_debug', '__return_true' );

With that in place, please go ahead and try things out again. I’m going to assume you will receive the same result, but this time if you visit WooCommerce → System Status → Logs you will hopefully be able to retrieve some useful data:

• You should see a dropdown in the top right hand side of the screen
• Select the most recent log file with a name that begins with tribe-paypal-adaptive-payments-…
• Click view

This will hopefully provide more insights into the specific problem you are facing – please copy and paste what you find and share it here (by private reply, please).

Thanks again!

[Barry]

Thanks!

Could you additionally share the system information provided by The Events Calendar, as described in the following knowledgebase article?

theeventscalendar.com/knowledgebase/sharing-sys-info

(The information you shared in your last reply appears to be debug information provided by WooCommerce.)

[Barry]

Thanks for clarifying. In that case, I’d love some more information:

• How are split payments configured in terms of the type and size of fee? (Please refer to the settings in Events → Settings → Community → Community Tickets → Per-Ticket Fee Type for this)
• Are you positive that the community organizers had registered valid email addresses that were linked to their PayPal accounts? (They typically would do this via example.com/events/community/payment-options)
• After problems like you described occur, are any error messages being recorded within WooCommerce → System Status → Logs and could you share them if so?
• Additionally, it may be useful if you could share your System Information (which can be found in the Events → Help screen – please remember to mark your reply as ‘private’ to prevent others from seeing this information)

Thanks for your patience while we look into this 🙂

[Barry]

Hi Huiwen,

Community Tickets actually requires WooCommerce to be activated – along with Event Tickets Plus, Event Tickets, The Events Calendar and Community Events.

theeventscalendar.com/knowledgebase/new-user-primer-community-tickets

In the case of WooCommerce, the reason for this requirement is that our payment adapter (which facilitates split payments) works by building on top of facilities provided by WooCommerce itself. Without WooCommerce and the other plugins I listed Community Tickets simply won’t work as expected.

So, right now, you would need to follow the instructions in the New User Primer linked to above and meet all of the requirements detailed there.

I hope that helps!

[Barry]

Hi there Huiwen,

I’m sorry to hear you’ve hit up against difficulties. A few questions/thoughts:

• Did you do any sandbox-based testing and did you have positive results at that stage?
• Can you confirm that you are indeed using a Rest API App (in terms of what you registered with PayPal)? We’ve found in the past that people have sometimes registered for other types of account and that can lead to problems like this
• Is WooCommerce’s own PayPal gateway also enabled?

Thanks!

[Barry]

I do apologize, Mike: I completely misread. With my local configuration corrected to match your own, I do indeed see this problem – I’ll get this logged and we’ll look at addressing this in an upcoming release.

[Barry]

Thanks, Robert.

I don’t find anything like as clear a correlation in my own testing: the total number of queries and time spent processing them is remarkably similar (for month view) between our final 4.2.x releases and our current 4.3.1.1 releases.

That doesn’t mean there isn’t a problem of course, just that I may lack the necessary test data to see it. With that in mind, would you be able to share a database dump with us?

If you’re happy to do so please either attach it to your next reply or if it is too big to upload here then you could host it elsewhere and supply a link instead.

Thanks for your continued assistance here 🙂

[Barry]

Hi Mike!

I hope you don’t mind me jumping in here however Nico is largely unavailable today and we didn’t want to leave you waiting.

Weirdly, I cannot replicate the same set of problems on a site running the latest versions of our plugins and where, as you have done, FORCE_SSL_ADMIN is true and https:// is specified in both the site and home URL settings.

I actually couldn’t find a single instance of an asset being referenced over straight HTTP (and I checked the general event settings screen and a few other settings screens, plus the main admin events list and of course the event editor). So there does seem to be a bit of a discrepancy here in terms of what we’re both experiencing and I’m admittedly unsure what would be behind that.

I realize you probably don’t want to revert to a situation where these problems crop up again, but if you were able to temporarily do so and itemize some of the scripts/stylesheets that are being flagged up that would be really helpful here.

Thanks so much for your help on this one!

[Barry]

Hi Robert,

I understand your frustration and you can of course manually rollback to older versions as an alternative to sticking with the current release.

Our own downloads page contains any previous versions of the plugin your license allowed access to and all historic versions of The Events Calendar itself are available over here.

While you’re free to follow that path we don’t currently feel there is a need to issue any kind of general roll-back. It’s true you aren’t the only user voicing performance concerns but we haven’t yet conclusively determined that this was something introduced by our 4.3 release, nor does it currently appear to be something that impacts the majority of our users.

We have a very large number of users to take care of and that of course means we need to proceed carefully and in the interests of everyone.

Naturally, we will continue to monitor this situation closely.

[Barry]

Thanks for locating that information!

Unfortunately that doesn’t seem to be a positive lead. What I’ve done, at this point, is link this support topic to our internal bug tracker (specifically to an issue logged about performance issues) and I have also increased the priority of that same bug report.

You already have page caching in effect (and I would additionally recommend you enable month view caching, if you haven’t already done so): beyond that the only further short term strategies I can offer until we implement changes in the code would include:

• Regular pruning of expired events
• Database level query caching (see here)
• Object caching (see here for a high level summary)

It’s possible you already have those items in place, of course, but I felt it was worth summarizing as it’s not uncommon for sites to use a caching plugin but only take advantage of static page caching.

Beyond that, we will of course do our best to update this topic as and when we progress the linked bug report.

[Barry]

Hi!

Most of these problems started after the last update, prior to that I never had problems with the page taking this long to load even when logged in.

Interesting. Perhaps we’re looking in the wrong area in that case?

Via Query Monitor, do you notice if any HTTP requests are taking place when our views are being loaded, particularly if they seem to be triggered by our plugins? (To be clear, I only mean HTTP requests between your server and another server, as listed by Query Monitor, and not the normal flow of HTTP requests issued by your browser).

Also, unrelated but something I noticed since the last login is the lines on the calendar are wacky and often either disappear or don’t extend fully to the top, attached are two screenshots from different browsers one using the default theme.

That is a little odd.

As it’s not related to the core performance issue, however, would you mind creating a fresh support thread for this? One of the team will then be only too happy to help.

[Barry]

Thanks!

The site loads pretty snappily for me but that is probably due to page caching.

My guess is you are mostly hitting this problem when you are logged in (and that, as is often the case, caching is disabled for authenticated users). If I’m correct, that means this is mostly a problem for just a subset of the site’s users – ie, those who are logged in – and generally it will not impact casual visitors who are not logged in.

The slow queries you shared have the hallmarks of those used to build both the full calendar month view and also the calendar widget. We’re aware that there is room for further optimization here and already have this on our issue tracker: while I can’t commit to exactly when that work will take place, do know that it is on our radar.

Last but not least, it looks like you haven’t enabled month view caching (via Events → Settings → Display): while enabling this unfortunately will not currently help to reduce load on pages utilizing the calendar widget, it will help to reduce load in relation to the full calendar month view and so is worth considering.

If this continues to be a major painpoint for you, it might be worth temporarily removing the event calendar widget from your sidebars until we can implement changes to our month view queries in a future release.

If you have further questions, please don’t hesitate to let me know.

[Barry]

Hi Robert,

I’m sorry to hear that your site hasn’t been performing optimally.

Let’s get started by running through the specific errors you highlighted and we can take things from there:

(Suppressed) opendir(/xxxx/xxxx/xxxxl/wp-content/plugins/event-aggregator): failed to open dir: No such file or directory

Note that Query Monitor has marked this error as “suppressed”. In other words, were it not for Query Monitor, this would not be flagged up and it is pretty much a false positive that we don’t need to be too concerned about.

Strict (Suppressed) call_user_func_array() expects parameter 1 to be a valid callback, non-static method WP_Feed_Cache::create() should not be called statically

Again this is a “suppressed” error that is only showing because Query Monitor is trying to be helpful – this particular error is also unrelated to our own code (rather it’s the result of core WordPress code).

Notice (Suppressed) unserialize(): Error at offset 39269 of 90888 bytes

This one is potentially a little more worrying, though the fact it has also been suppressed suggests the authors of the code were aware it might not work. That said, it’s hard to offer too many insights without knowing where exactly the problem is coming from.

For each error, Query Monitor usually offers a “trace” of different files which can help point us toward the source of issues like this – is that something you can share with us, perhaps by screenshotting Query Monitor’s output?

Performance

None of the above seem to directly relate to performance, which seems to be your chief concern. I’d like to learn more about this:

• Approximately how many events do you have? How many (if any) are recurring?
• Did performance suddenly take a nose dive (if so, when did it start?), or has it been a gradual progression?
• Can you tell me more about your hosting environment and roughly how much traffic you receive?

Thanks!

[Barry]

Hi Matthew,

I’m sorry to hear you’ve hit up against some problems.

I can’t actually replicate the problem so we’ll need to gather a little more information. If you are comfortable doing so, could you enable WP_DEBUG mode by adding the following snippet to your wp-config.php file:

define( 'WP_DEBUG', true );

If you’re unsure about the correct place to add this, do check out this codex article. With that done, can you return to the order screen: are any errors displayed and can you quote them/screenshot them if so?

Feel free to undo your change to wp-config.php once you’ve finished testing.

Thanks so much!

[Barry]

Hi Vic,

Up-voting the existing feature request was definitely the best course of action here. Beyond that I’m afraid there’s not too much more we can offer right at this time (except for Filter Bar, though as you’ve noted that could be overkill for this particular scenario).

Your request is certainly a valid one and we’re aware that a number of customers would like to see improvements and changes to the way tags are used in relation to events.

Unfortunately, a snippet-based approach to achieving your goals – while possible – is on this occasion beyond what we can provide here in the support forums, owing to the complexity of such a solution.

Thank you for highlighting this issue, though, and for taking the time to up-vote it.

[Author]

Posts