Time Out Issue
-
When admin users access reports from the Alpha Insights menu: Sales Reports and then try to access a sub-menu (such as Order Report), the system will sometimes open the report but more frequently it will cause a time out and not open.
We have approx 17,000 published products and a total of around 21000 products in the database. We also have approx 11,500 orders.
Any thoughts on what might be causing the time outs? I don’t see any specific errors in any of the log files.
The page I need help with: [log in to see the link]
-
Hi there,
Thanks for reaching out & using Alpha Insights
It could be many things, but your product count is a very strong lead – our reports build a JSON string of all product Id’s & names as a fallback for some edge cases – i suspect the rendering of 20k product values is causing timeouts, moreso on the DOM rather than the server thus nothing in the error log, but in any case – you can test this by short circuting this function, this is not tested, but try including this snippet in your functions.php
add_action('admin_init', function () {
set_transient(
'wpd_ai_report_filters_products',
[
0 => 'Placeholder (N/A)'
],
DAY_IN_SECONDS
);
});This should bypass this entire process and pass the empty array, rather than 20k product records
If you can give that a go and report back – if this is indeed the issue i’ll look at a system for handling large product databases & release an update in main
Our orders are highly optimized, so I don’t suspect it’s an order related issue, we’ve got user’s with hundreds of thousands of orders
Thanks, Chris
Hi there, just marking this as resolved – please feel free to throw in additional comments if you’re still having issues after implementing the snippet & i’ll assist
Thanks, Chris
We added that code snippet and didn’t see any difference.
Given that, what do you think the next steps are for resolving this?
At this time, Alpha Insights is pretty unusable as we can’t get any reports to open.
Thanks!
Understood, i strongly suspect it’s for the reasons above, the snippet may not have covered it off.
In any sense, i’ll release an update in the coming days that I believe will address the issue – if not back to the drawing board, but we’ll start there.
Speak soon,
Thanks, Chris
Hey Chris – any idea when the update will be released? Thanks!
Hey sorry for the late response been meaning to come aroud to this – we’ve just posted an update v1.6 which includes a few optimisations, one of which relates to what I suspect may be your issue (although might be wrong)
Please update to 1.6 and then give it about 24 hours – there are transients holding parts of the old data format, so they will expire in a day max, and then the new code will be executed
It may or may not help, but let’s start here – if we’re still having issues after this we may need to take this offline so I can have a look inside your admin account area myself to see what exactly the issue is
Hopefully this is helpful,
Thanks, Chris
Hey Chris –
We are using the pro version and I don’t see that there is an update. The latest version appears to be Version 5.5.5. We are still having issues. This is critical as they are about to run month end reports and have issues accessing Alpha Insights.
Thanks,
Debbie
@dlominick Please revoke any admin access to @wpdavies as they made a real mistake and that was bad. Both their are your replies have been archived.
@wpdavies Please reply that you understand and will not repeat that. It is very serious.
While I know you have the best of intentions, it’s forum policy that you not ask users for admin or server access. Users on the forums aren’t your customers, they’re your open source collaborators, and requesting that kind of access can put you and them at high risk.
If they are paying customers (such as people who bought a premium service/product from you) then by all means, direct them to your official customer support system. But in all other cases, you need to help them here on the forums.
Thankfully are other ways to get information you need:
- Ask the user to install the Health Check plugin and get the data that way.
- Ask for a link to the http://pastebin.com/ or https://gist.github.com log of the user’s web server error log.
- Ask the user to create and post a link to their phpinfo(); output.
- Walk the user through enabling WP_DEBUG and how to log that output to a file and how to share that file.
- Walk the user through basic troubleshooting steps such and disabling all other plugins, clear their cache and cookies and try again (the Health Check plugin can do this without impacting any site visitors).
- Ask the user for the step-by-step directions on how they can reproduce the problem.
You get the idea.
We know volunteer support is not easy, and this guideline can feel needlessly restrictive. It’s actually there to protect you as much as end users. Should their site be hacked or have any issues after you accessed it, you could be held legally liable for damages. In addition, it’s difficult for end users to know the difference between helpful developers and people with malicious intentions. Because of that, we rely on plugin developers and long-standing volunteers (like you) to help us and uphold this particular guideline.
When you help users here and in public, you also help the next person with the same problem. They’ll be able to read the debugging and solution and educate themselves. That’s how we get the next generation of developers.
@moderator Yes, understood, my apologies I was not aware
You must be logged in to reply to this topic.