FAQ

An audit log is append-heavy, filtered by date range and rarely edited — the opposite access pattern of wp_posts. Storing entries as a custom post type would mean one wp_posts + one wp_postmeta row per field for every login, save, and setting change, multiplying table size and slowing down the post-editing tables every other plugin also queries. A dedicated table with purpose-built indexes (created_at, user_id, action, object_type, and a composite action + created_at index for brute-force detection) keeps writes cheap and filtered reads fast even with a large history, without adding load to wp_posts/wp_postmeta. The table is namespaced ({prefix}reslab_activity_log) to avoid clashing with other logging plugins, is created via dbDelta() on activation/upgrade, and is fully removed by uninstall.php.

No meaningful impact on front-end performance. The tracker hooks fire only when specific admin or server-side actions occur. Database writes use a single $wpdb->insert() call with no additional queries.

uninstall.php drops the {prefix}reslab_activity_log table, removes all plugin options, deletes the brute-force alert transient, and strips the custom capabilities from all roles. Nothing is left behind.

Yes, two ways. Either grant the reslab_al_view_log capability to any role using a role-editor plugin, or add roles to the reslab_al_default_roles filter (array $roles, defaults to [ 'administrator' ]) so the plugin grants it itself on activation and on every schema upgrade — no role-editor plugin required. Either way they'll see the full log but won't have access to the Clear log button (which requires reslab_al_clear_log). By default they'll see every event type; add a callback on the reslab_al_viewable_object_types filter (array $types, int $user_id) to limit a role to, say, only order/coupon events — see README.md for an example.

Yes. The WooCommerce tracker uses the woocommerce_order_status_changed action hook, which fires reliably regardless of whether legacy post-based orders or HPOS is enabled.

Off by default — enable "Enable brute-force alerts" on the Settings page first. Once enabled, an hourly WP-Cron event counts login_failed entries per IP address within a configurable window (default: 10 attempts / 1 hour). When the threshold is exceeded a single email is sent to the admin email address. A transient prevents duplicate alerts for the same IP within the same window.

Also off by default. It's a second, independent hourly check that counts deleted events per user within a configurable window (default: 5 deletions / 1 hour) — the pattern a compromised account or malicious insider leaves behind (bulk order/content/user deletion), which brute-force detection doesn't catch on its own.

Set a "Webhook URL" on the Settings page (under Notifications). Every brute-force and mass-deletion alert is emailed and POSTed as JSON to that URL, so it works directly with Slack/Discord incoming webhooks, or through a no-code tool (Zapier, Make, n8n) for Telegram or anything else. There's also a reslab_al_alert_{$type} action hook (bruteforce or mass_deletion) for custom PHP integrations.

Yes — GET /wp-json/reslab-al/v1/events returns paginated JSON, authenticated via WordPress Application Passwords (Settings → your profile → Application Passwords) and gated by the reslab_al_view_log capability. It accepts the same filter_* query parameters as the admin screen (action, object_type, user, date range, search) and respects reslab_al_viewable_object_types.

By default the plugin only reads REMOTE_ADDR, which is the direct connection IP. Forwarded headers (X-Forwarded-For, CF-Connecting-IP) are only trusted when the connecting IP is listed in RESLAB_AL_TRUSTED_PROXIES or the reslab_al_trusted_proxies filter, preventing IP spoofing.

Not by default. All data stays in your WordPress database, and the plugin makes no outbound requests unless you explicitly configure a webhook URL for alerts (see above) — in which case only the alert payload (not the full log) is sent to that URL.

The plugin is not explicitly built for multisite in this release. It can be network-activated but will share a single log table for all sites on the network. Per-site tables are planned for a future release.