FAQ: Why do I get <this error> when I click Save or Sync?

Any action you perform that doesn't reload the whole page is an Ajax action. Loco Translate performs various actions via Ajax, including Save and Sync operations from the editor.

We've received many reports of these actions throwing HTTP errors like 404 "Not Found", 403 "Forbidden", 410 "Gone" and - even weirder - 501 "Not implemented". In all the cases we've examined the source of the error has been external to our plugin and related to the server it's running on.

It's not possible to use Loco Translate without Ajax, but here are some suggestions for fixing the problem.

Check your security software

Loco Translate does not produce these errors itself, which means something is getting in the way and stopping it from working. In the majority of cases we've seen, the culprit is security software designed to protect your site from attackers and malicious code.

This may take the form of a server module like mod_security or another WordPress plugin like WordFence. Their jobs are to examine requests to the server and block anything that looks "bad". Generally this blocking is done according to specific rules that have been configured on purpose, and for reasons unknown to us some rules can cause Ajax requests from our plugin to be blocked.

We can only make guesses at why requests are blocked, but we've learned a few things from people who have solved their firewall issues:

• Overwriting WordPress files can ring alarm bells: Make sure you're following our recommendations for saving custom translations and avoid writing to any files that an application firewall might deem suspicious.

• Posting large data can be blocked by some firewalls: Although this should produce a 413 Request Entity Too Large error, we've received reports of firewalls being configured to respond with various irrelevant error codes. Ensure you've enabled Ajax file uploads in the plugin settings.

We don't recommend disabling security software. It's there for a reason, but may need configuring by an expert.

Check output compression

Loco Translate's Ajax services return uncompressed JSON. Anything that interferes with this data can potentially cause problems if not done properly. This might include 'performance' plugins that compress the output that gets sent to the browser.

• It's been reported that PHP's zlib.output_compression setting can interfere with our plugin's Ajax requests. We can't reproduce this exact problem ourselves, but the setting is known to raise PHP notices due to the way WordPress closes output buffers. Try disabling this setting and see if your problem disappears.

• We've also seen issues where server modules (such as mod_deflate) are configured to compress output after it's left WordPress. This can result in HTTP protocol errors if the module doesn't alter the Content-Length header after compression. That can be solved by disabling gzip compression on requests to /wp-admin/admin-ajax.php.

Talk to your hosting provider

If your site is on a managed server you may find you need help from your hosting provider to check your server configuration.

It's not uncommon for hosting providers to say a problem isn't their responsibility when a third party plugin is involved. We recommend persisting with this line of enquiry. An issue may need escalating before someone with suitable expertise looks at it.

If your hosting support cant help you, you'll have to dig deeper into the problem yourself and find out more information.

Examine the error page

The first step to debugging HTTP errors is to actually see the error page being sent back from your server. You won't see it in the Loco Translate dashboard because Ajax actions are hidden. Most web browsers have some kind of "Network inspector" that will let you see the Ajax response with your own eyes. If you don't know how to access your network inspector, try this guide for Chrome.

Chrome has a "Preview" tab which will render the HTML (if there is any), as in the following example:

Note in this screenshot that the /wp-admin/admin-ajax.php request is highlighted, but there will be others that look the same because this is a core WordPress file. Erroneous entries might be highlighted in red, but if you're unsure which to select then watch the list as you perform actions in Loco Translate. The correct entry should appear just as the "Not Found" error appears on the page.

If you're lucky this page will tell you exactly why the request was blocked. However, in some cases (particularly 404s) the page may simply be the standard error page from your WordPress theme. For other errors (like 403 Forbidden) you may see a generic error page produced by your web server. This won't necessarily tell you why the request is blocked, but will at least give you something to go to your hosting provider with.

If the network inspector tells you nothing, switch debugging on and check your error logs.

Empty responses and 500 errors

An empty Ajax response usually means a fatal PHP error occurred without displaying a reason. Enable WP_DEBUG and try again.

If you still don't see any output you'll have to dig into your server logs to find a more useful error message. If it's a code error in our plugin then please report it as a bug, but check first whether it's a circumstantial error such as Memory Exhaustion.

See FAQ Why do I get a blank response from server? for more help in this.

It really is a bug

We're not ruling out a fault in Loco Translate, but our experience is that HTTP errors tend to be external to our plugin. That's not to say that there isn't some kind of conflict we can address, but we must be able to reproduce the issue on our own servers.

If you want to report your issue as a bug, please do so in the support forum and provide useful diagnostics.