Make WordPress Core

Opened 7 weeks ago

Last modified 5 days ago

#60913 assigned enhancement

Remove unnecessary code for ensuring interactivity API dependency in block core functions

Reported by: czapla's profile czapla Owned by: czapla's profile czapla
Milestone: 6.6 Priority: normal
Severity: normal Version: 6.4
Component: Interactivity API Keywords: has-patch dev-feedback
Focuses: Cc:

Description

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 .

Change History (9)

This ticket was mentioned in PR #6354 on WordPress/wordpress-develop by @czapla.


7 weeks ago
#1

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.

#2 @swissspidy
7 weeks ago

Why does this need to be in 6.5? It‘s an enhancement, IMHO this can wait until 6.6

This ticket was mentioned in Slack in #core by jorbin. View the logs.


7 weeks ago

#4 @jorbin
7 weeks ago

  • Milestone changed from 6.5.1 to 6.6

As these were just deprecated in 6.5, I also think no-oping them so quick doesn't give much opportunity for folks to update their code.

Do we know how many plugins/themes are using these functions? Is outreach necessary?

#5 @czapla
7 weeks ago

IMHO this can wait until 6.6

makes sense 👍

Do we know how many plugins/themes are using these functions? Is outreach necessary?

I don't really know how we could know how many plugins/themes are using it. However, prior to 6.5 the Interactivity API was explicitly a private API so I hope that this number is zero.

Technically, people could have added the Interactivity API as a dependency in the same way as it was done for the core blocks (link).

No-oping the block_core_image_ensure_interactivity_dependency & block_core_file_ensure_interactivity_dependency functions should be fine because the File and Image blocks now use the module version of the Interactivity API. So, if we [remove https://github.com/WordPress/wordpress-develop/pull/6354/files#diff-14577b710f11306118fa14601c82e5831f97b353025bfec3b59d9db9c49ecceaL285-L286] the private version of the API, those functions don't do anything.

#6 @oglekler
6 days ago

Are we proceeding with this? It is an enhancement and should be handled before Beta 1. Thank you!

#7 @czapla
5 days ago

I hope we can proceed with this! It would need another review from folks working on the Interactivity API.

#8 @gziolo
5 days ago

  • Component changed from Editor to Interactivity API
  • Version changed from trunk to 6.4

@gziolo commented on PR #6354:


5 days ago
#9

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 https://github.com/WordPress/wordpress-develop/pull/6354#discussion_r1606839683. 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.

Note: See TracTickets for help on using tickets.