Skip to content

URLs Not Updating

Symptom

Media Library or frontend URLs still point at your old delivery location (or at your local site) after changing a CDN hostname, storage profile, or provider.

How URLs actually work in this plugin

_wp_attached_file is always stored as a relative path, never a URL. For an existing offloaded object, KAZCODE first resolves the authoritative PRESENT object inventory row and the Storage Profile that owns that object. The delivery URL is then built from that profile’s current delivery/CDN configuration.

This means:

  • Changing the CDN/Base URL on the same owning Storage Profile should affect newly-rendered pages without a database rewrite.
  • Changing the default upload profile affects where new uploads are written; it does not move historical objects or make older attachments resolve through the new default profile.
  • If URLs still look wrong, the most common cause is a caching layer (page cache, CDN cache, browser cache) serving previously-rendered HTML rather than the plugin serving a stale value.

Steps to diagnose

  1. Confirm the setting actually saved — reload Universal Storage → Storage and check the delivery URL/CDN field.
  2. Check a freshly-loaded, uncached page (private/incognito window, or a cache-busted query string) rather than a cached one.
  3. Run wp universal-storage verify --attachment-id=ID --verbose to see what the plugin itself currently resolves for that attachment.

Private media

If you’re using signed URLs for a private bucket (private media delivery), URLs include a time-limited signature rather than being permanently cacheable — this is expected behavior, not a bug, and it’s why private-media URLs look different from public ones.