Enqueued scripts should use `plugins_url()` instead of `plugin_dir_url()`

[westonruter]

Feature Description

When the URLs for JS files are generated in the plugins, the plugin_dir_url() function is used. Its output is concatenated with the relative path:

performance/plugins/optimization-detective/detection.php

Line 82 in 5fbd82e

wp_json_encode( add_query_arg( 'ver', OPTIMIZATION_DETECTIVE_VERSION, plugin_dir_url( __FILE__ ) . 'detect.js' ) ),

However, this is not ideal because the resulting URL is not directly filterable. It would be better to use plugins_url():

- add_query_arg( 'ver', OPTIMIZATION_DETECTIVE_VERSION, plugin_dir_url( __FILE__ ) . 'detect.js'
+ plugins_url( add_query_arg( 'ver', OPTIMIZATION_DETECTIVE_VERSION, 'detect.js' ), __FILE__ )

In this way, the plugins_url filter can be used to potentially rewrite the URL to point to a CDN, for example.

See instances: https://github.com/search?q=repo%3AWordPress%2Fperformance%20%2Fplugin_dir_url%5C(%2F&type=code

[felixarntz]

@westonruter I'm not sure I agree with your assessment:

• plugin_dir_url() wraps plugins_url(), so the URL up to the plugin's own directory is still filterable.
• This means e.g. changing to point to a CDN works just as well with plugin_dir_url().
• I don't see any benefit of being able to filter the remainder of the URL (the path relative to the plugin's directory). You can't (or at the very least shouldn't) change the contents of a plugin from the outside, so being able to filter that part makes no sense to me. It's safer not to allow filtering it.

[westonruter]

A couple additional use cases for being able to filter the entire URL:

• Replace a minified JS or CSS file with a non-minified one, or vice-versa. This requires adding/removing .min from the URL path. (Example filter from Jetpack.)
• Add a cache busting query parameter.

Jetpack favors plugins_url() over plugin_dir_url() with 62 files vs 8 files, respectively.

Maybe more importantly, Gutenberg also favors plugins_url() over plugin_dir_url(), with 32 files vs 5 files, respectively.

[SohamPatel46]

Hello 👋
I would like to work on this issue and update the url function, if its still relevant here.
Thanks.

[felixarntz]

Thanks @SohamPatel46 for the offer! I think for now we're still discussing whether or not we should make this change. Curious if you have any thoughts on it.

One additional benefit I see with plugin_dir_url() over plugins_url() is that it's better aligned with plugin_dir_path(), which is also commonly needed in plugins. There is no plugins_path() function, so plugins_url() wouldn't be the same. Regarding the ability to filter the entire URL that you mention @westonruter, I guess this means it wouldn't be possible for the CSS/JS file path. Granted, this is probably less important than filtering the URL, but still a potential drawback and at the very least an inconsistency.

From a consistency and ergonomics perspective I'm in favor of keeping plugin_dir_url(), as it aligns with plugin_dir_path(). Additionally, plugins_url() is a lower-level function (as indicated by that it's being used within plugin_dir_url()), and its name is less intuitive to the purpose we'd be using it for, which is to get a specific plugin's asset URL, whereas "plugins URL" sounds more about a URL within the overall wp-content/plugins directory - which still works of course, but it's less intuitive.

[SohamPatel46]

Hello @felixarntz,

As mentioned by @westonruter Jetpack and Gutenberg mostly uses plugins_url() whenever we want a path appended at the end of the URL. So, I think that should be a good practice to use plugins_url() whenever we want to append a path to the URL, rather then manual concatenation to plugin_dir_url()'s output.

Also I think plugin_dir_url() internally uses plugins_url() with keeping an empty path ( ' ' ) as first argument. Ref. So, possibly I dont see any issue upgrading to plugins_url() function.