Tainacan Processes Stuck Indefinitely (Delete & Import Tasks Never Complete)

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.

Hope it helps.

Hi @vishalmori, welcome to our forum!

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.

Let us know how the system diagnosis goes!

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 :frowning:

Right now, I have no other ideas to investigate on this matter :confused:

If you find any new information, please bring it on, maybe that’s the click we need to find the solution.

Tenho a mesma situação aqui.
1.700 itens demoraram 3 dias com Nginx. Com Apache, apenas 2 minutos!

The issue has finally been resolved for me.

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:

This issue occurred on my staging site. Since it is a staging environment, I simply enabled this protection setting :sweat_smile: .

I have a theory about how this might be directly connected to the background/cron process, but I’m not sure yet.

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


Interesting. Good to know it was resolved there.

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 :stuck_out_tongue: , but we know it may be feasible.

Here is a completely clean installation of Ubuntu + Nginx + Wordpress + Tainacan.

Apache works. Nginx is a turtle.