Remove Generated Footer Scripts/Styles

Found it this morning.

It’s located in customizer.php line 122
add_action( 'wp_print_footer_scripts', array( $this, 'print_css_template' ), 15 );
From Function:

// If we don't have anything on the customizer don't print empty styles
		// On Customize Page, we don't care we need this
		if ( ! is_customize_preview() && empty( $css_template ) ) {
			return false;
		}
// All sections should use this action to print their template
		echo '<script type="text/css" id="' . esc_attr( 'tmpl-' . $this->ID . '_css' ) . '">';
		echo $css_template;
		echo '</script>';

		// Place where the template will be rendered to
		echo '<style type="text/css" id="' . esc_attr( $this->ID . '_css' ) . '">';
		echo $this->parse_css_template( $css_template );
		echo '</style>';

I don’t get why this is on every single page… Is it poor programming or laziness? Honestly, any plugin needs to enqueue their resources ONLY WHERE NEEDED. I don’t get it.

I’ll fix it myself.

• This reply was modified 7 years, 8 months ago by Fryvisuals.

Here’s the fix
remove_action( 'wp_print_footer_scripts', array( Tribe__Customizer::instance(), 'print_css_template' ), 15 );

Removing these styles while using the free plugin version with tribes default template styles does nothing to alter the display.

Hi @fryvisuals ??

The first is a <script> tag with an id=”tmpl-tribe_customizer_css”. This is a script tag with CSS in it… WHY?

That’s because it basically serves the role of a template, not unlike a <template> element but with better cross-platform results.

Is it poor programming or laziness? Honestly, any plugin needs to enqueue their resources ONLY WHERE NEEDED.

In general, I’d absolutely agree that resources should be included only where needed.

I disagree that this amounts to poor programming or laziness though: we need to support many different themes and environments and this was the most pragmatic way to achieve the level of coverage and customizer-support required by our user-base.

That doesn’t mean it’s perfect and we’ll continue to refine this: to that end, if you have specific thoughts on this, we’d welcome your feedback. Do remember though that we need to support the possible existence of calendar-related widget/shortcode output on any given page and that, as those can be generated or inserted dynamically, determining that those elements are present early enough to do things differently isn’t easy.

Beyond that, glad to hear you hit upon a fix you are happy with — and thank you for sharing it ??