Function WP_Scripts::add was called incorrectly

  • Resolved Oliver Campion

    (@domainsupport)


    1 month, 2 weeks ago

    Hello,

    In WordPress v6.9.1 detection was added for when scripts are enqueued with dependencies that are not registered …

    [05-Feb-2026 08:37:13 UTC] E_USER_NOTICE: Function WP_Scripts::add was called incorrectly. The script with the handle "XXX" was enqueued with dependencies that are not registered: hcaptcha. Please see Debugging in WordPress for more information. (This message was added in version 6.9.1.) in /wp-includes/functions.php on line 6131

    We believe that your plugin causes these error notices because it registers the hcatpcha script (with wp_enqueue_script() on line 832 of /src/php/Main.php) on the wp_print_footer_scripts hook rather than register it with wp_register_script() on the wp_enqueue_scripts hook.

    You can replicate this error by enqueuing a test script with hcaptcha as one of the dependencies …

    add_action('wp_enqueue_scripts', 'test_wp_enqueue_scripts');

    function test_wp_enqueue_scripts() {

        wp_enqueue_script(
            'test_script',
            'test-script.js',
            array('hcaptcha')
        );

    }

    Can you please look into this?

    Thank you.

    Oliver

Viewing 9 replies - 1 through 9 (of 9 total)
  • Plugin Contributor kaggdesign

    (@kaggdesign)

    1 month, 2 weeks ago

    Hi @domainsupport,

    This notice means that some code is calling WP_Scripts->add() incorrectly. The important part here is the script handle, which you replaced with XXX.

    Without the real handle, this issue cannot be investigated. The handle is exactly what identifies which plugin or theme is responsible.

    At the moment, there is no evidence this is coming from our plugin.

    Please provide:

    1. The full, unedited error message from debug.log (with the real script handle instead of XXX)
    2. The stack trace, if available
    3. Steps to reproduce (where/when this happens)
    4. WordPress + PHP versions and a list of active plugins

    If you want to isolate the source quickly, use Health Check → Troubleshooting mode and enable plugins one by one.

    Until then, this looks like an issue in custom code or another plugin, not ours.

    Thread Starter Oliver Campion

    (@domainsupport)

    1 month, 2 weeks ago

    I’m sorry but you have not understood what we have explained.

    We have provided exact instructions to replicate the issue, what the cause is and how you can rectify.

    The issue is specifically that your script is being registered and enqueued too late.

    Thank you.

    Plugin Contributor kaggdesign

    (@kaggdesign)

    1 month, 2 weeks ago

    Thanks for the clarification — I understand your point.

    Technically, yes, we could register the hcaptcha script globally. However, this is an intentional design decision on our side.

    We have received explicit requests from our users to avoid loading or registering hCaptcha scripts on pages where they are not needed. Because of that, our plugin registers and enqueues the hCaptcha script only in contexts where it is actually used, and we do not guarantee that the hcaptcha handle exists on every frontend request.

    Registering it globally would introduce unnecessary scripts and potential side effects on unrelated pages, which goes directly against those user requests and our performance goals.

    If custom code needs to rely on the hCaptcha script outside of those contexts, it should explicitly register or enqueue the script itself, for example:

    add_action('wp_enqueue_scripts', 'test_wp_enqueue_scripts');

    function test_wp_enqueue_scripts() {
    	wp_register_script(
    		'hcaptcha',
    		HCAPTCHA_URL . '/assets/js/apps/hcaptcha.js',
    		[ 'wp-hooks' ],
    		HCAPTCHA_VERSION,
    		true
    	);

    	wp_enqueue_script(
    		'test_script',
    		'/test-script.js',
    		array('hcaptcha')
    	);
    }

    This keeps responsibilities clearly separated:

    • our plugin loads hCaptcha only when required,
    • custom code ensures its own dependencies are available when needed.

    For these reasons, this is not a bug in our plugin but an integration detail in custom code.

    Thank you for your understanding.

    Thread Starter Oliver Campion

    (@domainsupport)

    1 month, 2 weeks ago

    That’s precisely how we have attempted to bypass this issue. We also wrap the wp_register_script() in a conditional to check to make sure your plugin is active …

            if (class_exists('\HCaptcha\Helpers\HCaptcha')) {

                wp_register_script(
                    'hcaptcha',
                    HCAPTCHA_URL . '/assets/js/apps/hcaptcha.js',
                    array('wp-hooks'),
                    HCAPTCHA_VERSION,
                    true
                );

            }

    We generate the hCaptcha form element within our shortcode’s form using …

    \HCaptcha\Helpers\HCaptcha::form();

    However, when call wp_register_script() to register 'hcaptcha' the WordPress notices are resolved but the hCaptcha form element shows “The hCaptcha loading is delayed until user interaction.” and never renders the tick box. I assume this is because registering the script early and allowing WordPress to enqueue it via the dependancies doesn’t allow this delay to take effect … ?

    DelayedScript::launch( [ 'src' => $this->get_api_src() ], $delay );

    Also, I am not suggesting that you enqueue the script for every page load. You only need to register it. WordPress will enqueue it automatically when it is required as a dependency and once registered you would only need to enqueue it manually with wp_enqueue_script('hcaptcha').

    Likewise on line 831 of /src/php/Main/php …

        wp_enqueue_script( self::WP_HOOKS_HANDLE );

    That line is superfluous because self::WP_HOOKS_HANDLE is specified as a dependency of 'hcaptcha' when it is then enqueued using to wp_enqueue_script() on the following line and as such 'wp-hooks' would be enqueued automatically. But I digress and that’s not relevant to this issue.

    Thank you for looking into this for us.

    Thread Starter Oliver Campion

    (@domainsupport)

    1 month, 2 weeks ago

    Oh and additionally, we notice that your Contact Form 7 integration “Form Auto-Add” is also causing this error notice so I think you may need to look into this in more detail …

    [06-Feb-2026 14:37:06 UTC] E_USER_NOTICE: Function WP_Scripts::add was called incorrectly. The script with the handle "hcaptcha-cf7" was enqueued with dependencies that are not registered: hcaptcha. Please see Debugging in WordPress for more information. (This message was added in version 6.9.1.) in /wp-includes/functions.php on line 6131

    Many thanks,

    Oliver

    Plugin Contributor kaggdesign

    (@kaggdesign)

    1 month, 2 weeks ago

    I think we are mixing two separate topics, so let me clarify.

    1. Custom code depending on the hcaptcha script handle

    Registering the hcaptcha script globally in our plugin would be functionally equivalent to registering it in your own code, as shown in the example above. From WordPress’ point of view, there is no practical difference in where wp_register_script( 'hcaptcha', … ) is called.

    If registering it on your side does not resolve the issue you are seeing, then adding the same registration in our plugin will not resolve it either. That strongly suggests the root cause is somewhere else.

    In addition, our plugin includes multiple conditions and filters that determine whether hCaptcha scripts are allowed to run on a given page at all. If any of those conditions prevent loading, simply registering the script handle — regardless of where it is done — will not change the outcome.

    Because of this, the problem cannot be reduced to “registering the script earlier”, and it is not something we can reliably diagnose without seeing the actual site setup.

    We cannot adapt core plugin behavior to every possible custom integration across tens of thousands of sites. The supported approach is to handle custom dependencies explicitly in custom code, as demonstrated.

    2. “The hCaptcha loading is delayed until user interaction”

    This message is not related to the script handle / registration discussion above and should be treated as a separate issue.

    That notice appears only when “Delay Showing hCaptcha (ms)” on the General settings page is set to a negative value. A negative value means that hCaptcha script loading is intentionally delayed until user interaction (click, scroll, etc.).

    Please set the delay value to 0 and reload the page to compare the behavior.

    If you believe this behavior is incorrect or confusing, please open a separate support topic, as it is a different code path and a different concern.

    Next steps

    At this point, there are too many variables involved (custom code, filters, settings, page context).
    To investigate further, I would need access to a test page or site where the issue can be reproduced.

    Based on the information available so far:

    • the script-handle warning points to an integration issue in custom code;
    • the delayed-loading notice is expected behavior based on current settings.

    Thank you for your understanding.

    Thread Starter Oliver Campion

    (@domainsupport)

    1 month, 2 weeks ago

    I feel like I’m talking to a bot so I’ll keep this short and sweet.

    From WordPress’ point of view, there is no practical difference in where wp_register_script( 'hcaptcha', … ) is called.

    That is not accurate and your bot probably isn’t aware of the changes in WordPress v6.9.1.

    Your own plugin causes the issue mentioned in this support topic so please have a go at using your Contact Form 7 integration “Form Auto-Add” which subsequently causing this error notice …

    [06-Feb-2026 14:37:06 UTC] E_USER_NOTICE: Function WP_Scripts::add was called incorrectly. The script with the handle "hcaptcha-cf7" was enqueued with dependencies that are not registered: hcaptcha. Please see Debugging in WordPress for more information. (This message was added in version 6.9.1.) in /wp-includes/functions.php on line 6131

    Many thanks,

    Oliver

    Plugin Contributor kaggdesign

    (@kaggdesign)

    1 month, 2 weeks ago

    I’d like to clarify a few points.

    First, comments implying that I am “a bot” are outside the scope of a respectful technical discussion. I am not a bot, and I am fully aware of the changes introduced in WordPress 6.9.1. In fact, I personally had to update and fix tests related to those changes on GitHub.

    Second, the issue you are describing does not reproduce on standard WordPress sites or in supported plugin usage scenarios. We have tested this with supported themes and plugins, including the Contact Form 7 integration in normal configurations.

    The notice you are seeing reproduces only in combination with your custom mu-plugin code, and it disappears as soon as wp_register_script( 'hcaptcha', … ) is added to that custom code. That clearly indicates the problem is caused by assumptions made in custom code, not by our plugin’s default behavior.

    Unfortunately, we cannot support or adapt our plugin to arbitrary custom mu-plugins. If you can demonstrate how to reproduce this issue using only supported themes and plugins, we will be happy to investigate and fix it.

    Also, per WordPress.org support guidelines, users are strongly encouraged to provide a public test page or reproducible setup. You have not provided one so far, which makes further investigation impossible.

    At this point, the behavior you are seeing is expected given the custom setup involved.

    Many thanks.

    Thread Starter Oliver Campion

    (@domainsupport)

    1 month, 2 weeks ago

    Thank you for your reply. We have found an alternate workaround to resolve the issue.

Viewing 9 replies - 1 through 9 (of 9 total)

You must be logged in to reply to this topic.