Disable Script Concatenation turns off the WordPress admin’s habit of bundling many JavaScript files into a single load-scripts.php response. The result is admin pages that are immune to a known denial-of-service attack against that endpoint.

What this feature does

To speed up admin pages, WordPress concatenates multiple JS and CSS files into single requests via wp-admin/load-scripts.php and load-styles.php. The endpoint accepts a comma-separated list of script handles and returns the concatenated output. It’s convenient and saves HTTP requests.

Unfortunately, the same endpoint can be abused: an attacker can send a request with hundreds of script handles, forcing the server to read, concatenate, and serve large amounts of data per request. Multiplied across many simultaneous requests, this can exhaust server resources without ever needing to authenticate.

This setting writes CONCATENATE_SCRIPTS as false to wp-config.php. WordPress falls back to enqueuing each script as its own <script> tag. The concatenation endpoint stops being a useful target.

Admin only, performance trade-off is small

Script concatenation only applies inside /wp-admin/, never on the public-facing front-end. Disabling it means slightly more HTTP requests on admin page loads, which is barely noticeable on modern HTTP/2 connections. The security benefit is large; the performance hit is negligible.

How to enable it

  1. Open AdminEase › Security. Click AdminEase in the WordPress admin menu, then switch to the Security tab.
  2. Toggle Disable scripts concatenation in WordPress admin panel on. Save settings. AdminEase writes the constant to wp-config.php immediately.
  3. Verify. Open any admin page, view source. You should see individual <script> tags for each WordPress core script (e.g. jquery-core.js, jquery-migrate.js) instead of a single load-scripts.php?load=… request.

Settings reference

Setting What it does Default
Disable scripts concatenation in WordPress admin panel Adds define('CONCATENATE_SCRIPTS', false); to wp-config.php. Off

What happens behind the scenes

wp-config.php constant

AdminEase writes the constant in a managed block in wp-config.php:

define( 'CONCATENATE_SCRIPTS', false );

WordPress core checks this constant in wp-admin/admin-header.php when deciding whether to use the concatenation endpoint or output individual script tags. With the constant set to false, the concatenation logic is bypassed entirely.

Troubleshooting

The admin feels slightly slower

Expected, but small. Each admin page now makes a few more HTTP requests. On HTTP/2 connections (which most modern hosts support), the difference is in milliseconds. If your admin feels sluggish for unrelated reasons, that’s worth investigating, but disabling concatenation isn’t the cause.

A plugin’s admin script stopped working

Possible but rare. Some plugins assume their script will run after WordPress core scripts have been concatenated. Switching to individual scripts changes the load order in subtle ways. If a specific plugin breaks, file a bug report with the plugin author so they can declare proper script dependencies via wp_enqueue_script instead of relying on concatenation timing.

I can’t see the constant in wp-config.php

Look for the AdminEase-managed block (between BEGIN AdminEase and END AdminEase markers). All AdminEase constants live in that block. If the block is missing, AdminEase couldn’t write to wp-config.php; check file permissions on your server.