Dragon Compliance Pro
Your licence now keeps working after it lapses. Pro features stay on for every activated site; renewing restores updates and support on the same key.
- The licence screen shows Lapsed, and what that means, instead of a red Expired.
- The Dragon Core vulnerability feed follows the same rule as updates: it is served while the licence is current, and the free plugin's own feed source takes over if it lapses.
- New versions are fetched only while the licence is current. Nothing else changes.
Fixes an evidence-sealing bug that could report the chain as tampered after a failed write, and a scheduled report that stayed unsent for 28 days after a mail failure.
What's fixed in 1.0.5
- A failed seal write no longer breaks the evidence chain. If the database refused to store an entry's hash, the sealer carried on and chained the next entry to a hash that was never written, so Seal & verify reported the log as BROKEN from then on. Sealing now stops at the first entry whose hash does not land, resumes from that entry on the next run, and the Snapshots tab reports the write failure separately from a real tamper verdict.
- Scheduled reports are retried after a mail failure. The report marked itself as sent before the email went out, so one failed send silently skipped the monthly report for another 28 days. The sent timestamp is now recorded only after at least one recipient accepted the mail. A report that reached nobody is logged in the evidence log as
report_send_failedand sent again on the next run. - The snapshots table schema version is stamped only after the table exists, so a failed creation is retried (every 10 minutes, with an admin notice) rather than recorded as complete.
- New
dragoncompliancepro_seal_failedanddragoncompliancepro_report_failedactions fire on those failures, for anyone routing them elsewhere. - A sealing failure can no longer be reported as a verified chain. If both the seal and the record of its failure were refused, the chain was left unsealed and then verified as valid with nothing checked, which read as an all-clear. A sealing failure is now reported from the run itself, and "valid" is never shown for a chain with no sealed entries.
- A broken chain is no longer hidden by a sealing failure. When verification found a genuinely modified entry in the same run that failed to seal a newer one, only the sealing failure was shown. Both are now reported, and the broken entry is never replaced by the one that failed to seal.
- A scheduled report that cannot record its send time says so. The send time is what stops the report going out again, so losing it silently re-sent the report on the next run. The mail is still reported as sent, and the bookkeeping failure is reported separately.
- Sites already missing the snapshots table are repaired on upgrade. The recorded schema version is no longer trusted on its own; the table is confirmed to exist first.
No settings or data changes otherwise.
Zero-configuration vulnerability monitoring: licensed sites now get the vulnerability feed from Dragon Core — no Wordfence account or API token needed.
= 1.0.4 =
- New: with a valid licence the vulnerability feed is fetched from Dragon Core (api.dragoncore.ltd) using your licence key. Delete your Wordfence token or never create one — monitoring stays active.
- If the licence lapses the plugin falls back to the free plugin's own Wordfence token automatically.
- Requires Dragon Compliance 1.0.6.
Security update: alert webhook secrets are authenticated at rest and Slack alerts no longer follow redirects.
= 1.0.3 =
- Security: the alert signing secret is encrypted at rest with authenticated encryption; Slack alerts disable redirects for parity with the signed webhook.
- Hardening: a stored licence is re-checked for a usable key before trusting the cached result.
Tested and verified on WordPress 7.1.
- Compatibility: tested up to WordPress 7.1.
Evidence verification and CSV export now stream in batches, staying fast and memory-safe no matter how large your evidence log grows.
Dragon Compliance Pro: the evidence pack your auditor asks for.
White-label reports, SBOM snapshots and diffs with SPDX export, a hash-chained tamper-evident evidence log, time-to-patch metrics, alert routing to email, signed webhooks or Slack, and a dedicated NIS2 view.