Pantry Cleanup

A Pantry Pro module for Pantry Cleanup. It shows every script and style a front-end page loads, where each one came from and how big it is, and turns any of them off on that page, on that post type, or everywhere.

Class: Pantry\Pro\Modules\Cleanup\Script_Manager Needs: Pantry Cleanup 1.1.0 or newer (for the pantry_cleanup_settings_after action) and a licence activated on the site.

What it adds

An admin-bar panel on the front end. Administrators get an Assets (n) item on the right of the admin bar of every front-end page. It opens a panel listing every enqueued script and style on that page:

• the handle, and whether it is a script or a style,
• the file it loads, and whether WordPress printed it inline,
• the source read off the asset URL: Plugin: <folder>, Must-use plugin: <folder>, Theme: <folder>, WordPress, Uploads, External: <host>, or No file: inline or grouped for a handle that has no file of its own,
• the file size when the file is on this site's disk,
• three buttons per row: This page, This post type, Everywhere.

This page stores the rule against the post id when the page is a single post, page or custom post type, and against the URL path otherwise (paths are compared lower-cased, with one leading and one trailing slash). This post type appears only on single posts and post type archives, and matches both. Everywhere matches every front-end request.

Rules that already took effect on the page being viewed are listed at the top of the panel under "Already disabled here", each with a Remove this rule link, so an asset can always be brought back from the page it disappeared from.

Test mode. While test mode is on, rules apply only to logged-in administrators. Visitors keep seeing every asset. It is on when the module is first installed, and it is switched off from the Cleanup screen when the rules are right.

A rules list on the Cleanup screen. Plugin Pantry > Cleanup, below the free plugin's own settings: the test mode switch with its own Save button, and a table of every rule (handle, kind, what it applies to, when it was added) with a Remove link on each.

What it never does

• It never runs in the admin, on the login screen, or during REST, AJAX, cron, WP-CLI, feed or embed requests.
• It refuses to disable jquery, jquery-core, admin-bar, dashicons, hoverintent-js or its own panel assets. The panel shows "Kept: the site needs it" instead of buttons for those rows, and the endpoint refuses the same handles if the request is forged. The admin bar style depends on dashicons and its script on hoverintent-js, so deregistering either would take the admin bar with it. To drop Dashicons for visitors who are not logged in, use the free plugin's own Dashicons switch.
• It never adds a rule for more than 200 rules in total.

How rules are applied

wp_enqueue_scripts at priority 9999 and wp_print_styles at priority 9999. Running twice catches styles that a block enqueued while the content was rendered. Each matching rule calls wp_dequeue_script() and wp_deregister_script(), or wp_dequeue_style() and wp_deregister_style(). Deregistering means anything that depends on the handle is not printed either; that is the point, and it is why the protected handles above are protected.

Settings

Setting	Where	Default	What it does
Test mode	Plugin Pantry > Cleanup, "Script and style manager"	on	Applies every rule only for logged-in administrators
Rules	Made from the front-end panel, listed on the same screen	none	One handle, one scope, one match each

The test mode switch has its own Save button rather than riding the free plugin's. The free plugin's form posts to options.php, and options.php writes null over every option registered in a settings group that is not present in the submitted form. The module's fields are rendered after that form closes (render_after() is called outside it), so registering the option in the free plugin's group would reset test mode on every free save. A separate admin-post.php form with its own nonce and capability check avoids that, and keeps the two plugins' options independent.

Data

One option, pantry_pro_cleanup_script_manager, autoloaded:

array(
	'test_mode' => true,
	'rules'     => array(
		'style|wp-block-navigation|post_type|post' => array(
			'type'   => 'style',   // script | style
			'handle' => 'wp-block-navigation',
			'scope'  => 'page',    // page | post_type | everywhere
			'match'  => 'post',    // '' | post type | post:<id> | /url/path/
			'added'  => 1789240922,
		),
	),
)

install() creates it with test mode on and no rules, and never overwrites an existing one. uninstall() deletes it. Nothing else is stored: no tables, no post meta, no transients, no cron events.

Assets

• assets/cleanup-script-manager.css
• assets/cleanup-script-manager.js (vanilla, no jQuery, no build step)

Both are enqueued only on front-end requests, only for users who can manage_options, only while the admin bar is showing, and never in the customizer preview.

Hooks

The module adds no filters or actions of its own. It uses one action in the free plugin:

• pantry_cleanup_settings_after (Pantry Cleanup 1.1.0) to render its section on the Cleanup screen.

Endpoints, both capability- and nonce-checked:

Endpoint	Action	Nonce
admin-ajax.php	pantry_pro_cleanup_script_manager (op=add / op=remove)	pantry_pro_cleanup_script_manager
admin-post.php	pantry_pro_cleanup_sm_settings	pantry_pro_cleanup_sm_settings
admin-post.php	pantry_pro_cleanup_sm_remove	pantry_pro_cleanup_sm_remove