Make WordPress Core

Opened 8 weeks ago

Last modified 7 weeks ago

#60597 new enhancement

Script Modules API: Allow list of enqueued module data to be exposed

Reported by: johnbillion's profile johnbillion Owned by:
Milestone: 6.6 Priority: normal
Severity: normal Version: 6.5
Component: Script Loader Keywords: needs-patch
Focuses: Cc:

Description

There's no means for a plugin to fetch a list of registered or enqueued script modules for debugging purposes from the Script Modules API as there is from the existing Scripts Dependencies API.

Most likely the get_import_map(), get_marked_for_enqueue(), get_dependencies(), and get_versioned_src() methods of the WP_Script_Modules should be made public to facilitate this.

Change History (9)

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


8 weeks ago
#1

  • Keywords has-patch added; needs-patch removed

#2 @johnbillion
8 weeks ago

  • Milestone changed from Awaiting Review to 6.5
  • Type changed from enhancement to task (blessed)

#3 @swissspidy
8 weeks ago

Are we comfortable with making all of these public and maintaining backward compatibility going forward?

Now would be the last chance to change anything about the function signature etc.

#4 @swissspidy
7 weeks ago

cc @luisherranz @westonruter

#5 @luisherranz
7 weeks ago

I think it's too soon to expose the internals.

I'd rather expose another function that only returns the list of enqueued/registered module identifiers.

#6 @johnbillion
7 weeks ago

I don't think this can really be considered "internals". The public print_import_map() method mostly just prints a JSON encoded representation of the data from the get_import_map() method which in turn constructs its data from the methods that I'm proposing should be public.

In order for my Query Monitor debugging plugin to show info about script modules in the same way that it does for enqueued scripts and styles, it needs to be able to fetch a list of enqueued modules (get_marked_for_enqueue()), their dependencies (get_dependencies()), and the full source URL (get_versioned_src()).

#7 @luisherranz
7 weeks ago

get_marked_for_enqueue and get_dependencies return a list of script module arrays, not a list of script module identifiers (strings). Those script module arrays are the arrays stored in $registered, and contain all the internal information about a script module.

So instead of making the $registered arrays public, which would mean they can't be refactored in the future, I would expose functions that return the script module identifiers (strings) only. If you need more information than that, like the corresponding src or dependencies of a script module identifier, I would create additional public functions that return a single piece of information (the src, the list of dependencies, etc).

That's just my opinion, though.

#8 @swissspidy
7 weeks ago

Tough one! I understand both sides, though I am probably leaning towards creating dedicated methods for this as suggested by Luis. This would be cleaner and wouldn't put us into a bad spot regarding BC. That would be an enhancement for early 6.6 though in my eyes, given how late in the release cycle we are. It's not ideal for plugins such as Query Monitor, but there might be workarounds.

What do you think?

#9 @johnbillion
7 weeks ago

  • Keywords needs-patch added; has-patch removed
  • Milestone changed from 6.5 to 6.6
  • Type changed from task (blessed) to enhancement

Alrighty let's bump this. I should be able to work around this via the magic of the reflection API for now.

Note: See TracTickets for help on using tickets.