Not Disabling Heartbeat

Here to say the same — ever since the update last week, I’m being SLAMMED with constant hits to our admin-ajax, while I update dozens of posts for the new year.

I too disabled the heartbeat for all three tick boxes.

The heartbeat is not disabled at all.

• This reply was modified 7 years ago by kjf916.

Same here. Disabled the heartbeat for all three tick boxes. Also being slammed with hits to admin-ajax.

Does anyone have the prior version? perhaps we can roll back, as there has been no response

I found this and just tried it out. Will report back if it helps:

In most cases, you can completely disable Heartbeat if you’re the only person working at any given time in your site and you know that you don’t have any important functionality that heavily relies on it to work properly.

To disable it, edit the functions.php file of your theme and paste these lines right after the opening <?php tag:

___________________
add_action( ‘init’, ‘stop_heartbeat’, 1 );
function stop_heartbeat() {
wp_deregister_script(‘heartbeat’);
}

____________________

This should completely disable this functionality and it will no longer add to the executions number and CPU time used in your account.

I tried this same code and it’s still running.

Me too. Hostgator had me install it on both my functions.php file and my plugins.php file, and that heartbeat is still running. I wish the plug-in creator would respond with a fix. It’s literally killing my site and holding up work. I’d pay for it happily, too, if that was an option.

Looks like either something is re-enqueueing the script or something changed within elsewhere. I’ll be looking into it, but I have to find the time first.

If someone else wants to look into it before I can, I’ll gladly apply a patch for everyone.

Thank you Jeff!

At least on our end it looks to be the mailchimp for woocommerce plugin that is causing the CPU drain via admin-ajax: https://github.com/mailchimp/mc-woocommerce/issues/158

Not sure if this plugin is somehow overriding the heatbeat control?

We thought our GetResponse plugin was causing the problem, eliminated it entirely and stopped inviting newsletter signups, just to see if that conflict was contributing. Removing that plug-in has had no effect. We’ve also removed other non-crucial plug-ins and that heartbeat remains.

The manual control-heartbeat code given to us by Hostgator didn’t work, this plug-in doesn’t work, and disabling our index.php file didn’t work.

HostGator gave us the idea of changing permissions on the index.php file to 0.0.0. while we’re working (in the middle of the night as it would result in our site failing to load for any visitors), just to see if it gives us a chance to work and save our posts. It didn’t work, either. Those admin-adjax files and index.php files keep loading in such high numbers it crashes our site.

To say we’re losing our minds is putting it mildly.

9 Planets, message for you, I have an interesting update. The code mentioned above, to disable the heartbeat, was added directly to my functions.php file, but had no effect.

However, just as an experiment, I took that code back out of my functions.php file, which was nested under my CHILD theme folder, and instead, added it to my functions.php in the parent theme. Normally I’d never change that file, but I’m desperate.

Added the code to the parent functions.php file, saved, and for the last hour, I’ve updated 10-15 posts without a single disconnect, delay, or excessive ajax fetch. No high processes on my panel, but still waiting for the CPU Use spike to come down when it next refreshes on the server.

I have not been able to save more than one post in a single day, with this heartbeat issue. Now, I’ve edited and saved over a dozen in the last hour alone without any ill effects.

Site still loading a little slower than usual, but fingers crossed … if I have to manually update that code in the parent functions.php file, until any kind of glitch in the plug-in is discovered, or other hitch, so be it.

kjf916 – Thanks! Good to know. I had the code in my child theme too and was wondering about that.

We just swapped out the clients mailchimp plugin for a 3rd party version. We weren’t having constant problems, but it would spike up a couple times a day and then a few days later happen again. So we’ll see if this helps. If not, I’ll try placing the code in the parent file.

Well my fix was great for several hours but CPU now spiking and heartbeat loading again. The plug-in hunt and destroy continues.

Had the same problem. I’ve found that Elegant Themes’ Divi theme is the cause of this for me.

The function in question is et_builder_maybe_ensure_heartbeat_script() within Divi/includes/builder/functions.php

These three actions seem to trigger it:

add_action( 'admin_print_scripts-post-new.php', 'et_builder_maybe_ensure_heartbeat_script', 9 );
add_action( 'admin_print_scripts-post.php', 'et_builder_maybe_ensure_heartbeat_script', 9 );
add_action( 'wp_footer', 'et_builder_maybe_ensure_heartbeat_script', 19 );

I’m guessing disabling this everywhere will have a negative impact on Divi. In my case, it’s in my local dev environment where heartbeat is needed, so I switched themes.

I’m guessing you can change the interval which may help.

We’re using a Genesis Framework Theme on the site I was having trouble with. So far so good with the new WooChimp plugin over the old MailChimp version.

I also have a lot of sites that use Divi and none of them are having this issue. What version do you have installed Marcus?