Comprehensive guide to FIX Connection lost Error in WordPress

Connection Lost Error is the following error message might occur while you are uploading, inserting media (image) files, publishing a post or saving draft.

“Connection lost. Saving has been disabled until you’re reconnected. We’re backing up this post in your browser, just in case.”

It may take a few seconds or over 10 minutes for that connection issue to clear. During that time you can’t save a draft or publish an article. At first, I thought there was something wrong with my activated plugins, themes… so I tried deactivating all my plugins, updating and changing to default themes, downgrading the version of WordPress and everything but the error still occurs. Very frustrating.
I found the problem must occur due to a technical glitch which leaves site owners frustrated and clueless. So then, in this post, I will help you understand the real reasons behind this error and how to resolve it efficiently.

Why Does This Error Occur?

The problem you describe can be caused by so many different factors. When editing a post, WordPress uses Ajax to auto-save revisions to the post as you edit. Basically, the admin-ajax.php is used to make AJAX based connections to the server, directly from your web browser. So that in the event you lose internet connectivity, or your server goes down, none of your work is lost, and you can use the most recent revision possible. It works in the background to send a regular “pulse” between the browser and the server that is repeated at regular intervals and can be used to keep them in sync, allowing near-real-time frontend updates.

I’m in the process of chasing down the problem. I found that message is a result of your server throwing a 503 error and the WordPress Heartbeat API catching that error.

The purpose of this API is to simulate a bidirectional connection between the browser and the server. Initially, it will be used for autosave, post locking, and log-in expiration warning while a user is writing or editing.

The idea is to have a relatively simple API that sends XHR requests to the server every 15 seconds and triggers events (or callbacks) on receiving data. Other components would be able to “hitch a ride” or get notified about another user’s activities.

The things WordPress Heartbeat API Manages:

• Creation of periodic autosave and revisions when you create/edit posts in the editor.
• Real-time sales data on the dashboard by e-commerce plugins.
• Used to show notification on the WordPress admin dashboard.
• Shows the locking information of a post by other authors. On multi-author sites when an author is editing a post, all other authors will see a message that the post is locked by other authors.
• and more …

However, the downside of Heartbeat is that it can cause high resource usage on the server. On shared hosts, this can often give you a “connection error” message on WordPress because it has limitations as they need to distribute the resource among all the hosted sites.

Is safe to disable it completely?

In my opinion, it depends on what kind of your server. Control the Heartbeat API seems the best solution instead disable it completely. It keeps all the features of the Heartbeat API but is battling high CPU usage to reduce your server load.
In below cases, you can disable the Heartbeat API completely.

• If you are a single user on your site, and you are sure that you will not be needing any features made possible by the API.
• You hate the WordPress Revision feature and want to disable it. This means you need to press the Save Draft button manually to save your content.
• Although you have multiple writers on your blog they all work on their owned articles, never use the post-locking function.
• You don’t plan to use any real-time statistics features.

Fixing Connection lost Error in WordPress

First of all, check your internet connection, to make sure you connected. In lots of cases, you may be disconnected from your blog, and that message appeared.
Secondly, WordPress Heartbeat API dealing with CPU usage then numerous admin-ajax.php request on some servers can cause an overload. It’s really important to have an eye on the Heartbeat API. If you ever encounter such a problem, try limiting or disabling it.
Finally, I found that “Connection lost” usually happens when running a task, that needs a lot of time for processing more than the limit value in your server’s configuration.

Controlling WordPress Heartbeat API

By default, WordPress identifies a page as non-focused when there have been 5 minutes of inactivity within the browser. The WordPress Heartbeat API Updating happens every 15 seconds on active page and every 2 minutes for pages that are inactivated. It’s the cause of this problem.
You can do two things – one is to control the API and other is to completely disable it.

1. Disable the WordPress Heartbeat API. (Note that disabling the Heartbeat API completely could affect the functionality of plugins and themes that rely on it.)
   • Disable everywhere.
   • Disable on the dashboard page.
   • Disable everywhere Except for post.php and post-new.php
2. Limit WordPress Heartbeat API

The fastest way to change that value is a plugin. There are a lot of plugins on the WordPress Plugins Repository that helps you change or disable the WordPress Heartbeat values.

• Go to Dashboard >> Plugins >> Add New.
• Search for Heartbeat
• Choose the newest or most installed plugin then click Install Now
• Activate the plugin then follow their instruction.

I recommend Heartbeat Control by WP Rocket. The figure below is a sample configuration of that plugin.

Disable WordPress Heartbeat API Using the Code

If you don’t want to use a lot of plugins on your WordPress website or you create your own theme. You can also completely stop the heartbeat API by adding the below code in functions.php file.

add_action('init', 'stop_heartbeat', 1);
function stop_heartbeat() {
wp_deregister_script('heartbeat');
}

Timeout between Nginx and PHP-FPM

When this message appeared, I’ve checked the server’s logs (I use LEMP on Digital Ocean Droplet) then found error messages below.

2019/05/19 11:36:59 [error] 14564#0: *1215 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 123.456.789.123, server: narga.net, request: "POST /path/to/some/script.php HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "narga.net", referrer: "https://www.narga.net/"

This happens because your upstream takes too much to answer the request and NGINX thinks the upstream already failed in processing the request, so it responds with an error. You can change the time Nginx waits for the FastCGI backend, by changing the fastcgi_read_timeout parameter in your virtual host.

location ~* \.php$ {
    ...
    fastcgi_read_timeout 120;
    ...
}

Hope this helps!