Common Issues

The Tools menu has no Ability Auditor item#

Symptom: After activation there is no Tools > Ability Auditor, and an error notice says the plugin needs the Abilities API.

Cause: The site runs WordPress older than 6.9.

Fix:

1. Go to Dashboard > Updates and update WordPress to 6.9 or later.
2. Reload wp-admin. The Tools items appear without reactivating the plugin.

The license will not activate#

Symptom: Clicking Activate License shows an error.

Cause: The key was mistyped, all activations for the plan are used, or the server cannot reach technoleet.dev.

Fix:

1. Copy the key again from your technoleet.dev dashboard and paste it without spaces.
2. Check Activation Remaining in your dashboard. Deactivate a site you no longer use.
3. Ask your host whether outbound HTTPS requests to technoleet.dev are blocked.

No updates are offered#

Symptom: A newer version exists but the Plugins screen does not show it.

Cause: The license is expired, deactivated, or has not been checked recently.

Fix:

1. Open Tools > Ability Auditor License and check Status and Expires.
2. Click Check License Status Now.
3. If the license has expired, renew it from your account, then check again.
4. Go to Dashboard > Updates and click Check again.

Many cells show Inconclusive#

Symptom: Whole rows or columns of the Role matrix are Inconclusive.

Cause: Either one plugin’s permission callbacks depend on input rather than roles, or the audit ran out of its 60-second budget and skipped the rest.

Fix:

1. Open a detail panel and read the reason under Permission check by role.
2. If the reason is a timeout, raise the budgets with the abau_permission_call_budget and abau_audit_time_budget filters (see Hooks & Filters) and run again.
3. If the check depends on input, that is a property of the ability, not an error. Consider whether the callback should also check a capability.

“A permission callback tried to execute these abilities”#

Symptom: A warning on the Report tab or in WP-CLI output names one or more abilities.

Cause: A permission callback calls another ability (or its own) while deciding who is allowed. Ability Auditor blocked the call.

Fix:

1. Open the ability’s detail panel and note the Permission callback.
2. Contact the plugin author, or change the callback so it only checks capabilities and never executes abilities.

The daily audit never runs#

Symptom: The Settings tab shows a next run in the past, and History has no Daily entries.

Cause: WP-Cron only runs when the site gets traffic, or DISABLE_WP_CRON is set.

Fix:

1. Visit the site front end once; the overdue event runs on the next request.
2. For reliable timing, add a system cron job that requests wp-cron.php every few minutes, or run wp cron event run abau_scheduled_audit or wp ability-audit run from a real cron job.

Exposure shows “set by core” for every ability#

Symptom: A notice says some abilities were registered before Ability Auditor loaded.

Cause: Another plugin registers abilities very early, before this plugin’s listener is attached, so the raw registration arguments were not captured.

Fix: The effective REST and MCP values are still correct; only the source (explicit versus inherited) is unknown. No action is needed. If you maintain the early plugin, register abilities on wp_abilities_api_init instead.

I did not receive an email alert#

Symptom: A daily audit found High or Critical findings but no email arrived.

Cause: The findings were already present in the previous audit (so they are not new), the audit was manual or from WP-CLI, or the site cannot send mail.

Fix:

1. Check the New column on the History tab for that audit. Only new High and Critical findings trigger email.
2. Confirm Email alerts is on under Settings.
3. Test that the site can send mail at all, for example by requesting a password reset.