by
Dragon Core
0 (0 reviews)
Dragon Activity Log – Audit Log, User Activity Tracking & Security Audit Trail
A tamper-evident activity log for WordPress. See who changed what, when, and from where, with field-level before/after detail.
Dragon Activity Log ranks #63,224 among WordPress.org plugins with 0+ active installations, is #3,855 of 5,058 in the Security category, and was last updated Oct 10, 2026. Data from WordPress.org, refreshed twice daily — see methodology.
Compatible with WP 7.1.4
v1.1.0
Current Version v1.1.0
Updated 4 weeks ago
Last Update on 10 Oct, 2026
Refreshed 1 week ago
Last Refreshed on
#3,855 of 5,058 in Security
Actively maintained
Rank
#63,224
—
No change
Active Installs
0+
-100%
KW Avg Position
125
—
No change
Downloads
548
+1 today
Support Resolved
0%
—
No change
Rating
0%
Review 0 out of 5
0
(0 reviews)
Next Milestone 10
0+
10+
35,656
Ranks to Climb
-
Growth Needed
8,000,000
Active Installs
Pro
Unlock Exact Install Count
See the precise estimated active installs for this plugin, calculated from real-time ranking data.
- Exact install estimates within tiers
- Track install growth over time
- Milestone progress predictions
Need 8 more installs to reach 10+
Rank Changes
Current
#63,224
Change
Best
#
Downloads Growth
Downloads
Growth
Peak
Upgrade to Pro
Unlock 30-day, 90-day, and yearly download history charts with a Pro subscription.
Upgrade NowReviews & Ratings
0.0
0 reviews
Overall
0%
5
0
(0%)
4
0
(0%)
3
0
(0%)
2
0
(0%)
1
0
(0%)
Track This Plugin
Get detailed analytics, keyword tracking, and position alerts delivered to your inbox.
Start Tracking FreePlugin Details
- Version
- 1.1.0
- Last Updated
- Oct 10, 2026
- Requires WP
- 6.2+
- Tested Up To
- 7.1.4
- PHP Version
- 8.0 or higher
- Author
- Dragon Core
Support & Rating
- Rating
- ☆ ☆ ☆ ☆ ☆ 0
- Reviews
- 0
- Support Threads
- 0
- Resolved
- 0%
Keywords
Upgrade to Pro
Unlock keyword rankings, search positions, and detailed analytics with a Pro subscription.
Upgrade NowSimilar Plugins
Adminify – White Label, Admin Menu Editor, Login Customizer
6K+ installs
#2,757
Master Addons for Elementor – Elementor Addons, Widgets, Mega Menu Builder, Popup Builder, Widget Builder & Template Kits
30K+ installs
#1,015
LiteSpeed Cache
7M+ installs
#5
Akismet Anti-spam: Spam Protection
5M+ installs
#8
Wordfence Security – Firewall, Malware Scan, and Login Security
5M+ installs
#11
Really Simple Security – Simple and Performant Security (formerly Really Simple SSL)
3M+ installs
#18
Hostinger Tools
3M+ installs
#20
WPS Hide Login
2M+ installs
#27
Limit Login Attempts Security - Login Security, 2FA, Firewall, Brute Force Prevention
1M+ installs
#33
WP Super Cache
1M+ installs
#36
Frequently Asked Questions
Common questions about Dragon Activity Log – Audit Log, User Activity Tracking & Security Audit Trail
Logging is a single indexed database write per action. The tamper-evidence hashing runs separately: an hourly WP-Cron job, plus a short end-of-request pass on roughly one request in twenty (capped at 200 events and two seconds) after the page has been generated.
Each event stores a SHA-256 hash computed over its own contents plus the previous event's hash, forming a chain. Editing or deleting any event breaks the chain from that point on, and the integrity check reports the first broken link. This is tamper evidence: it detects edits and deletions made outside the plugin, it does not prevent someone with database access from making them. Use it alongside normal access control and backups.
Two things, by design. First, events are hashed into the chain by a background pass (hourly, plus a short end-of-request pass), so a row deleted before it is sealed leaves no trace; on a quiet site without WP-Cron traffic that window can be up to an hour. Second, someone with write access to your database who also recomputes every later hash and the stored chain head can hide an edit from the self-check. That is what the off-site anchor is for: compare the log against an anchor you received earlier and such a rewrite is caught. Clearing the log or erasing someone's data rebuilds the chain; the event that records it says whether the chain was intact beforehand.
On the Settings tab, choose daily or weekly. On that schedule the plugin seals the chain and emails the chain head (an event number and a hash, never any event data) to the address you choose; ideally one outside this site. You can also have it posted to an https webhook you control, signed with a per-site secret. Keep those messages. At any time, paste an anchor reference into Integrity > "Compare with an anchor" (or run wp dragon-activity-log verify --anchor=<reference>): the plugin recomputes the chain up to that event and confirms it still produces the anchored hash. "Send anchor now" takes one immediately. When the anchored events are no longer in the log because retention cleanup, Clear log or a privacy erasure removed them, the check cannot be completed. It says so and names the event in the log that recorded the removal, with its date, so you can confirm it was one you made. It never reports such an anchor as a match. On the command line, a match exits with 0, an anchor that cannot be checked exits with 2, and anything else (a mismatch, a broken chain, a busy or unreadable log) exits with 1. The webhook must use https, and redirects are not followed. The signing secret is stored encrypted and shown on the Settings tab so your receiver can verify the X-Dragon-Signature header.
Open "Full details" on a log row. A changed setting can be put back to its previous value, and a role change can be undone (the roles it took away are given back and the roles it gave are taken away, nothing else). The rollback is refused, with the reason, when the setting or the user's roles have changed again since the event, when it was already rolled back, when the previous value held a hidden secret or data that cannot be stored exactly, when you are not allowed to give that role, or when it would take away your own permission to change roles. A change that created a setting is not rolled back (that would delete the setting), and neither is a change that deleted one (a deleted setting is not re-created). After a permalink setting (the permalink structure, category base or tag base) is restored, WordPress rebuilds its permalink rules on the next page load; when the restore leaves plain permalinks, the dialog asks you to save Settings > Permalinks once so the server's rewrite rules are written too. Restoring a setting needs the Manage options permission (on a network, the super admin's Manage network options), and undoing a role change also needs permission to change that user's role. Every rollback is recorded in the log, even when your role is excluded from logging. Post edits and trashed posts are not rolled back here: use WordPress's own revisions and Trash. Rollback is available for changes recorded since version 1.1.0, because the previous value is kept from that version on.
Switch them on under Settings > Security alerts and pick which ones you want. A new-address alert is sent when a user logs in from an address that is not among the last 20 they used on this site; their first login only starts that list. It uses the address the log records, so with IP capture off there are no new-address alerts and with anonymization on only a new masked address counts. A burst alert is sent when one address reaches the number of failed logins you set (5 by default) inside the window you set (5 minutes by default); an IPv6 address counts together with the rest of its /64 network. At most one burst alert is sent per window for the whole site: addresses that reach the limit in the meantime are listed in the next burst alert (up to 10, plus a count of the rest), and every failed login is in the log anyway. To count the attempts, the connecting address is kept as a hashed key that expires with the window, even with IP capture off; the alert, and the list held for the next one, show addresses only when capture is on. An administrator alert is sent when a user is given the administrator role, or super admin on a network. Alerts go to the site admin email unless you list up to 10 addresses, and are sent at the end of the request through your site's normal email delivery. A failed delivery is recorded in the log, at most once an hour.
Not to us or to any third party. Events are stored in dedicated wp_dal_events and wp_dal_snapshots tables in your own database. The only things that ever leave your site are the optional off-site anchor described above (an event number and a hash), to the email address and webhook you configure, and, if you switch them on, security alert emails to the addresses you choose.
By default the connecting address (REMOTE_ADDR). Proxy headers such as X-Forwarded-For are ignored unless you enable "Trust proxy headers", because visitors can forge them. You can also anonymize IP addresses or turn capture off entirely.
Yes. Set the retention to 0 days on the Settings tab.
Editor autosaves, background (cron) option writes other than core settings, the plugin's own bookkeeping options, first/last name, nickname and biography changes (email, display name, URL, password and roles are covered), network-wide (multisite) settings, and the success of each package in a bulk plugin or theme update (the update run is recorded per requested package). Settings that plugins use for their own bookkeeping are skipped too: names containing _cache or _last_, or ending in _version, db_version or _lock, the options WordPress writes during a theme switch, and the routine licence re-checks that Dragon Core's paid add-ons save. When "Trust proxy headers" is on, the address appended by the single proxy in front of the site is used (a port it appends is ignored); chains of several proxies are not walked.
