Add a safe preview workflow for Assets Manager changes

Problem

Assets Manager changes are powerful, but today a user generally has to save a rule before they can confirm whether disabling a script or stylesheet is safe for the current page. That raises the perceived risk of using one of Perform's most differentiated features, especially on stores, lead-generation pages, builder-heavy pages, and client sites where a broken interaction can hurt conversions.

Why this matters

A safer experimentation flow can improve adoption and retention by making asset optimization feel reversible and testable instead of fragile. It also creates a clearer support story: users can prove what changed, compare before/after behavior, and roll back a risky rule without digging through saved option arrays.

For WordPress.org ranking and website traffic, this strengthens Perform's public positioning around lightweight, practical optimization while reducing support friction from accidental asset unloads.

Proposed scope

• Add a preview or dry-run mode for Assets Manager changes before persisting them.
• Show a clear summary of pending changes, including affected handles, scope, and whether each rule disables or re-enables an asset.
• Provide a one-click revert path for the most recent saved Assets Manager change set.
• Make the UI explain that preview mode applies only to the current administrator session/request until saved.
• Keep the first pass focused on Assets Manager rules; do not broaden into full settings revisions unless needed.

Acceptance criteria

• An administrator can test an Assets Manager change on the current page without permanently saving it.
• Preview requests are capability-gated and cannot affect anonymous visitors or other users.
• The save flow shows a concise summary before persisting changed asset rules.
• The most recent saved Assets Manager change set can be reverted from the UI.
• Existing perform_assets_manager_options data remains backward compatible.
• Unit or integration coverage verifies preview isolation, save behavior, and revert behavior.

Validation / proof needed

• Verify preview mode on a page with at least one CSS handle and one JS handle.
• Verify preview mode does not change saved options until the user explicitly saves.
• Verify revert restores the prior rule state after a saved change.
• Run targeted PHP syntax/tests for changed Assets Manager code and the admin smoke path if UI changes are included.

Implementation notes

• src/Modules/Assets/AssetsManager.php already centralizes save and runtime rule evaluation for perform_assets_manager_options.
• Avoid introducing a second permanent rules engine; prefer a request/session-scoped preview overlay and a bounded previous-state snapshot.
• Keep runtime checks cheap because asset evaluation runs through frontend loader filters.
• Any UI should follow the existing WordPress component/admin patterns used in the settings experience.

Compatibility, security, and privacy considerations

• Preserve existing option keys and rule semantics.
• Gate preview, save, and revert paths behind manage_options and nonce checks.
• Do not expose filesystem paths, secrets, or full environment details in the preview summary.
• Avoid applying preview rules to logged-out visitors, cached public responses, REST, cron, ajax, or CLI contexts.

Start in src/Modules/Assets/AssetsManager.php, tracing how perform_assets_manager_options is saved and how runtime rules are evaluated, then inspect the existing WordPress admin settings patterns. Define coverage for capability and nonce checks, preview isolation, save compatibility, and reverting the prior state; done includes targeted PHP tests or syntax checks and validation with CSS and JS handles.