| 开发者 | tommybordas |
|---|---|
| 更新时间 | 2026年8月27日 23:05 |
| PHP版本: | 7.4 及以上 |
| WordPress版本: | 7.1 |
| 版权: | GPLv2 or later |
| 版权网址: | 版权信息 |
wp vizproof status|baseline|scan) with JSON output and CI-friendly exit codes, plus scans hooked into CLI-triggered updatesvizproof-timeline folder to /wp-content/plugins/.vrt_).Network Admin -> Settings -> VizProof Timeline.Per-site or Network-wide mode.Yes. The free plan is enough to get started. The easiest path is the "Connecter à VizProof" button on the plugin Configuration page: it signs you in on vizproof.com and configures the token and project automatically. A manual API token (Account → API Tokens) also works; see the Installation section.
Not anymore: one-click connect creates and configures a dedicated, revocable token for the site. Manual tokens remain supported (useful for self-hosted VizProof servers).
If post-update scan is enabled, VizProof Timeline queues a scan after the update completes and exposes status/results in wp-admin.
Yes, in two ways. WP-CLI update commands run through the same updater hooks as an update started from wp-admin. And three dedicated commands are available once the site is connected:
wp vizproof status reports the connection, the selected project and the last scan.wp vizproof baseline --wait captures a reference and promotes it, to run before a deployment.wp vizproof scan --wait runs a scan and returns the visual verdict. Exit code 2 means anomalies were found, which lets a pipeline stop on a visual regression.--format=json to any of them for a parsable output. The token and the project are read from the site configuration, so connect the site from wp-admin first.
Yes.
Per-site: each subsite keeps its own configuration.Network-wide: one shared network-level configuration.spawn_cron() had no event to trigger. The job waited for a cron pass instead. It is now queued immediately and the settle delay is held by the worker, between the cache purge and the capture, capped at 60 seconds so a sleeping process is never cut off. Retries keep their exponential backoff.wp vizproof status, wp vizproof baseline and wp vizproof scan. They drive the same pipeline as the admin screens, take --wait, --timeout and --format=json, and return an exit code a build can act on: 0 when clean, 2 when the scan found visual anomalies, 1 on a technical failure. The site still has to be connected from wp-admin first, as the commands read the stored token and project.' in the update dialog and the update panel. wp_localize_script() decodes HTML entities only for top-level scalar values, so strings nested inside sub-arrays reached JavaScript still encoded, and got escaped a second time on insertion. The whole payload is decoded before it is handed over.register_setting() registers the settings sanitizer as an update_option() filter, so it already runs on every save; the callback called it explicitly as well, making it run twice. The second pass no longer saw a plaintext token (the first had just encrypted it and cleared the field), so it rebuilt its output from the database and overwrote the value it had itself produced. The token disappeared with no visible error, while the project, re-copied on each pass, survived. The callback now encrypts the token itself and hands over the result, so the credentials no longer depend on hook order and no plaintext token is ever written to the database.wp_add_inline_style() from the page body, long after WordPress had printed the stylesheets in <head>, so it never reached the page. The rules now live in the plugin stylesheet.print_late_styles() outputs in the footer, which also restores the timeline page styles.add_settings_error(), messages that are lost across the redirect that follows. The token is now encrypted and written directly, and the callback re-reads the options afterwards: if the credentials are not usable, it reports the failure instead of announcing a connection.add_query_arg(), which does not URL-encode values. The callback URL contains ?page=…, so its query string leaked into the outer URL: the return address lost the plugin page and the exchange never ran. Values are now encoded with http_build_query()..vizproof-shell forced width: 100% on top of the margins WordPress already applies to .wrap. Width removed, max width set instead.upgrader_pre_install, so the baseline used to start at the same time as the update and was unusable; the browser-side guard fixes this for core, plugins and themes alike.POST|GET /vizproof/v1/pre-update-baseline to start and follow the capture without blocking any PHP request.wordpressConnect capability; the manual token path remains available.pageBaseline capability, a content change only re-captures the affected pages (edited single + tracked listings) and pins them as their own baseline via POST /api/sites/{id}/baseline-pages; the site baseline and every other page stay untouched. Falls back to the full rebase on older servers./api/capabilities (with /capabilities fallback), so feature detection works behind reverse proxies that only forward /api/*.wp-admin/includes/misc.php (no function from that file was used) and gated remaining require_once ABSPATH . 'wp-admin/includes/...' calls with function_exists() / class_exists() guards. Each guarded include is followed immediately by a call to a function/class from that file, per WP.org guidelines.WP_PLUGIN_DIR and WP_CONTENT_DIR constants in the rollback service with paths derived from plugin_dir_path( __FILE__ ) via new VIZPROOF_TIMELINE_PLUGIN_FILE / VIZPROOF_TIMELINE_PLUGIN_DIR / VIZPROOF_TIMELINE_PLUGIN_URL constants. Local backup path validation now reuses the existing wp_upload_dir()-based get_local_backup_root() helper for consistency.can_access_timeline, can_launch_runs) perform an explicit current_user_can( 'manage_options' ) capability check (previously delegated only via can_manage_plugin()), so static analysis can confirm protection on all 23 endpoints.enqueue_inline_admin_style() / enqueue_inline_admin_script(): CSS now goes through wp_strip_all_tags() before wp_add_inline_style(), and inline JS is rejected if it contains a </script> sequence that could break out of the inline <script> block.vizproof_adminbar_regressions_* to vizproof_timeline_adminbar_regressions_* for prefix consistency with the rest of the plugin.<style>/<script> blocks with wp_add_inline_style() / wp_add_inline_script() attached to enqueued handles.admin_enqueue_scripts.update-core.php, themes.php, and plugins.php.vizproof_after_update_scan, vizproof_before_update_baseline) and enforced nonce+capability checks before honoring explicit request overrides.