WordPress 7.1 expands Playlist block workflows while many production sites serve audio from private object storage through signed CDN URLs. A saved track URL can outlive its signature, a page cache can preserve an expired query string, or a player can retry the same denied byte range. The playlist looks healthy when published and then fails hours later with 403 responses, stalled waveforms, or tracks that work only for the editor.
Use this for membership, course, podcast, event, and private-media sites using S3, CloudFront, signed cookies, signed URLs, media offload plugins, byte-range requests, page caches, or long-lived prerendered HTML.
Quick answer
Create a short-lived synthetic audio signature, publish one Playlist, and record page-cache TTL, signed-URL expiry, player request time, Range header, edge status, origin status, and refresh behavior. Test before expiry, just after expiry, after page-cache HIT, in a second browser, and after seeking. Do not save a short-lived signed URL as permanent block content. Resolve a durable media ID to a fresh authorized URL at render or playback time, or align cache and signature lifetimes with a documented security policy.
What to check first
- Record the stored block attribute, attachment ID, generated media URL, signature expiry, page-cache TTL, CDN TTL, and player request time.
- Test initial load, play, pause, seek, next track, reload, cache HIT, signed-cookie and signed-URL modes before and after expiry.
- Capture Range, If-Range, status, Content-Range, Accept-Ranges, Cache-Control, Age, edge result, origin result, and response body hash.
- Compare editor, administrator, member, expired member, anonymous, mobile, background tab, and a second browser session.
- Verify logs, analytics, and support traces distinguish authorization expiry from CORS, missing file, unsupported codec, and range failures.
Why this usually happens
- The block stores a generated signed URL instead of a durable attachment or media identifier.
- Page-cache lifetime exceeds the signature lifetime and serves an expired query string.
- Player retry logic reuses a denied range URL without requesting fresh authorization.
- Signed-cookie, CORS, and byte-range policies differ between editor and public hostnames.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
curl -sS -D media.headers -H 'Range: bytes=0-1023' \
'https://media.example/audio/test.mp3?Expires=FIXTURE' \
-o /dev/null
record:
signature_expires_at: 2026-08-23T15:00:00Z
page_cache_ttl: 3600
expected_refresh: before_playback
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Store a durable media or attachment identifier rather than a short-lived signed URL in content. | Record the stored block attribute, attachment ID, generated media URL, signature expiry, page-cache TTL, CDN TTL, and player request time. | Authorized playback survives page-cache and signature-expiry boundaries. |
| Generate fresh authorization at render or playback time for the current user and resource. | Test initial load, play, pause, seek, next track, reload, cache HIT, signed-cookie and signed-URL modes before and after expiry. | Range responses remain correct after URL or cookie refresh. |
| Align page, edge, and player cache lifetimes with signature and membership policy. | Capture Range, If-Range, status, Content-Range, Accept-Ranges, Cache-Control, Age, edge result, origin result, and response body hash. | Expired and anonymous users cannot renew or reuse private media access. |
| Preserve byte-range, CORS, content type, filename, and seek behavior on refreshed URLs. | Compare editor, administrator, member, expired member, anonymous, mobile, background tab, and a second browser session. | Logs distinguish expiry, range, CORS, codec, and missing-object failures. |
Decision rule
Ship private Playlist playback when authorized users can start and seek across cache and signature boundaries, expired users cannot renew access, and content never depends permanently on a short-lived URL.
Test scenarios to run
Run the same controlled fixture across these branches. Write down the expected result before testing so a surprising response is easy to identify.
| Scenario | Fixture | Expected result |
|---|
| Before expiry | Cold member playback | 200 or 206 and audio plays |
| After expiry | Cached page with old URL | Fresh authorization or clear denial |
| Seek | Range after signature refresh | Correct 206 Content-Range |
| Expired member | Old page and player state | No renewed private access |
Safe fix order
Use a sequence that makes each result easy to prove. Stop when new evidence changes the scope or owner of the problem.
- Store a durable media or attachment identifier rather than a short-lived signed URL in content.
- Generate fresh authorization at render or playback time for the current user and resource.
- Align page, edge, and player cache lifetimes with signature and membership policy.
- Preserve byte-range, CORS, content type, filename, and seek behavior on refreshed URLs.
- Monitor 403, 416, stalled playback, refresh rate, and unauthorized renewal after release.
Production verification checklist
- Authorized playback survives page-cache and signature-expiry boundaries.
- Range responses remain correct after URL or cookie refresh.
- Expired and anonymous users cannot renew or reuse private media access.
- Logs distinguish expiry, range, CORS, codec, and missing-object failures.
What to tell the client or owner
Give the site owner the affected versions, exact synthetic fixture, UTC timeline, before and after evidence, cause class, decision, rollback point, unresolved risks, and next review date. State which measurements prove success and which observation window remains open.
Mistakes to avoid
- Changing production before recording exact versions, UTC timestamps, settings, stable fixture IDs, and a reproducible baseline.
- Treating one successful screen as proof that keyboard access, APIs, caches, jobs, reports, analytics, and downstream records agree.
- Testing only an administrator session instead of the devices, roles, networks, locales, and failure branches customers use.
- Closing the work without a named owner, rollback point, observation window, and contextual incoming link from an established guide.
Questions teams ask during testing
Can this be tested on production?
Use production for read-only checks and one narrow synthetic fixture that cannot charge a card, send customer email, expose personal data, or change inventory. Run upgrades, package changes, cache changes, and destructive repairs on staging first.
What evidence should the test report keep?
Keep exact versions, UTC timestamps, stable synthetic IDs, expected and actual results, screenshots or response excerpts, the decision owner, rollback point, and final verification. Redact credentials, tokens, customer data, private addresses, and infrastructure details.
How long should the observation window stay open?
Keep it open long enough to include at least one cache cycle, scheduled job cycle, and representative traffic period. For release changes, include logged-in and logged-out use plus the first real operational handoff.
When is the task complete?
Complete it when the primary user path passes, downstream records reconcile, failure branches are understood, monitoring is active, and an established owner page links to this guide in context.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, security, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.
If this is active on a production site, repair private WordPress media playback.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references