Remove unnecessary code for ensuring interactivity dependency in block core functions

[michalczaplinski]

I'm removing old code for registering the private version of the Interactivity API pre-6.5.

The Interactivity API is being loaded as a script module as of WordPress 6.5.

I've removed the bodies of the previously deprecated functions, now no-ops, since the scripts are being registered as modules here. These functions remain because they were public, but their execution is unnecessary.

Trac ticket: https://core.trac.wordpress.org/ticket/60913#ticket

---

This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Core Committers: Use this line as a base for the props when committing in SVN:

Props czapla, gziolo, shailu25, cbravobernal.

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[github-actions]

Test using WordPress Playground

The changes in this pull request can previewed and tested using a WordPress Playground instance.

WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.

Some things to be aware of

• The Plugin and Theme Directories cannot be accessed within Playground.
• All changes will be lost when closing a tab with a Playground instance.
• All changes will be lost when refreshing the page.
• A fresh instance is created each time the link below is clicked.
• Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
  it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.

[gziolo]

I hope we can safely remove it fully as it was very hard to use private version of Interactivity API. Technically speaking, folks were able to list is as a dependency so this needs to be investigated carefully.

[gziolo]

You can keep the script handle for backward compatibility and skip the file reference this way:

wordpress-develop/src/wp-includes/script-loader.php

Line 864 in ce84e1f

$scripts->add( 'scriptaculous', false, array( 'scriptaculous-dragdrop', 'scriptaculous-slider', 'scriptaculous-controls' ) );

[gziolo]

The simple way to test it, would be to see what happens when a script defines wp-interactivity-api as a dependency with the changes applied. Does it still enqueue?

[michalczaplinski]

I'll test it.

To be clear: with the changes in the current PR, I expect that it should not enqueue the Interactivity API. Are you saying that it should still enqueue the it (for backward compat)?

[gziolo]

No, I’m only talking about verifying that scripts that depend on the wp-interactivity-api script handle continue to enqueue. The example presents how to define a script handle without any file on the disk referenced.

[gziolo]

I recorded a video to illustrate the potential problem better:

Screen.Recording.2024-05-20.at.16.12.30.mov

[michalczaplinski]

ok, I've just tested it and it was never possible for scripts to depend on wp-interactivity in the first place because wp-interactivity is an ES module.

I tried enqueuing a script like:

function my_custom_scripts() {
    wp_register_script(
        'my-custom-script',
        includes_url() . '/js/my-custom-script.js',
        array('wp-interactivity'),
        '1.0.0', 
        true
    );
    wp_enqueue_script('my-custom-script');
}

add_action('wp_enqueue_scripts', 'my_custom_scripts');

it will enqueue both my-custom-script & wp-interactivity as scripts (not script modules) which results in:

Uncaught SyntaxError: Unexpected token 'export' (at index.min.js?ver=1a0bf353a1bf8c59d31b:2070:1)

[gziolo]

It doesn't look like the private version of Interactivity API was exposed as ES Module in WordPress 6.4:

https://github.com/WordPress/WordPress/blob/6.4-branch/wp-includes/js/dist/interactivity.js

It's a regular script that exposes the webpack chunk under __WordPressPrivateInteractivityAPI__ global.

[cbravobernal]

I guess this concern https://github.com/WordPress/wordpress-develop/pull/6354/files#r1550930263 will not apply now that developer's just need to use WP 6.5 for the Interactivity API and we are close to the 6.6 release.

[gziolo]

I guess this concern https://github.com/WordPress/wordpress-develop/pull/6354/files#r1550930263 will not apply now that developer's just need to use WP 6.5 for the Interactivity API and we are close to the 6.6 release.

See the video included in #6354 (comment). It all depends on whether wp-interactivity was used as a dependent script handle. In the current shape of PR, such custom scripts won't get printed on the site. It will prevent potential JS errors, but it will also prevent enqueuing execution of the custom JavaScript. I performed a quick search in the WPDirectory:

wp-interactivity in Plugins: https://www.wpdirectory.net/search/01HYB6GR4B51Y9Q52DQQEHJ03F
wp-interactivity in Themes: https://www.wpdirectory.net/search/01HYB6JDD4TG7V67ME7P77B9NN

It looks like there should be nothing to worry about. so either way is fine with the consequences described above if any script for any reason depends on wp-interactivity script handle.

[gziolo]

Committed with https://core.trac.wordpress.org/changeset/58322.