DevDome Activity Log: Track WordPress User Activity

DevDome Activity Log is a free WordPress activity tracker and user activity log. It keeps an audit trail of recorded site activity in a dedicated table in your own database, with filters, search and CSV export. The coverage list below states what it records and what it does not record; anything outside that list is not recorded.

What it records

• Authentication: review login history covering logins, logouts, failed login attempts, password reset requests and completed resets. Repeated failed logins and reset requests are counted into one row per source, per attempted account, per hour by a single atomic database statement, so concurrent attempts cannot create duplicate rows or lose increments.
• Users: accounts created and deleted, roles set, added and removed, email changes (both addresses masked) and other profile changes. Passwords are never recorded, only the fact that one changed.
• Content: posts, pages and custom post types created, updated, trashed, restored or deleted, with a summary of what changed. Bodies are compared by hash and never stored.
• Plugins, themes and core: installs, updates (with the previous and new version when it can be observed), activations, deactivations, deletions, theme switches and core updates. A plugin or theme update after which the installed version did not change is recorded as a failed update; when the previous version could not be observed, an update the upgrader reported as failed is recorded as failed too.
• Media and comments: uploads, deletions and comment status changes (approved, spam, trash, restored).
• Settings: changes to a fixed allowlist of nine important options: site title, site URL, home URL, admin email, open registration, default role, permalink structure, the site time zone and the UTC offset (the clock decides what every stored timestamp means).
• The log itself: every change to its own policy with the previous and new value, every CSV export, every retention purge, every personal-data erasure and every storage migration. These records cannot be switched off by the settings they describe.

Not recorded (yet)

So there is no ambiguity, this plugin does not currently record: comment creation, editing or permanent deletion; media edits and file replacements; term, taxonomy, menu, widget, Customizer, block-template or post-meta changes; rolled-back core updates and the reason an update failed (only the fact that it did not complete); application passwords; session destruction; the plugin/theme file editor; capability changes outside roles; network-level multisite actions; WooCommerce or other third-party events; and site options outside the nine-option allowlist.

Concurrency, performance and scale

• Failed logins and reset requests use one INSERT ... ON DUPLICATE KEY UPDATE statement against a unique bucket key. The counter is incremented by the database and never read into PHP first. The automated test suite asserts exact totals for 1, 10, 100, 1,000 and 500 synchronized attempts and for rotating usernames against the per-source row cap.
• Grouping uses a site-secret keyed fingerprint of the exact client address, so two machines in the same /24 are not merged into one attacker identity, while the stored address is still the truncated form.
• Events are written to a dedicated indexed table, never the options table. The settings tracker checks its allowlist on its first line and returns immediately for every other option.
• Queries are bounded: pages, page size, search length and date range are validated and refused with a clear error rather than run as an unbounded scan. CSV export reads with a keyset cursor inside a snapshot, so a concurrent write cannot duplicate or skip rows, and it does not repeat a COUNT(*) per page.
• Query plans have not been benchmarked on multi-million-row tables; the indexes are chosen by reasoning, and a very large log with a free-text search over the details column will be slow.

Access control

Reading the log, exporting it, changing its policy, purging it, viewing the diagnostics, repairing the storage and seeing full IP addresses are seven separate capabilities (devdacti_read, devdacti_export, devdacti_manage, devdacti_purge_log, devdacti_integrity, devdacti_repair, devdacti_view_ip), each with its own filter. They are granted to the administrator role on activation, and any role you grant devdacti_read to can read the log without being able to export or purge it. Administrators hold all seven. Reducing what gets recorded requires an explicit confirmation; every policy change is written in one statement and recorded with its outcome, and a change that could not be stored is recorded as a failure.

Filter, search and export

• Filter by user, activity group, individual action, object type, severity and date range, or search the object, details and username columns. Filters are reflected in the URL.
• Export the current filtered view to CSV. Every cell is neutralised against spreadsheet formula execution, including formulas hidden behind leading spaces, tabs, newlines, a byte-order mark or invisible Unicode characters.

AI agents and MCP

On WordPress 6.9 and newer the plugin registers eleven abilities through the WordPress Abilities API (and lists them as tools on the official WordPress MCP Adapter when it is installed): get-status, get-settings, get-events, get-recent-activity, get-user-activity, get-login-events, get-plugin-changes, find-suspicious-changes, update-settings, run-purge and repair-storage. Every read checks the same read capability as the screen and is recorded like a screen read; update-settings needs the manage capability and refuses a change that reduces coverage until it is confirmed; run-purge and repair-storage need their own capabilities and an explicit confirmation. No raw e-mail address and no server path leaves the site through an ability. On older WordPress nothing is registered.

Free

Every tracker, filter, the dashboard, retention control and CSV export are free. There is no paid tier and no locked feature inside the log.

Known limitations

These are deliberate, and named here rather than implied away:

• The log is a normal database table. A site administrator or anyone with database access can edit or delete rows in it, and this plugin does not detect that. There is no hash chaining or signed batching, so the log is evidence of what happened on a site you still control, not evidence that survives a compromise of it.
• Event details are stored as a readable sentence rather than a structured, versioned payload. That makes them easy to read and search, and it means a personal-data erasure clears the whole sentence for the account concerned instead of individual fields.
• CSV export is synchronous and capped. Very large exports should be narrowed by date range rather than run in one request; there is no background export job with progress and resume.
• The user filter offers the 200 most recently active accounts and says so; it is not a complete, pageable directory.
• On multisite, events are stored per site and are read per site. There is no network-wide screen that queries every blog at once.
• Query plans have not been benchmarked against multi-million-row tables.
• A personal-data erasure runs as a single pass over the table; on a very large log it can be slow.

External services

The Activity Log’s own features (recording, the screen, filters, export, retention, privacy export and erasure, the Abilities API) run entirely on your own server and make no network requests.

Error reports (devdome.com), only when you press “Report this error” on an error message. The plugin sends the error text, the plugin, bundled library, WordPress and PHP versions, whether the site is a multisite, the site locale, the screen you were on, its own state (storage schema status, write-failure and retention counters, the cached dashboard numbers, the trusted-proxy status; never an event row, username or IP address), your site address, the generated site ID, your DevDome account ID if the site is connected, and your admin e-mail (so support can reply) to https://devdome.com/api/plugin/error-report. Every text passes the plugin’s own redactor before it leaves the site. Nothing is sent unless you press the button. Service provider: DevDome. Terms: https://devdome.com/terms-of-service Privacy policy: https://devdome.com/privacy-policy

Plugin catalog (devdome.com), only after you connect a DevDome account. The DevDome Dashboard inside wp-admin fetches the list of DevDome plugins (names, descriptions, logos, links) from https://devdome.com/wp-plugins/catalog.json at most once every 12 hours (one hour after a failed fetch), so the list stays current. Only the bundled core version is sent in the request; no site or visitor data. Disconnected sites never fetch it. Service provider: DevDome. Terms: https://devdome.com/terms-of-service Privacy policy: https://devdome.com/privacy-policy

The Report a bug link on the DevDome Tools dashboard opens https://devdome.com/report-bug in your browser with the plugin identifier and version in the address; nothing is sent by the plugin itself.

The plugin bundles the shared DevDome suite library that powers the DevDome Tools dashboard. What that library may contact depends on the edition you are running; on the WordPress.org edition nothing is contacted before you act; the self-hosted edition also checks for updates as described below.

WordPress.org edition

The WordPress.org package carries a build marker that keeps the library’s bot-detection feed download permanently off and contains no self-hosted updater; updates come only from WordPress.org. Besides the requests above (error reports you send, the plugin catalog after connecting), the only other request the shared library can make is the optional account connection below.

Connecting a DevDome account (optional, both editions)

The DevDome Tools dashboard offers connecting a free DevDome account (used by other DevDome plugins for optional email alerts and dashboards; the Activity Log’s own features stay local; the shared library performs only the checks described here). Nothing is sent until you press the Connect button. If you do connect: the shared library sends your site address, a generated site ID and a generated secret site token to analytics.devdome.com/api/plugin/connect/start and /api/plugin/connect/claim to link this site to your account, and your browser opens https://devdome.com/connect/ with a temporary request token so you can authorize the connection; afterwards it confirms the connection with api.devdome.com/plugin/account (site address plus the site token in a request header) normally at most once every fifteen minutes while a DevDome screen is open (sooner right after connecting, and after ten minutes when a check failed), and tells api.devdome.com/plugin/disconnect when you disconnect. When you connect from the DevDome Tools dashboard, whose Connect card states this before you press the button, those account checks also carry the slug and version of each active DevDome plugin on the site plus the bundled DevDome library, WordPress and PHP versions, so your DevDome account can show your sites and their DevDome plugins for support and update notices. Nothing about other plugins, users, email addresses, content, visitors or activity-log rows is included. Sites connected from a button that does not show that text do not send the list. Disconnecting stops the checks and the plugin list. Terms: https://devdome.com/terms-of-service. Privacy: https://devdome.com/privacy-policy

Self-hosted edition only

• https://api.devdome.com/plugin-updates/devdome-activity-log.json: the self-hosted update manifest, checked from wp-admin and cron (never on front-end requests), cached six hours, ten-second timeout, with an Accept: application/json header and a fixed DevDome-Updater/1.0 user agent in place of WordPress’ default one. The request sends no site data; it is a plain download. The updater validates the manifest (trusted host, HTTPS, matching plugin, sane version) and, when the manifest publishes a checksum, verifies the downloaded package against it before installation; on any failure the installed version keeps working.
• https://api.devdome.com/bot-protection/*: the shared once-daily bot-detection reference lists (verified-bot user-agent patterns and datacenter/bad-IP networks) used by other DevDome plugins. A one-way download; no data about your site or visitors is sent.

Privacy

This plugin stores personal data. It reduces how much it stores and controls who can read it; it does not make you compliant with any law, and it makes no compliance guarantee.

• Records are stored locally in your own database. Nothing about them leaves your site.
• Each record can contain: date and time, actor user ID, username and role, actor type and request channel, a request correlation ID, the client IP and the transport peer IP, the subject type/ID/title, the action, outcome and severity, a short details string, the occurrence count and the site ID.
• IP addresses are truncated by default (1.2.3.0 instead of 1.2.3.4, and the first three groups of an IPv6 address). Truncation is pseudonymisation, not anonymisation: the same row still names the account, the time and the action. You can turn truncation off if you need full addresses.
• Values that look like credentials (password, token, key, secret, nonce and session parameters, JSON web tokens, password hashes and long hex blobs) are replaced with [redacted] before anything is stored, including in attempted usernames.
• Email addresses in user events are masked (a***@e***.com).
• Full IP addresses are only shown to users who hold the IP-viewing capability; everyone else sees a truncated address in the screen and in exports.
• WordPress personal-data exports include that account’s activity records. A personal-data erasure clears the username, user ID and IP from their records and keeps the pseudonymised security history, because deleting it would remove your site’s evidence of account and configuration changes. That decision is stated to the requester in the erasure response.
• Old events are deleted by a daily retention purge; you choose the window (1 to 3650 days, default 90). Deletion is permanent and is itself recorded.
• Roles and usernames can be excluded from logging. A user holding several roles is excluded if any of their roles is on the list. Protected event groups are recorded regardless of exclusions.
• This plugin sets no cookies and adds nothing to your site’s front end.

What this log can and cannot prove

Events are rows in a normal table in your site’s database. Anyone with database access, and any code running with administrator privileges, can edit or delete them. This plugin does not detect that and does not claim to be tamper-proof. If you need evidence that survives a compromise of the site itself, copy it somewhere the site cannot write to.

What the plugin does guarantee, and tests: policy changes, exports, purges and erasures are recorded before or as they happen and cannot be suppressed by the settings they concern; a missing table, a failed write, a failed migration or a failed query is reported as an error on screen and in the suite health panel, never as an empty healthy log.