When testing WordPress 7.2 media uploads, run the same image through the Media Library and the block editor. A successful editor upload does not prove that the Library screen, its progress handling or a media plugin's integration works. Compare the request paths and the resulting attachment before changing PHP limits.
WordPress 7.2 is in beta as of October 26, 2026. Keep these tests on isolated staging. This is a proposed diagnostic procedure, not a claim that HandL WP has reproduced a defect on your installation.
Why a New Screen-by-Screen Test Matters
The Beta 1 announcement expands client-side processing into the Media Library. The implementation ticket documents REST creation, derivative sideloading and finalization, with fallback behavior. Later changes extend the original grid-only proposal to the Add New Media File screen. Do not use the first ticket paragraph as the complete final scope.
Treat the actual network trace on your exact build as evidence of which path ran. Browser support, file type and environment matter. A classic uploader request is not, by itself, an upload failure.
Prepare Three Known Images
Choose a modest JPEG, a PNG with transparency and one format your team actually receives from customers or photographers. Use synthetic or approved test files, not confidential uploads. Give each file an unmistakable name and record its dimensions and size before starting.
Keep the source files unchanged. If you resize one between attempts, label it as a separate fixture. Otherwise a smaller file succeeding can be mistaken for a browser or WordPress fix.
Use a staging account with the intended upload permission. Keep public access restricted and prevent media-offload integrations from writing to production destinations. If the staging and live sites share storage, resolve that first using the shared media bucket checklist.
Run a Small Comparison Matrix
Test one file at a time before trying a multi-file drop. Record the screen, browser version and exact core build for each attempt.
| Surface |
What to record |
| Media Library grid |
Progress, final tile, attachment ID and request sequence |
| Add New Media File |
Success or error notice, retry behavior and saved attachment |
| Block editor Image block |
Upload completion, saved draft and preview |
| Second supported browser |
Whether the same fixture completes by the same or another path |
Do not assume every browser should generate identical requests. Compare the user-visible outcome and the saved media as well as the transport. Keep a successful case beside a failed one so differences are visible.
Upload completion has separate attachment, derivative and page-render checks. Explanatory acceptance ledger.
Find the First Incomplete Stage
In the Network panel, preserve the log and look for the attachment creation request. On the client-processing path, also examine sideload and finalize requests for the returned attachment ID. Record response status and a redacted error code. Never paste cookies or authorization headers into a public support thread.
If creation fails, investigate that response before looking for thumbnails that cannot yet exist. If creation succeeds but later operations fail, record the attachment ID and inspect its actual state. Avoid repeatedly uploading the same file until the Library contains a confusing set of duplicates.
A 100% progress indicator is only one observation. Open the attachment, confirm its dimensions and inspect the sizes used on the destination page. Save and preview a disposable page with the image at the layout sizes your theme uses. A full-size file may render while a requested thumbnail is missing.
Separate File, Browser and Site Problems
If one file fails everywhere, compare it with a simple known-good JPEG before changing configuration. If one browser fails across all fixtures, capture its console error and check whether the relevant processing resources loaded. If only one admin screen fails, focus on integrations and scripts attached to that screen.
Use the existing client-media CSP and fallback audit when a browser policy blocks processing. Do not weaken site-wide security headers simply to make an experiment pass. A narrow, reviewed staging change should have a clear reason and a recorded result.
For a plugin conflict, disable only the suspected integration on the test copy and repeat the same fixture. Keep the original failure trace. If the plugin controls remote storage, verify that a successful retry also produces the intended accessible file, not just a local database record.
Close the Test With a Usable Attachment
Acceptance should include a completed upload, an identifiable attachment, the needed image sizes and a saved page that displays the expected image. Also test a deliberately invalid file: the user should get a useful error and be able to retry without losing unrelated work.
Record failures as a screen, fixture and first failing operation, rather than simply “media broken.” Keep the beta result separate from production readiness. For problems already affecting a live supported release, the general media upload diagnosis is the starting point. HandL WP can review a failed media workflow with a redacted trace and an approved sample file.
References checked October 26, 2026. Procedures and synthetic diagrams are explanatory, not claims of customer testing.