After a security update, teams often test one Administrator upload and call the media path healthy. That misses the exact boundary that matters: Author, Editor, custom editorial roles, multisite restrictions, REST clients, mobile apps, PDF preview generation, and plugins that attach files to forms or products. The regression test should confirm both function and least privilege.
Use this for publishers, membership sites, WooCommerce stores, learning platforms, multisite networks, and custom editorial workflows where non-administrators upload or transform media.
Quick answer
Create named test users for each real role, define approved file types and expected derivative files, then test browser, block editor, classic editor, REST, mobile, and plugin upload paths that the site actually uses. Confirm expected files succeed, forbidden types fail without side effects, thumbnails and PDF previews are correct, and no role gained broader access after the update.
What to check first
- Export role and capability assignments before the update, including custom roles and multisite upload restrictions.
- List required MIME types, maximum sizes, image dimensions, metadata, thumbnail sizes, PDF previews, and storage destinations.
- Create one safe fixture per approved and denied file class, with predictable dimensions, names, and hashes.
- Test the exact browser, editor, REST, mobile, WooCommerce, form, and import paths used by each role.
- Review application, PHP, ImageMagick, Ghostscript, storage, and audit logs for errors, retries, or unexpected child processes.
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 |
|---|
| Author image | JPEG through block editor | Attachment and expected thumbnails created |
| Editor PDF | PDF requiring preview | Attachment succeeds and preview follows policy |
| Contributor | JPEG through Media Library | Denied without creating a partial file |
| REST client | Application password with scoped user | Only approved endpoint and MIME succeed |
Decision rule
Approve when every required role and upload path succeeds for approved fixtures, denied roles and types fail cleanly, derivative output matches policy, and logs show no unexplained process or file side effect.
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.
- Restore only the capabilities required by the written editorial workflow.
- Correct MIME, memory, temporary directory, package, or storage problems one layer at a time.
- Keep denied types blocked and confirm failed attempts leave no public partial object.
- Update automation for role fixtures and required media derivatives.
- Retest on the public production path and remove temporary users, files, and logging.
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Restore only the capabilities required by the written editorial workflow. | Export role and capability assignments before the update, including custom roles and multisite upload restrictions. | Approved roles can upload only the file classes required for their work. |
| Correct MIME, memory, temporary directory, package, or storage problems one layer at a time. | List required MIME types, maximum sizes, image dimensions, metadata, thumbnail sizes, PDF previews, and storage destinations. | Denied fixtures create no attachment, public object, orphaned derivative, or sensitive error. |
| Keep denied types blocked and confirm failed attempts leave no public partial object. | Create one safe fixture per approved and denied file class, with predictable dimensions, names, and hashes. | Expected thumbnails and PDF previews exist with correct dimensions and storage permissions. |
| Update automation for role fixtures and required media derivatives. | Test the exact browser, editor, REST, mobile, WooCommerce, form, and import paths used by each role. | Browser, REST, plugin, and mobile paths return consistent ownership and audit evidence. |
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
role,path,file,expected,attachment,derivatives,result
author,block-editor,photo.jpg,allow,created,all,pass
editor,media-library,guide.pdf,allow,created,preview,pass
contributor,media-library,photo.jpg,deny,none,none,pass
shop_manager,product,manual.pdf,allow,created,preview,review
Production verification checklist
- Approved roles can upload only the file classes required for their work.
- Denied fixtures create no attachment, public object, orphaned derivative, or sensitive error.
- Expected thumbnails and PDF previews exist with correct dimensions and storage permissions.
- Browser, REST, plugin, and mobile paths return consistent ownership and audit evidence.
Why this usually happens
- Administrator tests bypass many role, ownership, and capability checks that normal editors encounter.
- Plugins can register custom MIME types or upload endpoints that do not behave like the core Media Library.
- Image and PDF derivatives depend on server packages, memory limits, temporary storage, and filesystem ownership as well as WordPress core.
Field notes
- Use generated or public fixtures, never a customer document, in screenshots and shared test records.
- Delete fixtures and test users after evidence is retained.
- Record derivative filenames and hashes so a missing thumbnail is visible rather than inferred from the editor screen.
Mistakes to avoid
- Do not change several production layers at once. Preserve the failing evidence and isolate one variable per test.
- Do not treat a green screen, successful request, or quiet log as proof that the customer outcome is correct.
- Do not leave debug logs, broad credentials, test orders, temporary roles, or firewall exceptions active after verification.
- Do not close the work without recording versions, fixture IDs, UTC timestamps, owner, result, and rollback point.
What to tell the client or owner
Give the owner the affected versions, exact fixture, stable IDs, UTC timeline, before and after evidence, decision, rollback point, unresolved risks, and next review date.
Questions teams ask during testing
Can this be tested on staging?
Start on staging with production-like versions, cache, data shape, roles, integrations, and server packages. Finish with one controlled production fixture when the result depends on real email routing, edge cache, crawler access, payment callbacks, or advertising diagnostics.
What evidence should be retained?
Keep the smallest useful evidence set: exact versions, stable IDs, UTC timestamps, sanitized request or log excerpts, expected result, actual result, decision, and final verification. Redact customer data, secrets, order keys, and full click identifiers.
When should the change be rolled back?
Roll back when a revenue, privacy, security, publishing, or lead path fails and the cause cannot be isolated inside the approved maintenance window. Preserve the failed fixture before rollback so the next attempt starts with facts.
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, run a WordPress media regression test.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references