The developer asked for a full store diagnostic file

Define the fault the diagnostic must answer

Write down the symptom, the affected page, when it occurred and the steps that reproduce it. Then ask the developer which specific facts they need: a plugin version, a server setting, a template override list or a particular log entry around the failure time. A request for a full export is a starting point for that conversation, not an approval to send one.

This framing protects both sides. The developer gets material targeted at the fault instead of a large file to dig through, and the merchant avoids disclosing environment detail that has nothing to do with the problem. If the developer cannot say what they need yet, the first deliverable is a fault description, not a data export.

Open the file before anyone forwards it

WooCommerce documents its system status report as containing software versions, server settings, site URLs, paths, active plugins and theme information, and its logs can contain additional diagnostics. That is a description of contents, not a sanitization promise. Read the actual report or log section by section before deciding what any recipient may see.

Pay particular attention to extension logs, which can record order references, customer details, request data or tokens depending on the plugin. There is no general rule that a status page or log is safe because the platform produced it. Anything nobody has reviewed stays out of the package by default.

Build the minimal manifest

Copy the facts that answer the fault into a manifest you control: the relevant versions, the specific settings, and short log excerpts around the failure window. Redact the sensitive parts of an excerpt while keeping the surrounding context the developer needs, such as timestamps and error codes. The UK ICO's data-minimisation guidance frames personal information as adequate, relevant and limited to what the purpose requires; it is a UK principle and its guidance is under review, but the discipline travels well: the fault defines the boundary.

Standard exclusions belong in the manifest too, recorded as deliberate decisions: customer records, order details beyond a neutral reference, credentials, API keys, tokens, full raw logs and anything unrelated to the reported fault. If a needed fact cannot be produced without exposing excluded material, flag it for the technical owner instead of working around the boundary.

Confirm recipient, channel and authority

Verify who will receive the package and through which channel. Use the authorized support route for that developer or agency rather than a convenient personal address, and record who on the merchant side approved the send. A diagnostic file sent to the wrong mailbox is a disclosure in its own right.

Keep this decision separate from access decisions. Sending configuration facts does not grant account access, and a developer who needs to act inside an account follows the authorized invitation or credential route for that work. Secrets never travel inside a diagnostic package, whatever the file is called.

Record what was sent and close the loop

Treat the manifest as the send record: date, recipient, contents summary and the fault it addresses. When the diagnosis arrives, link the outcome back to the manifest so the business knows what the shared material actually resolved and whether any further sharing is justified.

If you want help framing the website side of the fault for a provider or reviewer, a Prism consultation can be scoped to the pages and questions involved. Describe the website, the research-only catalog and the fault in ordinary language, with no diagnostic files, customer records or credentials in the public form. Scope, responsibilities, fees and terms are agreed before work.

Diagnostic-sharing manifest

Complete one manifest per fault and per recipient. If a requested item cannot be produced without excluded material, mark it unresolved rather than improvising. The final column is left for your dated record and approver.

Worksheet entries are not submitted by Prism’s worksheet and are not saved by the site. Use record types, availability, anonymized observations, or match/mismatch results. Do not enter government identifiers, customer names or addresses, customer messages, receipt-access links, card or bank details, passwords, or keys. Send sensitive documents only through the provider’s verified secure channel.

These are temporary notes. Leaving or reloading this page may clear them. Worksheet entries are not sent automatically. If you copy notes into the consultation message and submit the form, Prism receives them as part of your request.