ChangeTrace
| 开发者 | changetrace |
|---|---|
| 更新时间 | 2026年10月12日 23:38 |
| PHP版本: | 8.1 及以上 |
| WordPress版本: | 7.1 |
| 版权: | GPLv2 or later |
| 版权网址: | 版权信息 |
详情介绍:
ChangeTrace watches your WordPress and WooCommerce site for meaningful changes and
errors and sends them to the ChangeTrace service (a cloud dashboard at
https://app.change-trace.com), where they are correlated against metrics to surface
the most likely cause of a movement, with evidence.
This plugin is the on-site agent. It does nothing until you connect it: you paste a
site token generated in the ChangeTrace dashboard, and only then does the plugin begin
sending data to the ChangeTrace API.
What it collects (once connected):
- A one-time baseline snapshot on connect: your active plugins and theme and their versions, plus WordPress, PHP, and WooCommerce versions.
- An hourly heartbeat so the dashboard knows the site is alive.
- Change detection — plugins installed, activated, deactivated, updated or removed; theme changed or updated (including the parent of a child theme); WordPress core updated; PHP version changed.
- Watched site options — a short, fixed allowlist (permalink structure, siteurl, home, active plugins, template, stylesheet, blog_public, core auto-update policy, and WooCommerce payment gateway settings). Only the option NAME and a summary of its shape (type, size/length, and a short one-way hash) are sent — never the option's value.
- Error capture — PHP fatals/errors (shutdown + error handler, fails silently), frontend JS errors (window.onerror, unhandled rejections, failed/5xx fetch & XHR; sampled), and 5xx/timeouts on WordPress's outbound HTTP and its own REST API.
- Commerce activity — if WooCommerce or Easy Digital Downloads is active: orders, failed orders, failed payments, refunds, and checkouts started/failed. Each carries the order id, the amount, the store currency, the payment method and the order status. No customer names, addresses, emails or line items are collected.
安装:
- Install and activate the plugin from the Plugins screen (or upload the folder to
wp-content/plugins/). - Open ChangeTrace in the admin menu.
- Create an account at https://app.change-trace.com, generate a site token (it starts
with
site_tok_), and paste it into the connect screen.
wp-config.php
via CHANGETRACE_API_BASE_URL, CHANGETRACE_APP_URL, CHANGETRACE_PRIVACY_URL, and
CHANGETRACE_TERMS_URL, or via the matching changetrace_* filters.常见问题:
Do I need a ChangeTrace account?
Yes. ChangeTrace is a hosted service. The plugin is the on-site agent and needs a site token from https://app.change-trace.com to do anything.
Does the plugin send any data before I connect it?
No. Nothing leaves your site until you paste a valid site token and connect. See the "External services" section for what is sent afterward.
Is personal data sent to ChangeTrace?
Error payloads are PII-stripped (emails, credentials, form values, card numbers) and size-capped before being queued and sent. The baseline snapshot contains software versions and plugin/theme names, not visitor data. A front-end JavaScript error is the one event that carries anything about a visitor: the browser's user-agent string and the address of the page the error happened on, with the query string stripped. No form values, cookies or identifiers are read. Commerce events carry order totals, currency, payment method and order status, plus the order id — never customer names, addresses, emails, phone numbers or line items. Fields a customer typed into checkout are discarded outright rather than filtered. Watched-option values are never transmitted; only the option name and a shape summary.
Does the plugin slow my site down?
Collection is event-driven and the handlers are wrapped so a collector error can never break a page, a checkout or a purchase. Work on the request path is limited to appending to a bounded local queue. Sending happens on WP-Cron, not during a page view. Frontend JavaScript error capture is sampled (about 25% of page loads, capped at 5 errors per load). The plugin does not measure page speed on your server; page performance is measured by ChangeTrace from outside your hosting.
How do I stop sending data?
Deactivate the plugin, or disconnect the site from the ChangeTrace connect screen. You can also delete the plugin; it cleans up its stored token and options on uninstall.
Can I point the plugin at a self-hosted or staging environment?
Yes. Define CHANGETRACE_API_BASE_URL (and optionally CHANGETRACE_APP_URL) in
wp-config.php.
更新日志:
0.4.2 - 2026-10-12
- New: when a child theme is active, an update to its parent theme is now reported as its own theme update. The child's version does not move when the parent updates, so this was missed. A theme switch to a child theme also names the parent, so errors from the parent's files can be traced to the switch.
- Fix: plugin deactivations are recorded after WordPress saves the active-plugins list, not before. They now share a timestamp with the matching settings change, so an incident's likely causes list the deactivation once instead of twice.
- Fix: front-end JavaScript error capture stopped working on sites with a full-page cache. The REST nonce was printed into the page and served from the cache long after it expired, so every report was rejected and silently dropped. The handler now refetches a current nonce once per page load and retries. Cached pages keep serving the old handler until the cache is purged, so the fix takes effect from the first purge after upgrading.
- Fix: the error-capture handler no longer routes its own reports through its own failed request detector, which could make a failing endpoint report itself.
- Change: the PHP error and shutdown handlers are installed only while the site is connected. Sites that never connected were paying for capture whose output was discarded.
- Change: the data disclosure on the connect screen, in the suggested privacy-policy text and in this readme now states that a JavaScript error report includes the visiting browser's user-agent string and the page address with the query string removed. No collection behaviour changed — this was always sent and is now named.
- New: plugin installs are reported as their own
plugin_installedevent. Previously a plugin that appeared on disk without being activated was absorbed silently into the baseline and could never be offered as a possible cause. - New: theme updates are detected. Only a switch to a different theme was reported before, so updating the active theme — one of the most common ways to break a site — produced no event at all.
- New: changes to a short, fixed allowlist of high-signal site options are reported
(
option_changed): permalink structure, siteurl, home, active plugins, template, stylesheet, blog_public, core auto-update policy, and WooCommerce payment gateway settings. Only the option NAME and a summary of its shape (type, size/length and a short one-way hash) are sent — never the option's value, because several of these hold live API keys. No other option is monitored. - New: event types are declared in one place (
includes/Support/Event_Types.php) and compared against the ChangeTrace API's own registry by an automated check, so the plugin cannot ship a type the service does not understand. - Change: readme and the connect screen now disclose WooCommerce/EDD commerce data (order id, total, currency, payment method, status, refunds, checkout events), which the plugin has sent since 0.2.0 but did not list. No collection behaviour changed.
- Fix: the connect screen and the suggested privacy-policy text claimed the plugin collects performance metrics. It does not and never has — page performance is measured by ChangeTrace from outside your hosting, with nothing running in visitors' browsers.
- Fix: WooCommerce and EDD event collectors did not register their hooks when the plugin loaded before WooCommerce/EDD (the usual load order), so orders, refunds, and failed payments were never captured. Hook registration is now deferred until WooCommerce/EDD is available.
- Fix: capture WooCommerce orders at checkout placement via
woocommerce_checkout_order_processedand the block/Store-APIwoocommerce_store_api_checkout_order_processed, instead ofwoocommerce_new_order, which fired at draft creation on block checkout and recorded phantom orders.
- Error capture: PHP fatals/errors (shutdown + error handler, fails silently), frontend JS errors (window.onerror, unhandled rejections, failed/5xx fetch & XHR; sampled), and 5xx/timeouts on WordPress's outbound HTTP + own REST API.
- All error payloads are PII-stripped (emails, credentials, form values, card numbers) and size-capped before queuing.
- Baseline snapshot (plugins, theme, WP/PHP/WooCommerce versions) sent once on connect.
- Bounded local event queue (drops oldest when full) with a scheduled batch sender (every 5 minutes) that retries with exponential backoff on failure.
- Remote config fetch (enabled modules, sampling, heartbeat interval).
- Connection layer: connect screen, secure token storage, hourly heartbeat.
- Initial skeleton. Boots and activates; no detectors wired up yet.