Requires: Charitable Pro 1.8.18+

Note: Currently asset loading – or some aspects of it – are in “beta” so this document might be frequenctly updated. Check back regularly for the latest updates.

By default, Charitable loads its frontend scripts on every page of your site. That is deliberate. A Donate button can be placed almost anywhere, including in a theme menu, a custom HTML block, a widget area or a page builder template, and some of those placements cannot be detected before the page is built. Loading everywhere means a Donate button always works, wherever you put it.

If you would rather trade that safety for a lighter front end, the Asset Loading setting lets you limit Charitable’s frontend scripts to pages where it can actually see a donation form or a campaign.

When you would use it

• A speed tool such as PageSpeed Insights or Lighthouse is listing Charitable files on pages that have no donation form.
• Your donation form lives on one campaign page, and the rest of the site does not need the form scripts.
• You are tuning Core Web Vitals and want fewer requests on your homepage.

If your Donate buttons open a donation modal directly on a page, or your theme adds Donate links through a menu or template rather than page content, stay on the default. See “If your Donate buttons stop opening” below.

Finding it

Charitable > Settings > Advanced > Misc, under Asset Loading.

The two modes

Mode	What it does
Load On All Pages (Recommended)	The default, and the original behavior. Charitable’s frontend scripts load on every page, so a Donate button works no matter where it is placed.
Load Only On Pages With A Form Or Campaign	Charitable’s frontend scripts load only where it detects Charitable content. Lighter, but placements it cannot detect will need a filter (below).

The default is unchanged from earlier versions, so upgrading changes nothing until you switch modes yourself.

What counts as a page with a form or campaign

In the second mode, Charitable checks the current page for:

• A single campaign page.
• A Charitable endpoint page, such as the donation form, donation receipt, donor dashboard, login, registration or profile page.
• Any known Charitable shortcode in the page content.
• Any Charitable block, including add-on blocks and Divi 5 modules stored as blocks.

What it cannot see is markup added outside page content. A Donate link in a theme menu, a charitable-modal-trigger CSS class added by hand, or content injected by another plugin are all invisible to this check. The filters in the developer section exist for exactly those cases.

What this setting changes today

The setting governs Charitable’s frontend scripts:

• charitable-frontend.min.js, the general form script.
• The Modal Donate Button bundle, which is charitable-universal-modal (script and stylesheet), charitable.min.js, and the Stripe pre-load that lets a card field mount inside a modal.

Some files continue to load on every page in both modes:

• charitable.min.css and visual-form-themes.min.css, the main stylesheets.
• charitable-session.min.js, which carries donation state.
• Feature stylesheets such as charitable-donor-comments.css and charitable-videos.css.
• Files belonging to separate add-ons, such as charitable-recurring.min.css from Recurring Donations.

Wider coverage is planned for a future release. In the meantime, the snippet at the end of this page trims those files on pages with no Charitable content, using Charitable’s own detection so your campaign pages are left alone.

After you change the setting

Clear your caches. This is a site-wide setting, and pages cached before the change will keep serving the old set of files. Clear your page cache and any combined or minified CSS and JS cache, in WP Rocket, LiteSpeed Cache, WP Super Cache, WP-Optimize, Autoptimize or whatever you run. A PageSpeed test against a stale cached page will show no change and look like the setting did nothing.

Two files to leave alone

charitable-session.min.js. This holds the donation session, including the amount a donor picked before they reached the form. Removing it can break donations in ways that are hard to trace, and it is small. Leave it.

js.stripe.com/v3. Stripe asks that this loads on every page so Stripe Radar can see the full visitor journey when scoring a payment for fraud. Removing it sitewide can reduce the quality of that scoring. If you still need to, the charitable_stripe_load_stripe_scripts_sitewide filter turns it off, but understand that trade-off before you use it.

If your Donate buttons stop opening

Almost always this means a Donate button lives somewhere the page-content check cannot see, such as a theme menu, a header template or a custom HTML block with a charitable-modal-trigger class.

Either switch back to Load On All Pages, or tell Charitable those pages count as content:

add_filter(
	'charitable_current_page_has_content',
	function ( $has_content ) {

		// Treat the homepage and the "Ways to Give" page as Charitable content.
		if ( is_front_page() || is_page( 'ways-to-give' ) ) {
			return true;
		}

		return $has_content;
	}
);

---

Developer reference

All six filters below must be registered before wp_enqueue_scripts priority 20, so hook them from a plugin, a must-use plugin, or your theme’s functions.php at the top level rather than inside a later hook.

Filter	Type	What it controls
charitable_is_strict_asset_loading	bool	The resolved mode. Return true to force the restricted mode regardless of the setting, or false to force the default.
charitable_current_page_has_content	bool	The final answer on whether the current page counts as Charitable content. The catch-all for anything the checks cannot see.
charitable_load_frontend_scripts	bool	Whether charitable-frontend.min.js is enqueued on this request.
charitable_content_shortcodes	array	Shortcode tags that count as Charitable content. Add your own.
charitable_content_blocks	array	Block names that count as Charitable content, including blocks in other namespaces.
charitable_content_endpoints	array	Charitable endpoint IDs that count as content. The trailing _page suffix is optional.

Two of these are also public functions, so your own code can gate its assets on the same decision Charitable makes:

• charitable_is_strict_asset_loading() returns whether the restricted mode is active.
• charitable_current_page_has_content() returns whether the current page contains Charitable content.

There is also charitable_enqueue_modal_donation_assets, which predates this setting. Returning false removes the whole Modal Donate Button bundle on the current request.

Trimming the remaining files

This snippet removes every Charitable stylesheet and script on pages that Charitable itself does not consider content, while keeping the two files named above. It asks charitable_current_page_has_content() rather than hard-coding page conditions, so campaign pages, the donation receipt and the donor dashboard are never touched. It also matches by file location rather than by handle name, so it covers add-on files without you having to list them.

add_action(
	'wp_enqueue_scripts',
	function () {

		// Let Charitable decide. On any page it considers content, change nothing.
		if ( ! function_exists( 'charitable_current_page_has_content' ) || charitable_current_page_has_content() ) {
			return;
		}

		// Files that must keep loading everywhere.
		$keep = array( 'charitable-sessions', 'js-cookie', 'stripe-v3' );

		foreach ( array( 'styles', 'scripts' ) as $type ) {

			$assets  = ( 'styles' === $type ) ? wp_styles() : wp_scripts();
			$dequeue = array();

			// Collect first. Dequeuing while looping over the queue skips entries.
			foreach ( (array) $assets->queue as $handle ) {

				if ( in_array( $handle, $keep, true ) ) {
					continue;
				}

				$src = isset( $assets->registered[ $handle ] ) ? $assets->registered[ $handle ]->src : '';

				if ( is_string( $src ) && false !== strpos( $src, '/plugins/charitable' ) ) {
					$dequeue[] = $handle;
				}
			}

			foreach ( $dequeue as $handle ) {
				if ( 'styles' === $type ) {
					wp_dequeue_style( $handle );
				} else {
					wp_dequeue_script( $handle );
				}
			}
		}
	},
	100
);

Add it with a code snippet plugin such as WPCode, or in a must-use plugin. Priority 100 matters: it has to run after Charitable and its add-ons have enqueued their files.

After adding it, clear your caches and re-test. On a test site with Charitable Pro, Recurring Donations, donor comments and videos all active, this took the homepage from 18 Charitable files to 2, and left the campaign page’s 24 files untouched.

Two things to check once it is live:

1. Open a campaign page and make a test donation. It should be completely unaffected. If it is not, the snippet is running somewhere it should not be, and charitable_current_page_has_content is the filter to correct that.
2. Check any page with a Donate button that opens a modal. If a button stops working, add that page through the charitable_current_page_has_content filter shown earlier.