Hello Tainacan Support Team,
I need urgent help. All background processes on my site appear to be stuck indefinitely.
I am experiencing the following issues:
When I try to delete items from a collection, the deletion process starts but never completes.
When importing items, the import reaches the final step and redirects to the processing page, but the process remains stuck forever.
Troubleshooting already attempted:
Disabled and re-enabled the Tainacan plugin
Cleared cache multiple times
Restarted processes several times
Unfortunately, none of these steps resolved the issue.
Additional information:
The site is hosted on WP Engine.
This issue is affecting both item deletion and item import processes.
I have 7000+ items from all the collection and i am going to more 9000+ items very soon.
Please help me identify the cause and resolve this as soon as possible.
Hi @vishalmori . Iâve had that same issue in the past and it was some sort of incompatibility between nginx and tainacan.
Here is the whole discussion:
The solution was to change from Nginx to Apache. everything else was kept the same.
Another possibility is that your cron jobs are not running since every bg process uses it on Tainacan.
There is a plugin called WP Crontrol that can display and show the WP cron processes. If they are overdue, they will also show that. And, if they are overdue, that is likely your cause. you can try running them manually from there, but mostly you must fix the WP Cron.
That is a recurring error and unfortunately it is a bit hard to debug since it depends a lot on server-side settings. First, could you check in your âWordPress Admin â Tools â Health checkâ if there are any issues related to Loopback or background processes stuck?
From there, one way that sometimes people can overcome this is to install WP Crontrol and use to force the execution of Tainacan-related cron jobs (they often are listed starting with a âtnc_â). If that does not solves, clearing transients may help as well.
Thanks for the quick reply. I was unable to respond earlier due to workload.
I tried the following solutions:
Checked the Site Health status, but no issues were found.
Used the WP Crontrol tool to manually execute cron jobs starting with âtnc-â, but the issue still persists.
Switching from Nginx to Apache is not possible on WP Engine.
I also used the âTransients Managerâ plugin to clear transients. While reviewing additional discussion threads, I found several users mentioning this approach as a possible solution.
@marvila you are right. I tested it on my local environment using an Apache server, and it worked successfully.
This was working until April 16.
I hope there is another possible solution for this.
I have found no way to overcome this nginx/apache solution so far.
Through several months trying to make Tainacan work with bulk editing, I have tried everything I could related to memory, fast-cgi and whatnot configuration of Nginx without avail.
Finally it occurred to me to try on a different environment and it worked. The main difference: Apache vs Nginx.
Then I just installed standard apache on the server and it worked.
I still think there must be an Nginx config that could make Tainacan bg process to work, but I havenât had the time to investigate it further. Nonetheless, even if there is such config, I doubt that WP Engine you will make those changes for you
Right now, I have no other ideas to investigate on this matter
If you find any new information, please bring it on, maybe thatâs the click we need to find the solution.
If anyone else is facing the same issue while hosting their site on WP Engine, you may want to try again after disabling this protection setting for your site:
Hey @vishalmori that is a nice and curious discovery. I wonder if the Password protection feature could be somehow affecting the Loopback requests that are done by the cron job to check the background processing status. Because that is something that happens in Cloudflare. But at least your System check did not mention thatâŠ
In my case, my customerâs environment was behind a firewall (only accessible inside their netowork), but that same env worked with Apache. On my local env, it also failed with nginx. And on my online staging env, I did have basic auth, but I donât recall if I had tried without them.
Best part is to know that, even with nginx, it worked. God knows what is the nginx setup they use, though , but we know it may be feasible.