A 410 response from load-scripts.php or load-styles.php on a WordPress 7.2 test installation can be intentional. The old admin asset concatenation endpoints were retired. Find out why something still requests them before changing firewall rules or reinstalling WordPress.
This guide is for administrators and plugin developers testing the 7.2 beta. It is not advice to upgrade a production site to beta software. The official Beta 1 announcement explicitly limits that release to testing.
What Changed, and What Did Not
The final retirement change recorded in WordPress ticket 57548 serves scripts and styles individually, makes the old loaders return 410, and stops reading CONCATENATE_SCRIPTS. Earlier discussion in the same ticket describes transitional behavior. Do not mistake an intermediate proposal for the final change.
A retired loader returning Gone does not establish that the dashboard is broken. Conversely, a usable-looking dashboard does not prove that every plugin screen works. Separate the obsolete request from the user action that fails.
Start With the Request That Breaks the Screen
On staging, open browser developer tools before loading the affected admin page. Preserve the Network log across navigation. Filter to CSS and JavaScript, then identify the first failed resource needed by the screen. Open its Initiator details to see whether a document, plugin script or redirect generated the URL.
Record the exact core build, screen URL without sensitive query values, resource path, status, response type and initiator. A screenshot of a red row without its path is not enough to decide which layer to fix.
| Observation |
Next question |
| Old loader returns 410; current assets succeed |
Is a stale reference still present, and does it affect a task? |
| Current stylesheet returns 404 |
Does the requested file match this deployed build? |
| Current script returns HTML |
Did authentication, a rewrite or an error handler replace the asset? |
| Current asset returns 403 |
Which access rule rejected this specific request? |
| All files load but a control fails |
What is the first relevant JavaScript error? |
A failed retired loader and a failed current stylesheet need different investigations. Synthetic diagnostic worksheet.
Trace Stale References Without Replacing Core Files
First compare a normal navigation with a reload that bypasses the browser cache. If only one browser profile fails, repeat with extensions disabled in a separate test profile. That narrows the investigation; it is not a reason to clear every user's session.
If the reference persists, inspect the rendered admin document and the identified plugin's code. A developer can search a local copy of wp-content for the two loader names and CONCATENATE_SCRIPTS. Classify every hit: an actual generated URL matters differently from a comment, old troubleshooting article or unused compatibility branch.
Do not copy load-scripts.php from an older WordPress version into the new installation. That creates a mixed core deployment and conceals the producer of the stale reference. Likewise, do not disable the firewall globally because one obsolete endpoint is unavailable.
Test the Real Workflow, Not Just the Dashboard
Use the same staging account and permissions that produced the failure. Test opening the affected settings page, changing a harmless test value, saving it and reloading it. For an editor problem, save a disposable draft and confirm its content survives a reload. Avoid using real customer records as test fixtures.
Compare with the last supported build in a separate snapshot. Keep plugins, browser and test data fixed where practical. If changing several components fixes the screen, you still do not know which change mattered.
For a suspected plugin, reproduce with only its necessary dependencies on the test copy. Record the smallest configuration that fails. A report saying which plugin emitted which retired URL is far more actionable than asking a vendor to investigate all of wp-admin.
Check Cold and Repeat Visits Separately
More individual requests do not automatically mean a slower experience. Measure the actual admin task with the same browser, network and cache conditions. Record a cold visit separately from a repeat visit, and note whether a login or another admin screen came first. Do not compare one cold beta run with a warm baseline run and label the difference a regression.
You do not need a performance benchmark to establish a functional failure. A required file returning HTML or a save button failing consistently is enough to open a focused compatibility investigation.
When the Fix Is Ready
Accept the repair when the obsolete reference has an explained owner, required current assets return the expected content, and the affected task works after a fresh navigation and reload. Preserve a small redacted evidence record for the next beta or release candidate.
For problems on other WordPress versions, start with the broader unstyled admin dashboard checklist. Use the WordPress 7.2 staging plan to keep beta work isolated. HandL WP can trace an admin asset failure when the initiator, deployed files and access rules disagree.
References checked October 26, 2026. Procedures and synthetic diagrams are explanatory, not claims of customer testing.