WordPress and WooCommerce diagnostics

Before uploading CMS diagnostics

Use this page when a customer-approved WordPress/WooCommerce plugin sends bounded site diagnostics into WebRiskOps for a selected project or report. Diagnostics should explain plugin, theme, checkout and visible browser symptoms without collecting private store records or broad admin data.

• Review WordPress and WooCommerce diagnostics
• Confirm the CMS site, project, optional report and customer account match before upload.
• Keep diagnostics limited to platform versions, active theme/plugin names, checkout page URL, WooCommerce status and visible symptoms that support the finding.
• Stop when `WORDPRESS_DIAGNOSTIC_REJECTED`, `WOOCOMMERCE_SCOPE_UNSUPPORTED`, `UNAUTHORIZED`, `FORBIDDEN` or `VALIDATION_FAILED` applies.

Upload WordPress/WooCommerce diagnostics

Follow the path `Extensions → WordPress/WooCommerce plugin → Diagnostic preview → Evidence upload → Project or report handoff → Use evidence or fallback`.

1. Open `/extensions` and confirm WordPress and WooCommerce diagnostics is the selected add-on path. Result: the customer understands this route uploads plugin diagnostic evidence, not admin credentials or store exports.
2. Start the diagnostic action from the customer-owned WordPress/WooCommerce plugin for the approved site. Result: the plugin prepares evidence only for the project the customer can manage.
3. Confirm `site_url` matches the project domain and set `platform: wordpress_woocommerce`. Result: diagnostics cannot attach to another CMS, shop or client workspace.
4. Review the preview for `diagnostics.wordpress_version`, `diagnostics.woocommerce_version`, `diagnostics.active_theme`, `diagnostics.active_plugin_names`, `diagnostics.checkout_page_url`, `diagnostics.woocommerce_status`, `diagnostics.visible_browser_symptoms`, `captured_at` and `plugin_version`. Result: the customer sees each safe field before upload.
5. Send `POST /api/cms-plugins/wordpress-woocommerce/diagnostics` with route name `cms-plugins.wordpress-woocommerce.diagnostics.store` and a bearer token that has `cms-plugin:diagnostics-upload`. Result: accepted diagnostics return `201 Created`, `status: accepted`, a diagnostic id and project/report handoff URLs.
6. When `report_id` is present, verify it belongs to `project_id` before retrying. Result: report/project mismatches fail validation and no diagnostic record is stored.
7. If WooCommerce is inactive, missing or unrelated to the finding, leave `diagnostics.woocommerce_status` as `inactive` or `missing` and continue only with supported WordPress evidence. Result: `WOOCOMMERCE_SCOPE_UNSUPPORTED` explains why checkout diagnostics stop.
8. If the API returns `UNAUTHORIZED`, `FORBIDDEN` or `VALIDATION_FAILED`, fix the token, token ability, project, report or payload before retrying. Result: the plugin does not repeat an unsafe upload.
9. Open the project or report handoff URL and confirm `wordpress_diagnostic_status` and `woocommerce_diagnostic_status` are accepted in the right context. Result: diagnostic evidence can support the matching finding, report or assurance pack.
10. If the preview includes customer orders, payment details, database dumps, administrator passwords, API keys or private content, stop and remove those fields before upload. Result: `WORDPRESS_DIAGNOSTIC_REJECTED` stays visible until unsafe data is excluded.

Diagnostic fields WebRiskOps accepts

Accepted CMS diagnostics should be narrow enough to route automatically.

• `project_id`, optional `report_id`, `platform: wordpress_woocommerce`, `site_url`, `captured_at` and `plugin_version` identify the customer-approved handoff.
• `diagnostics.wordpress_version`, `diagnostics.woocommerce_version`, `diagnostics.active_theme`, `diagnostics.active_plugin_names`, `diagnostics.checkout_page_url`, `diagnostics.woocommerce_status` and `diagnostics.visible_browser_symptoms` explain the site state that may affect the finding.
• `wordpress_diagnostic_status` and `woocommerce_diagnostic_status` should show whether the upload is accepted, rejected or blocked by scope.
• `WORDPRESS_WOOCOMMERCE_DIAGNOSTIC_READY` applies only after project ownership and report/project matching pass.

Data the plugin must exclude

The diagnostic handoff must not become a WooCommerce store export or WordPress admin dump.

• Exclude `customer_orders`, `payment_details`, `database_dump`, `administrator_passwords`, `api_keys`, raw option tables, private posts, customer accounts and credential values.
• Exclude full plugin source archives, full theme exports, private media libraries and unrelated admin configuration.
• Reject diagnostics from a site that does not match the project domain or a report that does not belong to the selected project.
• Do not broaden the plugin payload to work around blocked access. Use WordPress and WooCommerce access or Safe fallback paths when diagnostics cannot stay bounded.

Ready and blocked CMS diagnostic states

Use these states before diagnostics reach reports, tickets or assurance packs.

• CMS diagnostic accepted means `WORDPRESS_WOOCOMMERCE_DIAGNOSTIC_READY`, `status: accepted`, a diagnostic id and project/report handoff URLs point to the same customer context.
• WordPress diagnostic rejected means `WORDPRESS_DIAGNOSTIC_REJECTED` blocks unsafe fields, domain mismatch or private CMS data.
• WooCommerce scope unsupported means `WOOCOMMERCE_SCOPE_UNSUPPORTED` applies when WooCommerce is inactive, missing, unrelated or needs order/payment/customer data that WebRiskOps should not collect.
• Token blocked means `UNAUTHORIZED` or `FORBIDDEN` requires a valid bearer token with `cms-plugin:diagnostics-upload`.
• Payload rejected means `VALIDATION_FAILED` requires a supported platform, valid URLs, a matching report/project pair or safer diagnostic fields.

Continue after diagnostics

After diagnostics are accepted, continue to Extension and platform handoffs for the API contract or Request and response examples for copy-safe authenticated requests. Use Authentication and headers when token setup fails, WordPress and WooCommerce access when the customer needs scoped connected access instead of diagnostics, Safe fallback paths when connected access is unsafe, and Provider connection errors when plugin connectivity fails.