WordPress 7.2 Removes load-scripts.php: Clean Up wp-config.php

WordPress 7.2 stops concatenating admin scripts and styles. The two files that used to do that, wp-admin/load-scripts.php and wp-admin/load-styles.php, now just return 410 Gone. If you have define( 'CONCATENATE_SCRIPTS', false ); in wp-config.php, nginx rules that block load-scripts.php, or a plugin that calls script_concat_settings(), this post is for you. As of 2026-10-29, 7.2 is in beta (Beta 2 shipped on October 27), and the final release is planned for December 8, 2026. That leaves about five weeks to clean up.

Nothing here should take a site down, but I’d rather find the leftovers on staging than in a client’s error log.

The fix: find the leftovers and remove them

Back up first. You’re about to edit wp-config.php and maybe your web server config, so keep copies of both:

cp wp-config.php wp-config.php.bak-$(date +%F)
sudo cp -a /etc/nginx /root/nginx-backup-$(date +%F)

Then search the site and the server for anything that still relies on concatenation:

# In the WordPress root
grep -nE "CONCATENATE_SCRIPTS|COMPRESS_SCRIPTS|COMPRESS_CSS|ENFORCE_GZIP" wp-config.php

# Plugins, themes and mu-plugins
grep -rnE "load-(scripts|styles).php|script_concat_settings|_print_scripts|_print_styles|concatenate_scripts" wp-content/ --include=*.php --include=*.js

# Web server rules (nginx / Apache)
grep -rnE "load-(scripts|styles)" /etc/nginx/ /etc/apache2/ /etc/httpd/ 2>/dev/null
grep -nE "load-(scripts|styles)" .htaccess

Here’s what to do with each hit:

• define( 'CONCATENATE_SCRIPTS', false ); in wp-config.php: people added this to debug broken admin screens, or as a mitigation for the old load-scripts.php DoS trick. In 7.2 core no longer concatenates anything, so the line does nothing. Delete it, or comment it out until you’re on 7.2 everywhere.
• nginx/Apache rules that deny or rate-limit load-scripts.php / load-styles.php: these won’t hurt anything, but they’re dead weight now. The 7.2 versions of both files answer with a 410 without even loading WordPress, so hitting them is cheap.
• Plugin or theme code calling script_concat_settings(), _print_scripts() or _print_styles(): all three are deprecated in 7.2.0. They still run, but with WP_DEBUG on you’ll get a deprecation notice. Update the plugin, or remove the call in your own code.
• Hardcoded links to load-scripts.php?load[]=..., for example in a custom login page, a preload header or a CDN warm-up script: these will break, because the URL now returns plain text and a 410. Enqueue the handles normally with wp_enqueue_script() / wp_enqueue_style() instead.

If your own code reads the $concatenate_scripts global, it keeps working. The deprecated script_concat_settings() now just sets $concatenate_scripts, $compress_scripts and $compress_css to false when they aren’t already set, so old checks get a sane value. Don’t write new code that depends on them, though.

Test it on staging with the 7.2 beta

Never run a beta on production. On a staging copy, WP-CLI gets you there in one command (this is the exact command from the WordPress 7.2 Beta 2 announcement):

wp core update --version=7.2-beta2
wp core version

Turn on debug logging so deprecation notices end up in a file instead of on screen:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Now click through the screens that used concatenated assets: the login page, Dashboard, Posts, the block editor, Plugins and, on multisite, the Network Admin. Then check the log:

grep -nE "script_concat_settings|_print_scripts|_print_styles" wp-content/debug.log

If you’re new to the debug constants, I covered them in How to enable WP_DEBUG in WordPress and in more depth in How to properly DEBUG in WordPress.

Also open the browser dev tools on the Network tab. Under 7.2 you should see each admin script requested on its own (/wp-includes/js/..., /wp-admin/js/...) rather than one big load-scripts.php?c=1&load[]=... request. If anything still asks for load-scripts.php, the Initiator column tells you which file is doing it.

Watch for 410s in your access log

Once production is on 7.2, any request still hitting the old endpoints shows up as a 410. Bots and stale cached pages will produce a few, which is fine. Lots of them coming from your own admin pages points to a plugin you missed:

grep -E "load-(scripts|styles).php" /var/log/nginx/access.log | awk '$9 == 410' | wc -l
grep -E "load-(scripts|styles).php" /var/log/nginx/access.log | awk '$9 == 410 {print $11}' | sort | uniq -c | sort -rn | head

The second command groups the hits by referer (field 11 in the default combined log format), so you can see which admin page is still asking for the old file. Adjust the log path for your server.

Why this works

Script concatenation was a workaround from the HTTP/1.1 days, when every extra request was expensive. Core used it only on the login and admin screens, including the super admin screens. The October 20 performance chat summary confirms that removing it landed in 7.2-beta1 and retires load-scripts.php and load-styles.php. The replacement is a more modern approach: blocking scripts and styles known to be needed on the next screen get prefetched, so the browser cache is already warm when you reach the Dashboard or the editor.

Both old files are still shipped so that existing links fail cleanly. You can see the new load-scripts.php in wordpress-develop: it sends http_response_code( 410 ), prints “Scripts are no longer concatenated.” and exits without loading WordPress. That’s why your old blocking rules no longer matter and why stale links don’t fill your log with PHP notices.

For reference, my list of all WordPress constants still includes CONCATENATE_SCRIPTS because sites below 7.2 use it. Just don’t carry it into new wp-config.php templates.

Testing 7.2 in OpenPanel

If your staging site is on OpenPanel, WP-CLI comes preinstalled in each site’s PHP container. You can run wp core update --version=7.2-beta2 --allow-root from the web terminal (Enterprise), or put the command in a cron job and click Run to see the output. Their WP-CLI guide explains why --allow-root is needed there. In cPanel you’d normally SSH in, or use the cPanel Terminal if your host enables it, and run the same command without that flag.

Prevention

• Keep wp-config.php minimal. Every “just in case” define becomes something to audit later.
• Comment every server rule you add for a specific WordPress file with the reason and the date. When core changes, you’ll know what’s safe to delete.
• Never hardcode core asset URLs. Enqueue by handle, and core can change how those assets are delivered without breaking you.
• Test each beta on a staging clone with WP_DEBUG_LOG on. Deprecation notices are the warning you get before something actually breaks.

TL;DR

WordPress 7.2 (planned for December 8, 2026) no longer concatenates admin scripts and styles. load-scripts.php and load-styles.php now return 410, and script_concat_settings(), _print_scripts() and _print_styles() are deprecated. Back up, grep for CONCATENATE_SCRIPTS and load-(scripts|styles) in wp-config.php, wp-content and your server config, remove the leftovers, and test on staging with wp core update --version=7.2-beta2 and debug logging on.