Title: Dragon Activity Log – Audit Log, User Activity Tracking & Security Audit Trail
Author: Dragon Core
Published: Сентябрь 8, 2026-ж.
Last modified: Октябрь 10, 2026-ж.
---
Плагиндерди издөө
# Dragon Activity Log – Audit Log, User Activity Tracking & Security Audit Trail
Автору [Dragon Core](https://profiles.wordpress.org/dragoncoreltd/)
[Жүктөө](https://downloads.wordpress.org/plugin/dragon-activity-log.1.1.0.zip)
* [Кенен маалымат](https://ky.wordpress.org/plugins/dragon-activity-log/#description)
* [Сын-пикирлер](https://ky.wordpress.org/plugins/dragon-activity-log/#reviews)
* [Орнотуу](https://ky.wordpress.org/plugins/dragon-activity-log/#installation)
* [Development](https://ky.wordpress.org/plugins/dragon-activity-log/#developers)
[Колдоо](https://wordpress.org/support/plugin/dragon-activity-log/)
## Сүрөттөө
Dragon Activity Log records what happens on your WordPress site in a fast, searchable
audit trail that lives in its own database table. Unlike a plain event list, it
shows the **field-level change** for the fields listed below (the old role and the
new role, the old setting value and the new one, a renamed title or slug), and it
links every event to the one before it with a SHA-256 hash so that a later edit
or deletion of the log can be detected.
Everything in this plugin is free and fully functional: every event type, no cap
on the number of events stored, any retention window including “keep forever”, all
filters and search, live updates, integrity verification, one-click rollback of
settings and role changes, full before/after diffs, security alert emails, CSV and
JSON export, WooCommerce events, and the WP-CLI commands. (Individual values in
the change detail of a log row are shortened at 500 characters; the full diff keeps
the whole value.)
#### Why Dragon Activity Log
* **Field-level change detail** – before and after values for post title, slug
and excerpt, user email, display name, URL and roles, media title, caption and
alt text, and single-value settings (array settings show their item count, and
a post body is flagged as changed in the row)
* **Full before/after diffs** – “Full details” on a post or setting event opens
a side-by-side diff of the whole post content, title, excerpt and status, or
of the whole setting value, kept from the moment of the change
* **One-click rollback** – put a changed setting back to its previous value, or
undo a role change, from the same dialog. A rollback only runs while the setting
or the user’s roles still hold exactly what the event left behind, follows WordPress’s
own rules for who may change roles, and is itself recorded in the chained log
* **Security alerts by email** – a login from an IP address the user has not used
before, a burst of failed logins from one address, and a user made administrator(
or super admin on a network), sent to the site admin email or a list of addresses
you choose. Off until you switch them on
* **CSV and JSON export** – download the events that match the filters on screen;
spreadsheet formulas in exported cells are neutralised, and every export is itself
logged
* **WooCommerce events** – new orders, order status changes, stock quantity and
stock status changes, and new coupons, recorded while WooCommerce is active
* **Tamper-evident hash chain** – every event is chained to the previous one; one
click checks the chain (up to 25 seconds in the browser; the WP-CLI command checks
a log of any size end to end) and reports the first event whose link no longer
matches
* **Off-site anchor** – email (and optionally post to a signed webhook) the chain
head daily or weekly, then compare the log against any anchor later: proof that
the log was not rewritten, even by someone with database access
* **Site Health** – an integrity test and an anchor test on the Site Health screen,
plus a debug-information section
* **Fast and lean** – events live in their own indexed table, never in your posts
table, and are pruned automatically on the retention window you choose
* **Live activity stream** – new activity appears on the log screen as it happens
* **Privacy controls** – capture, anonymize or skip IP addresses, and exclude trusted
roles from logging
* **Privacy tools integration** – events caused by a user, events about their account,
failed logins against their username or email, and events about comments they
wrote (guests included) are covered by WordPress personal data export and erasure
requests
* **WP-CLI** – `wp dragon-activity-log list`, `prune`, `anchor` and `verify`
#### What gets logged
* **Logins** – successful logins, logouts, failed logins, password resets
* **Users** – registration, profile changes, role changes, deletion, and on multisite
removal from a site and super admin grants and revocations
* **Content** – posts, pages and custom post types: create, edit, status change,
trash, restore, delete
* **Plugins and themes** – activate, deactivate, install, update (and a failed
single update), delete, switch
* **Settings** – WordPress and plugin option changes and deletions, with secret-
shaped values redacted (option writes made by background cron tasks are skipped
unless they touch core settings)
* **Media** – uploads, title, caption and alt text edits, deletions
* **Taxonomies** – term create, edit and delete for categories, tags, menus and
custom taxonomies
* **Comments** – submitted, approved, unapproved, spam, trashed, deleted
* **Core** – WordPress core updates and content exports
* **WooCommerce** (while it is active) – new orders, order status changes, product
stock quantity and stock status changes, new coupons. Orders are no longer also
logged as posts on stores that keep orders in the posts table, and a new coupon
is logged once as a coupon (its later edits as post events). Store events recorded
with no logged-in user (a guest checkout, a payment gateway callback or a scheduled
task) keep no IP address
* **The log itself** – clearing, retention cleanup, anchors, exports, rollbacks
and failed alert deliveries
#### WP-CLI
* `wp dragon-activity-log list [--limit=] [--event=]`
* `wp dragon-activity-log prune`
* `wp dragon-activity-log anchor` – send an off-site anchor now
* `wp dragon-activity-log verify [--anchor=]`
### External services
This plugin does not connect to any external service of ours or of any third party.
All logging, hashing and verification runs on your own server.
The optional off-site anchor sends the chain head (an event number, a hash, your
site URL and a timestamp; never any event data) to a destination you configure:
by email through your site’s normal mail delivery, and, only if you enter a webhook
URL, by an HTTPS POST to that URL. Nothing is sent unless you turn the anchor on.
The optional security alerts send an email through your site’s normal mail delivery
to the site admin email or the addresses you list. An alert names the site, the
user concerned, the acting user or the attempted username, and the IP addresses
involved (a burst alert can list several), and links to the activity log. Nothing
is sent unless you turn the alerts on.
### Credits
The WordPress.org listing icon is drawn with glyphs from Lucide (https://lucide.
dev), ISC License. Copyright (c) for portions of Lucide are held by Cole Bemis 2013-
2022 as part of Feather (https://feathericons.com, MIT License). All other copyright(
c) for Lucide are held by Lucide Contributors 2022. The plugin itself does not include
these icons.
### Privacy Policy
Dragon Activity Log stores activity data locally in your WordPress database, including
usernames, IP addresses (unless disabled or anonymized), and details of changes
made on your site. It does not send any data to third parties. IP capture can be
disabled or anonymized in the settings. WooCommerce events recorded with no logged-
in user (a guest checkout, a payment gateway callback or a scheduled task) are stored
without an IP address, because they cannot be matched to a person’s email address.
WordPress personal data export and erasure requests are matched by email address
and cover events caused by the user, events about their account, failed logins against
their username or email, and events about comments written with that email (so guest
commenters are covered too). Events about comments that have since been deleted
can no longer be matched to an email address.
## Скриншоттор
[⌊The activity log: field-level change detail, severity pills and live updates.⌉⌊
The activity log: field-level change detail, severity pills and live updates.⌉[
The activity log: field-level change detail, severity pills and live updates.
[⌊Filtering the log by object type, event, severity and date.⌉⌊Filtering the log
by object type, event, severity and date.⌉[
Filtering the log by object type, event, severity and date.
[⌊Integrity tab: verifying the tamper-evidence hash chain and anchoring the chain
head off-site.⌉⌊Integrity tab: verifying the tamper-evidence hash chain and anchoring
the chain head off-site.⌉[
Integrity tab: verifying the tamper-evidence hash chain and anchoring the chain
head off-site.
[⌊Settings tab: retention, IP privacy controls, chain anchor and excluded roles.⌉⌊
Settings tab: retention, IP privacy controls, chain anchor and excluded roles.⌉[
Settings tab: retention, IP privacy controls, chain anchor and excluded roles.
## Орнотуу
1. Upload the `dragon-activity-log` folder to `/wp-content/plugins/`, or install it
from the Plugins screen.
2. Activate the plugin through the Plugins screen in WordPress.
3. Go to Tools > Activity Log. Events start recording immediately; the Settings tab
holds retention and privacy options.
## FAQ.KG
### Does this slow down my site?
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.
### How does the tamper-evidence work?
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.
### What can the integrity check not catch?
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.
### How does the off-site anchor work?
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=`): 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.
### What can be rolled back?
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.
### How do the security alerts work?
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.
### Does the plugin send data anywhere?
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.
### Which IP address is recorded?
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.
### Can I keep events forever?
Yes. Set the retention to 0 days on the Settings tab.
### What is not logged?
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.
### What is redacted?
Option and field names that look like secrets are recorded as “[redacted]” and their
values are never read by the plugin: anything containing password, pass, pwd, secret,
token, auth, nonce, salt, private, api, license, licence or credential, or containing
_key. Password changes are recorded as “(changed)”, never the hash. In the log row,
a post body is only flagged as changed and settings stored as JSON or serialized
text are summarised like arrays.
For the full diff and rollback, a copy of the state before and after the change
is kept in the separate `wp_dal_snapshots` table: for posts the title, content,
excerpt, status, type and slug; for settings the whole value. Settings whose name
looks like a secret (the list above, plus key) and the anchor webhook address are
never copied. Inside a setting’s value, and before a change is handed to other code
listening for events, nested keys with a secret-shaped name segment (for example`
api_key`, `smtp_pwd`, `client_secret`, `access_token`, `Authorization`) are replaced
by “[redacted]”, and a value holding such a key is never rolled back. Serialized
values that refer to themselves are redacted whole, and nested keys ending in key,
pass or passphrase count as secret too. A side larger than 256 KB is not kept. On
a network, the full value of a setting is shown only to super admins. Each copy
is deleted with its event: by retention cleanup, Clear log or a privacy erasure.
The anchor webhook address is recorded as its host only. The username typed into
a failed login is recorded as typed. For the new-address alert, the last 20 login
addresses of each user are kept as user data on each site; they are included in
personal data exports and removed by erasure requests.
## Сын-пикирлер
There are no reviews for this plugin.
## Contributors & Developers
“Dragon Activity Log – Audit Log, User Activity Tracking & Security Audit Trail”
is open source software. The following people have contributed to this plugin.
Мүчөлөрү
* [ Dragon Core ](https://profiles.wordpress.org/dragoncoreltd/)
[Translate “Dragon Activity Log – Audit Log, User Activity Tracking & Security Audit Trail” into your language.](https://translate.wordpress.org/projects/wp-plugins/dragon-activity-log)
### Interested in development?
[Browse the code](https://plugins.trac.wordpress.org/browser/dragon-activity-log/),
check out the [SVN repository](https://plugins.svn.wordpress.org/dragon-activity-log/),
or subscribe to the [development log](https://plugins.trac.wordpress.org/log/dragon-activity-log/)
by [RSS](https://plugins.trac.wordpress.org/log/dragon-activity-log/?limit=100&mode=stop_on_copy&format=rss).
## Өзгөртүүлөр
#### 1.1.0
* New: one-click rollback. “Full details” on a setting change or a role change
offers to put it back. It runs only while the setting or the user’s roles still
hold exactly what the event left behind, follows WordPress’s rules for who may
change roles (you cannot take away your own), and records a “Change rolled back”
event in the chained log, even when your role is excluded from logging. A change
that created or deleted a setting is not rolled back, and the dialog says so.
Restoring a permalink setting has WordPress rebuild its permalink rules (leaving
plain permalinks also needs one save of Settings > Permalinks, and the dialog
says so).
* New: full before/after diffs. Post and setting events keep a copy of the state
before and after the change, so “Full details” shows the whole content or setting
value side by side. Copies are deleted with their event.
* New: security alerts by email for a login from a new IP address, a burst of failed
logins and a user made administrator or super admin. Off until you switch them
on; recipients default to the site admin email. At most one burst alert is sent
per window for the whole site, listing the other addresses that reached the limit
since the previous one; IPv6 addresses are counted per /64 network.
* New: CSV and JSON export of the events matching the current filters. Cells that
would start a spreadsheet formula are neutralised, and each export is logged.
* New: WooCommerce events: new orders, order status changes, stock quantity and
status changes, and new coupons. Orders are no longer also logged as posts on
stores with legacy order storage, a new coupon is logged once, and creating a
product is not logged as a stock change. Store events recorded with no logged-
in user (such as a guest checkout) keep no IP address. Declared compatible with
High-Performance Order Storage.
* These features were the Dragon Activity Log Pro add-on and are now part of this
plugin. If the add-on is still active, deactivate it: until you do, the built-
in versions stay off and the log screen says so. Nothing is carried over from
the add-on: switch the security alerts on again under Settings after deactivating
it, and diffs and rollback cover changes recorded from then on (the add-on’s
earlier diffs are not carried over).
* The links and notes pointing to the Pro add-on are gone.
#### 1.0.21
* Fixed: someone with database access could hide an edited event from both the
integrity check and the off-site anchor by changing one setting. The chain now
refuses that, and anchors whose events were removed are only explained by a matching
event recorded in the sealed log itself.
* Retention cleanup checks the chain before it deletes anything, records every
cleanup that removes events as an event, and never removes events that are not
sealed yet. If the chain is broken, cleanup pauses and the Settings tab and Site
Health say so.
* An anchor that can no longer be checked says why and names the event that explains
it; it is never shown as a match. The command line exits with 2 in that case
and with 1 for a failed or busy check. “Beyond the current chain” is gone: a
truncated log now reads as broken.
* A database read error during a check is reported as such, not as tampering or
a timeout. A check that finished on its last batch no longer reads as out of
time.
* The anchor webhook signing secret is stored encrypted, redirects are not followed,
and the last anchor shows whether it was delivered.
* Logging: failed single plugin and theme updates, removal from a network site
and super admin grants are recorded; settings saved without a real change, a
theme switch’s own bookkeeping and Dragon Pro licence re-checks no longer add
rows; a role grant before a role change is kept; settings changed late in a request
are recorded.
* Secrets: credentials inside serialized settings are no longer stored, and nested
secret keys are redacted before a change reaches an add-on. The anchor webhook
address is recorded as its host only.
* Settings: an invalid retention, anchor email or trusted proxy entry is rejected
with a message and the previous value is kept, and a setting that could not be
saved is reported.
* Privacy export: events about a person that someone else caused no longer include
that other person’s IP address or username.
* Uninstall deletes data only when the opt-in is clearly on (1, true, yes or on),
not for “false” or “no”.
* Fixed: a search for “0” filtered nothing, very long role names lost the event,`
list --format=ids` printed “Array”, and a proxy that appends a port recorded
its own address.
* Each admin action checks its own security token and your permission, and every
submitted value goes through WordPress’s own sanitizers.
* A plugin update is logged under the plugin’s new name even when the plugin list
was read earlier in the same request.
* Fixed: saving settings with a malformed webhook field no longer writes a PHP
warning to the debug log.
#### 1.0.20
* Fixed: since 1.0.11, a change to a setting that holds a secret (an API key, token,
licence key or password) was not logged at all. It is now logged as “Changed (
value hidden)”, and the secret itself is never stored.
* Setting a secret and then setting it back in the same request is not logged,
as there was no net change.
#### 1.0.19
* Anchor checks only accept a clear or privacy erasure recorded inside the sealed
log itself, so a gap cannot be hidden by editing a setting. Rewrites still show
as a mismatch.
* An anchor due while the log is being resealed is retried 15 minutes later instead
of being skipped.
* Anchors made before a Clear log or an erasure report the events as rebuilt or
erased, not rewritten.
* Sites upgrading straight from 1.0.0 keep their retention and exclusion settings.
#### 1.0.18
* Anchor checks now say when older events were removed by retention cleanup or
a privacy erasure, instead of reporting a broken chain.
* Clear, rebuild and erasure events show readable details.
* Settings that other Dragon plugins use for their own bookkeeping are no longer
logged as setting changes.
* Log times follow your site’s date format.
#### 1.0.17
* Every screen, email and alert is now translatable, so community translations
from translate.wordpress.org cover the whole plugin. Counts use proper plural
forms, and numbers and dates follow your site’s language.
* Clear, rebuild and privacy-erasure events show readable details in the log and
the live stream.
* The personal-data export lists changes as readable lines instead of raw data.
* Log times follow your site’s date format.
#### 1.0.16
* Fixed: when one of this plugin’s scheduled tasks needed re-creating, it was scheduled
before WordPress had finished loading, which made WordPress log “translation
loading was triggered too early” notices that named other plugins. Scheduling
now waits until WordPress is ready. The notices only appeared with debug logging
switched on.
#### 1.0.15
* An “Upgrade to Pro” link on the Plugins screen, a one-line pointer at the foot
of the plugin’s own screens, and a single dismissible note once the plugin has
done its job. All three disappear when the Pro add-on is active; nothing in the
free plugin is locked or changed.
#### 1.0.14
* Listing only: a clearer WordPress.org title and tags, so people searching for
an audit log or user activity trail can find the plugin. No functional changes.
#### 1.0.13
* Adds a one-time WordPress.org review prompt on the Activity Log screen after
your first integrity check or anchor. No other changes.
#### 1.0.12
* New: off-site chain anchor. Email the chain head daily or weekly (optionally
also to a signed webhook you control), send one on demand, and compare the log
against any anchor from the Integrity tab or WP-CLI (`verify --anchor=`). Each anchor is recorded in the log itself.
* New: Site Health integration. An “Activity log integrity” test, an “off-site
anchor” test, and a Dragon Activity Log section under Info.
#### 1.0.11
* Secret-shaped settings (API keys, tokens, passwords, licences) are no longer
read at all when they change or are deleted: the event still records that the
setting changed, but the value is dropped at the source and is not passed to
add-ons either.
#### 1.0.10
* Integrity chain hardening: the hash now covers the event id and uses an unambiguous
encoding, so a row cannot be renumbered or have field boundaries shifted unnoticed.
Existing chains are rebuilt once after updating (the log itself is untouched).
* Verification now says exactly what it checked: it reports events not yet sealed,
tells you when it ran out of time on a very large log, and no longer reports “
intact” when another process held the lock.
* Clearing the log or erasing someone’s data checks the chain first and records
the outcome; an erasure that removes nothing leaves the chain alone.
* Retention cleanup removes a contiguous block of oldest events and re-anchors
after every batch, so an interrupted run can never leave the chain unverifiable;“
Run cleanup now” applies the number in the retention field, saved or not, and
says so.
* Optional list of trusted proxy addresses (IPs or CIDR ranges): when set, proxy
headers are honoured only for connections from those addresses.
* Screen Options on the log now work: choose how many events to show per page and
hide columns; live-stream rows respect hidden columns, keep the page at its size
and update the item count.
* Hosts whose database cannot provide advisory locks (for example Galera clusters)
fall back to an option-row lock, so sealing and cleanup keep running there.
* The background sealer re-reads the chain state from the database before every
write, so a persistent object cache cannot hand it a stale copy.
* The events table is created on first load for any site that never ran activation,
not only on admin visits.
* Live-stream rows now show the object type and the field-level change table, exactly
like rows rendered on load; a log cleared from another tab reloads open log screens;
a lost session shows a message instead of silently stopping; typing a page number
in the pagination box works.
* Publishing a draft while editing it records one event carrying both the status
change and the field changes (previously the field changes were lost). Role additions
and removals, and network user deletions, are recorded.
* Less noise: editor autosaves of a draft, and the two option writes behind a theme
switch, no longer add rows (the theme switch itself is still logged). On a network,
option changes made while switched to another site are recorded on that site.
* JSON-encoded settings values are summarised like arrays instead of being stored
verbatim, so a credential nested inside one never reaches the log.
* Comment status events use translated labels; setting an image’s alt text for
the first time logs once.
* Accessibility: the active tab is announced, and change-detail field names are
proper row headers.
* A missing events table (restored database, manual drop) is recreated on the next
request instead of surfacing database errors.
#### 1.0.9
* The log, integrity check and settings now live on one Tools > Activity Log screen
with tabs instead of three separate Tools menu entries. Old links redirect.
* Live updates pause automatically while a filter, search or a page other than
the first is active, so filtered views are no longer interrupted by unfiltered
rows.
* Severity is shown with the Dragon design system’s tinted pills and row markers,
and the integrity and cleanup messages are now translatable.
* New “Run cleanup now” button on the Settings tab applies the retention window
immediately.
* Events are no longer recorded before WordPress has finished loading, which fixes
a “translation loading triggered too early” notice when another plugin crashed
during startup.
* Logins, logouts and password resets are now attributed to the user concerned
instead of “System / Guest” (WordPress fires those hooks before it sets the current
user), so role exclusions apply to them and privacy export and erasure cover
them.
* Personal data export and erasure now include events about the user’s account
and failed logins against their username, not only events they caused.
* Media alt text changes are recorded with the old and new value; previously that
field never showed a difference.
* Changes to the plugin’s own settings are logged, and clearing the log records
a “log cleared” event as the first row of the new chain.
* Date filters use the site’s timezone; the retention field only accepts whole
days; the daily cleanup and chain reset now coordinate with the background sealer
so a rare overlap cannot leave the chain unverifiable.
* The events table is created on sites that never ran activation (network activation
only runs it on the main site) and schema updates apply on upgrade.
* Uninstalling with “Delete all data” opted in now also removes that setting itself,
and on a network it runs for every site.
* Network activation creates the events table on every site, and new network sites
get one automatically.
* Fresh plugin and theme installs are recorded (previously only updates were);
deleted options are recorded too.
* The live stream delivers bursts larger than one page across consecutive polls
instead of skipping the middle, and guest rows show the “System / Guest” label.
* The migration of settings from the 1.0.0 option names has been removed; sites
still on 1.0.0 start with default settings after updating.
#### 1.0.8
* Retention: the retention setting now accepts 0 to keep events forever. Any retention
window, or none at all, is available in the free plugin.
#### 1.0.7
* Security: integrity verification now detects truncation of the newest sealed
log entries (deleting the tail no longer passes as “verified”).
#### 1.0.6
* Compatibility: tested up to WordPress 7.1.
* Housekeeping: corrected the contributor name in the plugin readme.
#### 1.0.5
* Accessibility: screen-reader labels on the log filters and table header scopes
throughout.
#### 1.0.4
* Data safety: uninstalling the plugin no longer deletes its data unless you explicitly
opt in first. A reinstall now picks up exactly where you left off. (New setting.)
#### 1.0.3
* New look: the Dragon design system arrives. A consistent Dragon Core header,
cleaner tables, and unified status colours. Purely visual; no behaviour changes.
#### 1.0.2
* Fix: the integrity-chain state is now carried safely on a deactivate then reactivate
update (it could previously reset).
#### 1.0.1
* Renamed all option, hook, function and constant prefixes to the unique `dragonactivitylog_`/`
DRAGONACTIVITYLOG_` prefix. Existing settings and the integrity-chain state are
migrated automatically on update; the event table is unaffected.
#### 1.0.0
* Initial release.
## Мета
* Нуска **1.1.0**
* Акыркы жаңыртуу **5 күн мурун**
* Активдүү орнотуулар **Fewer than 10**
* WordPress нускасы ** 6.2 же андан жогору **
* Tested up to **7.1.3**
* PHP нускасы ** 8.0 же андан жогору **
* Тил
* [English (US)](https://wordpress.org/plugins/dragon-activity-log/)
* Тег:
* [Activity Log](https://ky.wordpress.org/plugins/tags/activity-log/)[audit log](https://ky.wordpress.org/plugins/tags/audit-log/)
[audit trail](https://ky.wordpress.org/plugins/tags/audit-trail/)[security](https://ky.wordpress.org/plugins/tags/security/)
[user activity](https://ky.wordpress.org/plugins/tags/user-activity/)
* [Advanced View](https://ky.wordpress.org/plugins/dragon-activity-log/advanced/)
## Рейтинг
Азырынча эч кандай сын-пикир жок.
[Your review](https://wordpress.org/support/plugin/dragon-activity-log/reviews/#new-post)
[See all reviews](https://wordpress.org/support/plugin/dragon-activity-log/reviews/)
## Мүчөлөрү
* [ Dragon Core ](https://profiles.wordpress.org/dragoncoreltd/)
## Колдоо
Комментарийлер барбы? Жардам керекпи?
[Колдоо форумун көрүү](https://wordpress.org/support/plugin/dragon-activity-log/)