Collect WordPress diagnostic evidence
Choose the problem you are investigating, then collect the smallest report that can show it. NosHost analyzes the evidence you supply and keeps missing measurements visible.
Start with the manual exporter
Download the WordPress exporter, install it through Plugins, then open Tools, NosHost evidence. Only an administrator can download a report. Collection is manual and sends no data to NosHost.
The exporter includes supported software/update metadata, autoloaded option names and byte sizes, cron hook names and times, grouped Action Scheduler statuses, table size estimates, classic template header versions, HPOS configuration, a bounded product sample and local media metadata. It excludes option values, SQL, job arguments, request bodies, cookies, credentials, raw logs and customer/order records.
Product prices, stock metadata, identifiers, relative paths and plugin names can still be private. Review the JSON before sharing it. Bounded samples and database estimates are marked partial; they cannot certify an entire site.
PHP failures and source compatibility
For a fatal error, select a recent PHP error-log excerpt. Open Input details and select the PHP log format, your public site URL and the collection time in UTC, such as 2026-10-29T06:00:00Z. Use the log-window fields only when you know the actual boundaries. An excerpt is not a complete failure history.
For a PHP upgrade, either upload a small source ZIP to the separately labelled queued scanner or import native PHPCompatibility JSON locally. Direct scanner reports need the target PHP version, completed-scan status and scanned-file count. The bundled scanner uses fixed prerelease rules and never executes your code. Review static findings, then test the complete site on staging.
WooCommerce System Status reports
In WooCommerce, open Status and choose Get System Report. Supported copied text or JSON can provide recorded environment, template and order-storage facts. Select the matching input format and provide the report's site and collection time. A System Status report does not contain checkout traces, query timings or proof of working extension compatibility.
Runtime observations and controlled tests
- Queries and AJAX: use measured counts and timings from a profiler such as Query Monitor or your staging request instrumentation. Record the request scope. Remove SQL values, request bodies and authentication data.
- Object cache: collect actual hit/miss counters for a defined request sample. An enabled cache flag alone is insufficient evidence of effectiveness.
- REST and checkout: record endpoint paths, expected and actual statuses, response types and error codes from an explicit controlled test. Use synthetic checkout data and a test gateway. Do not include card details or customers.
- Cart isolation: record two isolated test sessions with synthetic cart fingerprints and observed cache headers. Public responses with the same content do not prove a leak.
- Plugin conflicts: repeat the same staging scenario with an explicit control and one changed combination. Keep environment and failure signatures comparable. NosHost does not switch plugins for you.
- Integrity: use official WordPress core/plugin checksum verification results. A file without an official reference stays unverified; checksums do not establish absence of malware.
- Migration: use scoped reference counts and selected media observations. Check destination behavior separately. Reports do not execute replacements or remove files.
Use the documented report format
Open a tool's worked example and choose Download example inputs. It contains the exact fields used by that analyzer, with visibly synthetic values. You can load it back into the same tool. For your own structured report, use format: noshost-wordpress-evidence, version: 1, the UTC collection time, site metadata and the relevant section.
Each section records status, reason, rows, summary and truncated. Use unavailable for measurements you do not have and partial for samples. Uploaded conclusions are not accepted as proof. The analyzer calculates findings from the recorded fields.
Each input is limited to 2 MiB, 500 rows per section, 30 nesting levels and 50,000 values. Reports older than seven days are flagged as stale. Comparisons require matching site and scope, with an earlier baseline. Unsupported versions and malformed fields are rejected.
After you repair an issue
Repeat the same observation and compare the evidence. Download the derived report or evidence ZIP if you need to keep it. Local inputs remain on your device; source uploads have the separate queue and backup retention described in the privacy notice.