Skip to content
KAZCODE Universal Storage KAZCODE Universal Storage

Verify Media

Verification checks each of an attachment’s expected files — the original and every generated image size — directly against your storage with a HEAD request, rather than trusting a status flag that might be stale.

Before you begin

A tested storage profile.

Steps

  • Single attachment: in Universal Storage → Media, use the row action to verify one attachment, or run:

    Terminal window
    wp universal-storage verify --attachment-id=ID --verbose

  • Everything: run

    Terminal window
    wp universal-storage verify

    or use the batch Verify mode on Universal Storage → Migration.

Verify it worked

Verification reports each expected object separately. In 1.0.1 those results are classified more precisely:

  • Present — the owning Storage Profile confirmed the object exists.
  • Confirmed missing — the provider returned a definitive missing-object response, such as 404, NoSuchKey, or an equivalent NotFound result.
  • Unknown / provider error — KAZCODE could not safely determine whether the object exists because of authentication/403 failures, throttling/429, timeouts, 5xx provider errors, DNS/network/TLS failures, or similar transient conditions. These are not recorded as confirmed missing media.
  • Size mismatch — the object exists, but its remote Content-Length does not match the expected file size when that size is known.

When KAZCODE says a normal remote cleanup is safe, it does not mean byte-for-byte content checksum verification. In 1.0.1 destructive local cleanup requires sufficient remote verification; when an expected file size is known, the remote size must match before the local copy can be removed.

Troubleshooting

Verification reports missing files that you’re sure are uploaded — for inventory-bound existing objects, verification uses the persisted Storage Profile that owns the object, not whichever profile is currently selected as the default upload target. A deleted or missing referenced profile is a profile configuration/integrity problem. Authentication failures, outages, timeouts, and throttling are reported as unknown/provider errors rather than confirmed missing media. See URLs not updating for a related symptom.

Bad metadata — if an attachment is missing its _wp_attached_file postmeta or has no resolvable file list at all, verification reports this distinctly rather than treating it as a normal missing-file case; this usually points to a corrupted or manually-edited attachment record, not a storage problem.