Dev.to · 6 min read

AbilityGuard v1.1: I Gave My Abilities API Monitor a Memory (and a Voice)

AbilityGuard v1.1: I Gave My Abilities API Monitor a Memory (and a Voice)

A few weeks back I published an article upon my latest AbilityGuard plugin so you could actually see what the WordPress Abilities API was doing on your site — which abilities were registered, which ones were risky, and what ran when nobody was watching. That part worked. But pretty quickly I ran into a problem I should've seen coming: a monitor that only shows you the last 100 log entries and makes you stare at the screen isn't really monitoring anything. It's just a mirror. You still have to be looking at it at the exact moment something happens. So v1.1 isn't a "few bug fixes" release. It's the release where AbilityGuard stopped being a dashboard and started being something closer to a watchdog — one that remembers, filters, exports, flags, and taps you on the shoulder when it needs to. 🧠 The Problem With a 100-Entry Memory The original execution log was capped at a rolling 100 entries. Fine for a quick check. Useless for an actual audit trail. If you wanted to know what an ability did last Tuesday, and 150 executions had happened since, that data was just gone. So the first thing I fixed in 1.1 was retention itself. You can now configure how many log entries AbilityGuard keeps — including unlimited retention if you want a permanent record. No more silently losing history because the log rotated while you weren't looking. Of course, unlimited retention is only useful if you can actually find what you're looking for inside it. Which brings me to the next piece. 🔍 Filters That Don't Fight Each Other The old filter set technically existed, but it wasn't built for real audit work. In v1.1 I rebuilt it as advanced execution log filters — status, trigger context, risk level, category, user ID, date range, and free-text search, all combinable. The detail that actually took the most iteration wasn't adding filters, it was making them behave independently. Previously, selecting one filter could quietly narrow or reset another in a way that wasn't obvious. Now each filter selection stands on its own, so "show me destructive abilities triggered via REST by user 14 last week" actually returns what you'd expect, instead of a filter fighting itself behind the scenes. Once you've built a filter combination you actually care about, you shouldn't have to rebuild it every time. So I added saved views — save a filter set once, reuse it from a dropdown. If you're doing weekly reviews, this alone probably saves you the most clicks. And once you've filtered down to the exact slice of log you care about, you'll usually want to take it somewhere else — which is exactly what CSV export is for. 📤 Getting Data Out of the Admin Screen Every filtered log view can now be exported to CSV directly from the current view. This wasn't a hard technical problem, but it mattered a lot — because plenty of AbilityGuard users aren't just checking a dashboard, they're pulling this data into a compliance report, a security review, or a spreadsheet someone else on the team is going to read. 👀 The Watchlist: Not All Abilities Deserve Equal Attention Here's the thing about a site with the Abilities API active — you might have dozens of registered abilities, and realistically only a handful of them actually worry you. The ones marked destructive. The ones an AI agent could trigger unattended. The ones tied to user data. v1.1 adds a sensitive ability watchlist so you can flag exactly those abilities for closer attention, instead of treating every entry in the inventory as equally important. It's a small feature on paper, but it's the one that changes how you actually use the plugin day to day — you stop scanning everything and start watching what matters. And a watchlist that requires you to keep checking back is still passive. So the next two features exist to close that gap. 📧 Email Alerts and Scheduled Reports This is the part that turns AbilityGuard from "something I check" into "something that tells me." Email alerts fire for high-risk, failed, or watchlisted ability executions — so if something destructive runs, or something fails, or a watched ability triggers, you find out without opening wp-admin. Scheduled reports send a daily or weekly summary of activity, so even if nothing alarming happened, you still get a pulse check in your inbox. Between the two, you get both ends of monitoring covered: immediate notice when something risky happens, and a steady rhythm of visibility even when nothing does. 🌐 Multisite Finally Gets Its Own Dashboard If you're running a network, checking abilities site by site was never going to scale. v1.1 adds a Network Admin dashboard that shows per-site ability and log counts in one place, so a network admin can spot which site is generating unusual activity without switching contexts twenty times. And while I was in the multisite code, I found (and fixed in the 1.1.1 patch) a bug where uninstall cleanup only ran on the main site instead of every site in the network. If you'd removed AbilityGuard from a multisite install, subsites were quietly keeping their data behind. That's fixed now — cleanup runs network-wide. The 1.1.1 patch also brought the inventory detail popup in line with the execution log's detail modal, so the two feel like the same plugin instead of two screens that were designed a week apart. 🧩 What Didn't Change No new abilities are logged that weren't logged before. AbilityGuard still only tracks Abilities API registrations and executions — not general WordPress admin actions like post edits or media uploads. That boundary was intentional in 1.0, and it's still intentional now. This release is about doing more with the data AbilityGuard already collects, not collecting more kinds of data. Payload logging also stays privacy-conscious by default: output logging is still off unless you turn it on, same as before. 🛠️ Where This Goes Next Retention, filters, exports, watchlist, alerts, reports, multisite — that's a lot for one point release, and it's the reason it took a few weeks instead of a few days. What's next is less about adding more surfaces and more about making the existing ones smarter — better risk scoring, and eventually, a Pro tier for teams that need more than a single site's worth of visibility. More on that when it's actually ready to talk about. If you're running the Abilities API on your site — whether it's your own plugins registering abilities or third-party AI tools doing it for you — v1.1 is a straightforward update. No config migration, no breaking changes, just a plugin that remembers more and bothers you less. You can grab it from the WordPress.org plugin page.

This is a summary aggregated from Dev.to. Read the complete article on the original site:

Read full article at Dev.to

More AI & Machine Learning News