Heartbeat Manager v1.0.3

Official Technical & End-User Documentation

Designed and optimized for high-performance server configurations, database relief, and admin panel efficiency.

1. Overview and Purpose

The WordPress Heartbeat API uses continuous, periodic AJAX requests via admin-ajax.php to manage tasks like autosaving drafts, locking posts during multi-author editing, and fetching real-time dashboard notifications. While helpful, these tasks trigger heavy server-side processing cycles every 15 to 60 seconds.

On high-traffic websites, multi-author blogs, or large-scale WooCommerce installations, these background executions can saturate host CPU capacities, resulting in increased page response latencies or temporary server crashes. Heartbeat Manager resolves this systemic bottleneck by granting developers complete control over execution frequencies across specific layout zones.

2. Plugin Settings & Configuration

Once installed, navigate to Settings > Heartbeat Manager. You will find three main configuration options:

Backend Frequency (Admin Dashboard): Controls the heartbeat interval when browsing general administration pages (Dashboard, Media Library, Plugins, etc.).
- Range: 30 to 300 seconds.
- Recommended: 60 or 120 seconds for optimal server relief.
Post/Page Editor Frequency: Controls the interval specifically inside the Gutenberg block editor, Classic Editor, or WooCommerce product edit screens. It manages critical tasks like Autosaves and Post Locking.
- Range: 30 to 300 seconds.
- Recommended: 30 or 60 seconds to preserve auto-backups while reducing server strain.
Frontend Frequency: Manages the Heartbeat API on the public side of your website.
- Options: Disabled (0), 60 seconds, or 120 seconds.
- Recommended: Disabled for most presentation websites and standard e-commerce stores.

3. Testing and Verification (Vademecum)

1. Backend & Editor Test

Open your browser's Developer Tools (F12), switch to the Network tab, and filter by admin-ajax. If you are on the general Admin Dashboard, requests will fire at your configured Backend Frequency. If you open a Post or Page editing screen, requests will dynamically switch to your Post/Page Editor Frequency (e.g., every 30 or 60 seconds).

2. Frontend Verification

Visit your public site. If Frontend is set to "Disabled", you should see absolutely no admin-ajax.php calls originating from the Heartbeat script, meaning background hits are completely halted.

3. Console Inspection

Open the browser Console tab (F12) on your public site and type wp.heartbeat.interval() or lnhm_frontend_settings. Note: If you receive an Uncaught ReferenceError or undefined error, this is perfectly normal and expected! It means WordPress has not loaded the Heartbeat script on the frontend because no active assets require it, ensuring your public pages are already naturally optimized.

4. Frequently Asked Questions (FAQ)

Will disabling the Frontend Heartbeat break my store's functionality?

No. For standard presentation platforms or portfolio layouts, disabling the frontend heartbeat has no negative impact. However, if you are utilizing specific external components like dynamic real-time live messaging blocks, ongoing live counters, or complex dynamic stock updates, setting an interval of 60 or 120 seconds is highly recommended over full deactivation.

How does this plugin improve my core performance metrics?

By shifting or entirely turning off redundant constant server polls, you drastically minimize the overhead background executions hitting admin-ajax.php, freeing up immense server resources. The method used preserves the stability of dependent plugins (such as WooCommerce).

Why do I get an "Uncaught ReferenceError" or "undefined" error when testing the frontend?

This is a great sign! WordPress does not load the Heartbeat script on the frontend by default. If you see this error, it confirms that neither your theme nor your active plugins are running background AJAX loops on your public pages, leaving your frontend fully optimized.

Will a higher Post/Page Editor interval affect my Page Builder or Autosaves?

Setting the Editor interval to a maximum value (e.g., 300 seconds) means your automatic layout backups will only trigger every 5 minutes. If you are actively building pages with Elementor, Divi, or Gutenberg, we highly recommend keeping this specific setting at 30 or 60 seconds to balance server resource savings with content safety in case of browser crashes.

5. Technical Notes for Developers

Main Hooks Used

add_filter( 'heartbeat_settings', ... ): Used to modify the interval dynamically between the admin dashboard and editor viewports.
add_action( 'wp_enqueue_scripts', ... ): Safely deregisters or modifies public-facing scripts to intercept frontend hits.

6. Changelog

Version 1.0.3

Fix: Updated Vademecum documentation to prevent testing confusion regarding Admin vs Editor intervals.
Docs: Added technical FAQ coverage for high editor intervals, page builders, and WordPress autosaves.

Version 1.0.2

Tweak: Raised the minimum allowed interval for Backend/Editor settings to 30 seconds to prevent aggressive server polling.
Docs: Enhanced built-in testing guides to clarify native frontend script behavior.

Version 1.0.1

Security: Implemented strict data escaping procedures (esc_attr, esc_html) and sanitization (intval).
i18n: Fully internationalized and translation-ready infrastructure.
Initial stable public deployment.