Jeff Matson

I’m the original author of Heartbeat Control.

I hate to see this. When I handed it over to the current maintainers several years ago, I had hoped that they would continue it for as long as it was useful to people. Looks like it hasn’t.

I’ll reach out and see if I can get this handled. I’d rather take it over again than see it go abandoned.

So if you’re having issues with the post editor and autosaves, set it to only disable the heartbeat on the frontend.

As long as nothing has changed since I sold this plugin to the WP Rocket folks, Dashboard should disable the heartbeat on admin pages (post editor and such), while Frontend will disable the heartbeat for visitor-facing pages.

Interesting. Something could be overriding things elsewhere. If you use the Chrome developer console, how often are the request to admin-ajax.php firing?

It should be fine, but I haven’t tested them together so your results may vary. Give it a whirl and let me know how it goes!

It might have something to do with us both using CMB2. Shoot me over an email to my contact form on https://jeffmatson.net and we can work together to resolve it.

Yes indeed!

@kendalm The issue itself appears to be due to heavy caching that is preventing the notification from properly dismissing. I’ve have a few reports of it here and there, but unfortunately nobody has been able to provide me with an environment to test against and find why the issue is occurring.

If you could provide me with a development environment to test against, I’d greatly appreciate it. It’s not intended to occur (and code-wise should disappear and stay gone), but without being able to replicate the issue, there’s not much I can do.

Here’s a few answers to your questions:

1. Disabling the heartbeat API is usually fine for most sites, but it’s going to vary based on your particular situation. Usually, the safest route is to disable everywhere except post editor pages and increase the interval on post edit pages. It’s entirely subjective though, so it depends on your site’s specifics.

2. You can safely slow it down everywhere in most cases. I don’t want to give absolutes just because every site is different, but in my experience, slowing it down everywhere is fine 99.9% of the time.

On most sites, it’s only used by post autosave functionality, so disabling everywhere except the post editor is usually fine. Of course, if you’re not worries about autosaving, you can disable it there too.

3. When referring to WordPress Dashboard, it’s referring to the entirety of the WordPress admin.

Hope that helps!

@seepops Interesting. Let me know what you find. If you want to set me up with a test environment to look deeper into it all, just let me know!

No catch. Just a 3rd-party Gravity Forms add-on like many of the others out there. To my knowledge, there isn’t even a paid version available.

@sprucelydesigned Thanks so much! I’ll do some digging to see what I can find related to the caching issues. In the meantime, feel free to use the hook I mentioned to completely disable it if you need to.

Are you getting any errors anywhere? Could you provide more information on your environment (WordPress version, PHP version, plugins/themes installed)? Thanks!

@sprucelydesigned Would you mind changing your review? Based on it, you mentioned the plugin is worth 5 stars, but the message dismissal is what led you to leave a 1-star rating. As the issue appears to be cache-related and completely unrelated to the plugin itself, I’d appreciate it. Thanks!

From what @sprucelydesigned is saying in his update, it sounds like it might be a caching issue somewhere.

Code-wise, it simply checks if an update notice should be fired (based on the plugin actually being updated or installed), and displays the notice. Upon dismissing it, it removes that value. Nothing sketchy going on here at all or anything time-based. As soon as you dismiss it, it should immediately dismiss it (until a new update is released).