Cannot exclude JavaScript files that are registered but not enqueued

Hello @remcotolsma ,

Scripts that are registered with wp_register_script WP function, but are not enqueued via wp_enqueue_script are not affected by our plugin, due to the fact that in order to be enqueued properly on the site, they have to be enqueued according to WP standards.

Scripts that are only registered are not enqueued according to the WordPress instance, which is why they are ignored from the combination and the exclusion of the combination.

Best regards,
Georgi Ganchev

add_action( 'wp_enqueue_scripts', function() {
	wp_register_script( 'plugin-js', plugins_url( 'js/custom.js', __FILE__ ), array(), '1.0.0', true );
} );

add_shortcode( 'test', function( $atts ) {
	wp_enqueue_script( 'plugin-js' );

	return 'test';
} );

You say plugin-js is now not included in SiteGround Optimizer JavaScript combining? I think I saw different behavior which also resulted in problems and why I started this topic.

@remcotolsma

This script won’t be included in our optimizations, due to the fact that it’s not registered as per WordPress’ coding recommendations.

According to the docs for the wp_enqueue_script:
https://developer.www.ads-software.com/reference/functions/wp_enqueue_script

The function should be called using the wp_enqueue_scripts action hook if you want to call it on the front-end of the site, like in the examples above. To call it on the administration screens, use the admin_enqueue_scripts action hook. For the login screen, use the login_enqueue_scripts action hook. Calling it outside of an action hook can lead to problems, see the ticket #11526 for details.`

Best regards,
Georgi Ganchev

This script won’t be included in our optimizations, due to the fact that it’s not registered as per WordPress’ coding recommendations.

You are incorrect, this script is included in the SiteGround Optimizer optimizations. I have created a test plugin:

wp-topic-15652168.php

<?php
/**
 * Plugin Name: SiteGround Optimizer topic 15652168
 */

add_action( 'wp_enqueue_scripts', function() {
	wp_register_script( 'wp-topic-15652168', plugins_url( 'wp-topic-15652168.js', __FILE__ ), array(), '1.0.0', true );
} );

add_shortcode( 'wp_topic_15652168', function( $atts ) {
	wp_enqueue_script( 'wp-topic-15652168' );

    $url = 'https://www.ads-software.com/support/topic/cannot-exclude-javascript-files-that-are-registered-but-not-enqueued/';

	return sprintf(
        '<a href="%s">%s</a>',
        esc_url( $url ),
        esc_html( $url )
    );
} );

wp-topic-15652168.js

console.log( 'Hello from wp-topic-15652168.js.' );

document.body.style.background = 'Red';

On https://remcot12.sg-host.com/siteground-optimizer-topic-15652168/ a page with the shortcode [wp_topic_15652168].

As you can see the document.body.style.background='Red' is part of the https://remcot12.sg-host.com/wp-content/uploads/siteground-optimizer-assets/siteground-optimizer-combined-js-d20ccf0fa19bb9d0fe2416faa77bdcaf.js file.

It’s perfectly fine to enqueue scripts at a later time, the WordPress coding recommendations are a bit outdated and more about registering the scripts. Also see this comment:

1. https://developer.www.ads-software.com/reference/functions/wp_enqueue_script/#comment-1602
2. https://scribu.net/wordpress/conditional-script-loading-revisited.html

• This reply was modified 2 years, 6 months ago by Remco Tolsma.

Hello @remcotolsma,

While the script will be included in the combination, since it’s detected as being used in the specific URL that is visited, the same script can’t be found in the $wp_scripts global variable, set by WordPress.

We are using said variable for detecting registered scripts, in order to list them as suggestions in SG Optimizer >> Frontend >> Javascript >> Exclude from Javascript Combination dropdown.

Since this is more of a corner case, for similar situations we suggest using the filter, that we’ve added, in order to exclude specific script from the JS combination manually:

add_filter( 'sgo_javascript_combine_exclude', 'js_combine_exclude' );
	function js_combine_exclude( $exclude_list ) {
		$exclude_list[] = 'script-handle';
		$exclude_list[] = 'script-handle-2';

		return $exclude_list;
	}

Best Regards,
Gergana Petrova

While the script will be included in the combination, since it’s detected as being used in the specific URL that is visited, the same script can’t be found in the $wp_scripts global variable, set by WordPress.

I’m not sure if that’s true, i have added following to the test plugin:

add_action( 'wp_footer', function() {
	$wp_scripts = wp_scripts();

	echo '<pre>';
	var_dump( $wp_scripts );
	echo '</pre>';
} );

If you view https://remcot12.sg-host.com/ you will see that wp-topic-15652168 is part of $wp_scripts?

Since this is more of a corner case, for similar situations we suggest using the filter, that we’ve added, in order to exclude specific script from the JS combination manually:

I don’t think you should see this as a corner case, a good plugin developer should only enqueue the scripts that are needed?

I think it is also perfectly possible to create a select field containing all the registered scripts for exclusion.

However, if you don’t have the time and motivation to improve this, that is of course also an answer. I’m just trying to help make your plugin even better.

Thank you for the additional feedback, @remcotolsma.

I have already passed it along to our developers.

Best Regards,
Gergana Petrova

Hello @remcotolsma,

We do understand your point of view. Still most of our plugin users are not developers and if we list all registered scripts in a drop-down they will see a huge amount of files (on more complex websites there are hundreads of registered scripts) and this will be more confusing then helpfull.

As for the developers – they can find the handler of the script they need to exclude and use our filters.

Best Regards,
Elena

Hmm, then you might also wonder how useful the “Exclude from JavaScript Minification” functionality is at all. If that doesn’t even include the scripts of plugins that register them correctly. I understand that the list can get very long, but that shouldn’t be a reason not to do it right. This issue came up by a non-developer. Personally, I think there is still room for improvement here. You will probably not be very satisfied with how the displayed assets are currently being requested.

// Get the global varialbes.
global $wp;
global $wp_styles;
global $wp_scripts;
// Remove the jet popup action to prevent fatal errros.
remove_all_actions( 'elementor/editor/after_enqueue_styles', 10 );

$wp_scripts->queue[] = 'wc-jilt';

ob_start();
// Call the action to load the assets.
do_action( 'wp', $wp );
do_action( 'wp_enqueue_scripts' );
do_action( 'elementor/editor/after_enqueue_styles' );
ob_get_clean();

unset( $wp_scripts->queue['wc-jilt'] );

I think this will remain somewhat error-prone and more users will open topics/issues for this.