DEV Community: PluginLab

WordPress Heartbeat API: What It Does and When to Slow It Down

PluginLab — Tue, 10 Nov 2026 11:14:10 +0000

If you have ever opened your browser's network tab on a WordPress admin screen, you have seen a request to admin-ajax.php that keeps repeating on its own. That is the Heartbeat API. It is part of WordPress core, it is on by default, and it is one of the most misunderstood things people switch off.

I built SlimPress to turn off parts of core that a site does not use, with each switch explaining what it might break. Heartbeat is a good example of why that explanation matters, because the right answer is not always "off".

What the Heartbeat API does

Heartbeat is a small timer in the browser. While a logged-in user has a WordPress screen open, it sends a request to your server every so often (roughly every 15 to 60 seconds, depending on the screen) and lets WordPress and plugins send data back. In core it is used for three things:

Autosave of the post you are editing.
Post locking, so two people do not overwrite each other, and the "someone else is editing this" notice.
Login expiry, the prompt that asks you to log in again without losing your work.

Plugins can hook into it too, for example to refresh a live counter or a notification badge in the dashboard.

Why it can matter for server load

Every heartbeat is a full WordPress request. One editor with a tab open is nothing. A handful of staff who leave the dashboard open all day on a small shared host, or a shop where several people sit on the orders screen, add up to a steady trickle of admin-ajax.php calls that never stops. On a well-resourced server you will not notice it. On a weak one, it is often what you see when you check what is hitting the site while nobody is visiting.

I will not give you a speed-up figure for it, because it depends entirely on your hosting, how many people are logged in and what your plugins add to each beat. If you want a number for your own site, the performance test in SlimPress compares your pages with and without its features in the same run, and says "within noise" when the difference is too small to trust.

Slow it down, or turn it off?

These are different choices, and they have different costs.

Leave it alone if you edit content regularly, have more than one author, or run plugins that show live data in the admin. Autosave and post locking are useful.
Limit it by location if you want the saving without the constant background chatter. SlimPress has a Heartbeat switch per location, so you can treat different parts of the site differently instead of one on/off for everything.
Turn it off in a location only where you know nothing there needs it, for example a screen where nobody writes content.

Switching it off completely is the option that costs you the most. Without it you lose the protections above in that location.

How to change it with SlimPress

Install and activate SlimPress. Nothing changes on activation; every switch starts off.
Go to Settings → SlimPress and open the APIs & connections group.
Find the Heartbeat switches. Each one lists what it does and what might break, so read that before you save.
Save, then use the site as you normally would. Open a post, edit it, and check that you are still seeing autosave and the editing notices where you expect them.

SlimPress also warns you if an active plugin is known to rely on something you are about to switch off.

What can break

The risk is concentrated in two places. If you turn Heartbeat off where people edit posts, autosave and post locking stop working there, so a browser crash costs more work and two editors can overwrite each other. And if a plugin of yours uses Heartbeat for live updates in the admin, those updates stop refreshing by themselves. Neither failure is loud, which is why I would test with a real post after changing it rather than assume.

How to undo it

SlimPress keeps the last 10 versions of its settings. Open Tools → Undo a change and restore an earlier version, whether the change was a single save, a preset or a reset. If you are not sure which switch caused a problem, pause one group at a time from its tab to find out. Every switch is a runtime filter, so deactivating the plugin puts WordPress back to its default behaviour on the next request. Nothing is written to core settings.

When another approach is better

If you only want Heartbeat tamed and nothing else, a plugin dedicated to that one job may be all you need, and a few lines of code in a small custom plugin can do it too. SlimPress makes sense when Heartbeat is one of several core features you want to review with the risks spelled out. It deliberately does not do caching, minification or script delaying, so it will not replace a performance plugin for those.

The short version

Heartbeat powers autosave, post locking and login-expiry prompts in the admin.
It matters mostly on weak hosting with several people keeping the dashboard open.
Limit it where you can; turn it off only where nothing needs it, and test with a real post.
You can undo any change from the Tools tab.

SlimPress is free on WordPress.org, with no pro tier and no telemetry. Support happens in the WordPress.org forums, in public.

Originally published on pluginlab.dev.

Selling Event Tickets With QR Codes in WooCommerce, Without a Ticketing Service

PluginLab — Tue, 10 Nov 2026 11:08:04 +0000

If you run a venue, an escape room, a museum or a club with a WooCommerce shop, you have probably looked at ticketing services. They work, but they take a fee on every ticket, they put someone else's brand in the middle of your checkout, and your customer list ends up on their platform.

I wrote Tickets & Passes for WooCommerce for shops where the sale already happens in WooCommerce and the only missing piece is: how does a person get in the door? Here is how it works from sale to scan.

Three product types, one dropdown

After you activate the plugin and turn on the types you need, three new options appear in the same Product data dropdown that holds Simple and Variable:

Ticket: plain admission with a validity window and a set number of uses. Day tickets, entry tickets, gift admission.
Timeslot Ticket: admission for a specific date and time, with a capacity per slot.
Pass: valid across a period rather than one visit. Season passes, memberships, annual cards.

All three can sit in the same cart and the same order as your normal products, so selling a ticket and a T-shirt together just works.

What the customer gets

Every purchase issues a QR code. Customers see it in the order confirmation email, on a new Tickets or Passes tab in WooCommerce My Account, and as a printable PDF. Each ticket shows its live status (active, used, expired, cancelled or not valid yet) and how many uses are left. Timeslot tickets include an Add to Calendar file.

The QR codes and PDFs are not stored at a guessable public URL. They are served through the plugin, which checks the request is coming from a signed link in the customer's email or from the signed-in owner. That also means a page cache or CDN will not hand one customer's ticket to another visitor.

Timeslots without building next month by hand

For anything with a limited capacity per session, Timeslot Tickets let you generate slots on a repeating schedule. Capacity is checked when the item goes into the cart, not only after payment. Reservations that are never paid for are released automatically, so an abandoned checkout does not hold a seat.

Passes, guest passes and photo check

A Pass can include guest passes that the holder hands out from their account page, collect a cardholder photo at purchase, and enforce a cooldown between scans. At the door, staff see the photo next to the scan result and can compare it with the person standing there.

Scanning at the door

This is the part people expect to need an app. It does not:

The scanner is a full-screen page on your own domain, at /check-in/.
Door staff open it in a phone browser and point the camera at the QR code. It needs HTTPS, because phone browsers only give camera access to secure pages.
Results are colour-coded and you choose the colours: valid, already used, expired, on cooldown or not found.
Give staff the Scanner user role and they can check people in without seeing anything else in wp-admin.

Every decision is made on your server, not on the phone. A cancelled ticket cannot be waved through by putting the phone in airplane mode, because the check has to reach your site. If there is no camera, a code can be typed in, and manual check-in is available from the dashboard.

What it costs

The plugin is free, and there is no fee per ticket. You sell through your own WooCommerce checkout, so what you charge is what you keep. You still pay your payment processor's normal fees, as with any WooCommerce sale. There is no pro version, no telemetry, and the code is readable and unminified.

Setup in five steps

Install and activate the plugin with WooCommerce already active.
Go to Ticket & Passes → Settings and enable the product types you need.
On the Scanner / API tab, turn on the scanner. The tab shows your scanner URL.
Create a product and pick Ticket, Timeslot Ticket or Pass from the Product data dropdown.
Set door staff to the Scanner role.

Where a hosted service is still better

If you need a marketplace where strangers discover your event, or you do not already run a WooCommerce shop, a hosted ticketing service gives you that audience and the setup for free. This plugin is for the case where people already come to your own site and you would rather keep the fee and the customer relationship.

Tickets & Passes is on WordPress.org. Support is in the public forums, where the next person with your question can read the answer.

Originally published on pluginlab.dev.

How to Disable XML-RPC in WordPress Without Breaking Anything

PluginLab — Tue, 10 Nov 2026 11:08:01 +0000

XML-RPC is an old remote-access door into WordPress, a single file called xmlrpc.php in your site root. It has been switched on by default for years, and most sites have never used it. Security guides tell you to turn it off. What they usually skip is the part that matters: what stops working when you do.

I built SlimPress because I kept turning off the same parts of WordPress core on shop sites and wanted each switch to say what it might break. XML-RPC is one of the first ones people ask about, so here is the full picture.

What XML-RPC is used for

Before XML-RPC existed as a thing to worry about, it was how outside software talked to WordPress. Today three things still use it:

The WordPress mobile app, on some setups, to publish and manage posts.
Jetpack, which uses it to connect your site to WordPress.com.
Pingbacks and trackbacks, the notifications between blogs that link to each other.

Some older desktop publishing tools and a few third-party services also use it. If none of the above applies to you, nothing on your site is likely to miss it.

Why people turn it off

Two reasons come up repeatedly. First, XML-RPC accepts login attempts, and it can bundle many of them into one request, which makes it a convenient target for password guessing. Second, pingbacks can be abused to make your site send requests to other places. Neither is a reason to panic, but if you are not using the feature, there is nothing to gain from leaving it exposed.

Step 1: check whether anything uses it

Open Plugins and look for Jetpack or any plugin that mentions WordPress.com, remote publishing or a mobile app.
Ask yourself whether anyone posts to the site from the WordPress mobile app or an old desktop editor.
Check Settings → Discussion. If "Allow link notifications from other blogs (pingbacks and trackbacks)" is ticked and you care about those, keep that in mind.

If the answer to all three is no, you can switch it off.

Step 2: switch it off

You can do this with a code snippet or a .htaccess rule, but then it is hard to remember later that you did it, and harder to undo. With SlimPress it is one switch:

Install and activate SlimPress. Activation changes nothing on its own.
Go to Settings → SlimPress and open the APIs & connections group.
Turn on Disable XML-RPC. It is marked Careful, and the note under it lists what might break: the WordPress mobile app, Jetpack and pingbacks.

SlimPress also warns you if an active plugin is known to rely on the feature you are about to switch off, so Jetpack on the same site would show up before you save.

Step 3: confirm it worked

Visit yoursite.com/xmlrpc.php. On a default WordPress site you will see the message "XML-RPC server accepts POST requests only." After the switch is on, that page should no longer behave like a working XML-RPC endpoint. Then open your site's front end and the dashboard to make sure nothing looks different. For most sites, nothing will.

If something stops working

This is the part I care about most. SlimPress keeps the last 10 versions of its settings, so any save can be undone, and every switch is a runtime filter. Deactivating the plugin puts WordPress back to its default behaviour on the next request. There is nothing in your database to clean up.

If Jetpack complains after the change, turn the switch off again and reconnect it. If you want to keep Jetpack and still reduce exposure, the better route is to leave XML-RPC on and add rate limiting at your firewall or host.

The short version

Check for Jetpack, the mobile app and pingbacks first.
If you use none of them, turn XML-RPC off.
Check /xmlrpc.php afterwards, and know how to undo it.

SlimPress is free, with no pro tier and no telemetry. Support happens in the WordPress.org forums, in public.

Originally published on pluginlab.dev.