This feature is available in the Pro version starting from v1.1.8.6.

For better performance and a higher PageSpeed Insights score, unloading plugins (not just the CSS/JS files that are loading from those plugins) in the frontend view is one of the features that can be used in Asset CleanUp Pro. This post is about the same functionality that takes effect inside the Dashboard (where you have to be always logged-in, not for your guest visitors). Although it’s not often needed, there are situations when you have conflicts between plugins, very slow admin pages that could load faster if certain plugins are unloaded on those admin pages.

Using this feature is recommended only to advanced users (e.g. developers/admins that know very well their website and the consequences of having plugins unloaded for certain pages) who really need it. A set rule would not only unload all the CSS/JS that is loading from a plugin but everything else (e.g. its backend PHP code, HTML output printed via admin_head() or admin_footer() action hooks, any cookies that are set, .etc).

The function is_admin() is used to perform the verification to determine if the user is inside a Dashboard page.

How to enable this option in Asset CleanUp Pro?

Due to the nature of this feature which requires extra care when unloading plugins within the Dashboard, the WPACU_ALLOW_DASH_PLUGIN_FILTER constant has to be enabled in the file wp-config.php, just like in the example below.

If you can’t view the list of plugins the way you can view it when you navigate to the other tab (“IN FRONTEND VIEW (your visitors)”), the constant is set to false or it wasn’t added there in the first place. Here’s the constant that should be used, ideally before the /** Sets up WordPress vars and included files. */ line:


/** Sets up WordPress vars and included files. */
require_once(ABSPATH . 'wp-settings.php');
Placing define(‘WPACU_ALLOW_DASH_PLUGIN_FILTER’, true); AFTER require_once(ABSPATH . ‘wp-settings.php’); is the wrong way of doing it, and it will not take any effect.

Once the snippet is added correctly, the list of active plugins will be shown in “PLUGINS MANAGER” -> “INSIDE THE DASHBOARD /wp-admin/”, just like it is in “IN FRONTEND VIEW (your visitors)” which doesn’t require any special activation.

What if I make a mistake and I end up with a page that is not usable?

In the event that you unload a plugin or a few plugins in specific admin pages and you end up with PHP errors or inoperational pages (e.g. you unloaded a plugin that is connected to another plugin and you should keep both plugins loaded on that particular page). In this case, you can bypass it (have the unload rules ignored) by appending the following query string to the URL: &wpacu_no_dash_plugin_unload, thus allowing you to access the page as if the Asset CleanUp Pro rule had no effect. What you can do once you realized you need to change the rules is access “PLUGINS MANAGER” -> “INSIDE THE DASHBOARD /wp-admin/” (/wp-admin/admin.php?page=wpassetcleanup_plugins_manager&wpacu_sub_page=manage_plugins_dash) and have the rules removed. If the actual management page is also affected, then you can append &wpacu_no_dash_plugin_unload to the URI that was just mentioned and you will be able to access the page and make the changes you need.

How can I check if the rules I’ve applied actually took effect? Is there a way to view the list of all the plugins that were NOT loaded on the targeted pages?

Definitely! This is also a good way to remind you which plugins you decided to unload on those pages. If you append /?wpacu_debug or &wpacu_debug (depending on the URI if it already had a query string added to it) to the target page, you will notice at the bottom of the page a debug notice containing the list of all the plugins that weren’t loaded.

UPDATE: Starting from version (Pro), there’s a notice added to the top admin bar’s menu (if the menu is shown), altering the current user of any rules that took effect from Asset CleanUp Pro. The rules are showing in both the Dashboard and the front-end view (if the top admin bar is shown obviously), just like in the example below where a rule was set in a certain admin page to exclude the “Yoast SEO” plugin (just an example, you have to do your own research and determine if you need it or not on specific admin pages).

Is extra care required when adding the RegEx rules to make sure the request URI is matched?

If the URI contains characters such as a question mark – ? (which is fairly common within the Dashboard’s URIs) or any of the following characters, then they have to be escaped properly if your purpose is to have a match if the URI contains a specific string. For instance, on the “Media” -> “Library” page (list mode) you decided to prevent certain plugins from loading. The URI is /wp-admin/upload.php?mode=list. The question mark has to be escaped with \ in front of it since it’s a special character in a RegEx. The RegEx would be #/wp-admin/upload.php\?mode=list# – by using # as a delimiter, we won’t have to escape other characters such as = equal sign or forward slash.

Another example is the edit post/page which often loads plugins that are not needed (test carefully, don’t just unload a plugin when it might be needed to load). The RegEx rule that could be used in this case is #/wp-admin/post.php\?post=# – this would match URIs such as /wp-admin/post.php?post=100&action=edit – 100 is the post ID in this example.

What about calls to /wp-admin/admin-ajax.php? Can they be added to the plugin unload rules?

Currently, unload rules to this URI (which is the default location where WordPress AJAX calls are made) are not taking effect. These AJAX calls are made in both the frontend view and /wp-admin/ and require special attention to make sure nothing will get broken with the functionality. Soon, Asset CleanUp Pro will have a dedicated page or plugin extension that will offer unloading plugins on AJAX calls.

Note: In future versions of the plugin, there will be easier ways to add rules such as choosing to match a URI if it just contains, starts, or ends with a specific string. RegEx(es) can be complicated sometimes and could make admins write them incorrectly.

Was this post helpful?