__group__ ticket summary owner _component _version priority severity milestone type _status workflow _created modified _description _reporter Slated for Next Release 60597 Script Modules API: Allow list of enqueued module data to be exposed Script Loader trunk normal normal 6.6 enhancement new 2024-02-21T23:24:22Z 2024-03-01T12:30:33Z "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." johnbillion Slated for Next Release 60647 Script Modules: Allow modules to depend on existing WordPress scripts jonsurrell Script Loader trunk normal normal 6.6 feature request assigned 2024-02-27T15:40:59Z 2024-03-21T08:07:18Z "Script modules cannot depend on existing scripts such as `wp-url`, `wp-i18n`, or `wp-api-fetch`. Script modules should be able to leverage the functionality available in existing scripts." jonsurrell Tickets Awaiting Review 53848 'is_feed was called incorrectly' notice if `wp_styles()` is called before the query Script Loader 5.8 normal normal Awaiting Review defect (bug) new 2021-07-31T17:20:16Z 2021-12-14T23:59:40Z "WordPress 5.8 introduced the `wp_should_load_separate_core_block_assets` (https://developer.wordpress.org/reference/functions/wp_should_load_separate_core_block_assets/) function which calls `is_feed()` internally as part of its preliminary checks that guard the application of its filter. Since `wp_should_load_separate_core_block_assets` is now called within `wp_default_styles()`, this has the potential to raise a ""doing it wrong"" notice if `WP_Styles` is initialized before the query runs for non-admin requests. `wp_styles()` has never imposed such timing restrictions on when it is called, this is somewhat of a breaking change. Ideally a different condition that does not impose the same limitation could be used in the place of `is_feed` here." aaemnnosttv Tickets Awaiting Review 37362 @font-face errors with dashicons in Microsoft Edge Script Loader normal normal Awaiting Review defect (bug) new 2016-07-14T12:08:36Z 2017-12-11T23:04:04Z "I encountered the following errors in Microsoft Edge console when enter admin dashboard: CSS3113:@font-face font format not recognized dashicons.eot CSS3120: No fonts available for @font-face rule load-styles.php (0,37) This is the following explanation of error code https://msdn.microsoft.com/query/dev12.query?appId=Dev12IDEF1&l=EN-US&k=k%28VS.WebClient.Help.CSS3113%29#cssCodes " jevuska Tickets Awaiting Review 59780 Add functionality to dequeue a block style added via wp_enqueue_block_style Script Loader normal normal Awaiting Review defect (bug) new 2023-10-31T19:53:29Z 2023-10-31T19:53:29Z "Currently there is no API to remove a block style that has been enqueued with `wp_enqueue_block_style`. This makes it harder than neccessary for a child theme to override a blockstyle from a theme. See the discussion in this core thread: https://wordpress.slack.com/archives/C02RQBWTW/p1698774094584149" jorbin Tickets Awaiting Review 43900 Add hint about blocked Javascript as possible error reason in script-loader.php Script Loader normal normal Awaiting Review defect (bug) new 2018-04-29T18:52:58Z 2018-05-02T09:41:14Z "When trying to do various things with a new site, I got the same error message over and over: {{{Connection lost or the server is busy. Please try again later.}}} I even reinstalled, but the error didn't go away. When I revisited the issue next day, finally realized what silly mistake i had made. In order to help other people with same issue, we only need to change the string above in /wp-includes/script-loader.php (around row 840) into: {{{Connection lost, the server is busy, or you may have blocked JavaScript. Please try again later.}}} " tobifjellner Tickets Awaiting Review 55485 Clarify `wp_should_load_separate_core_block_assets()`, `block.json` script expectations Script Loader normal normal Awaiting Review defect (bug) new 2022-03-30T00:49:10Z 2023-10-25T10:27:44Z "In the `block.json` [https://github.com/WordPress/gutenberg/blob/45a8e6be0eb7fca87d64ce8140792b30e6bc4a20/schemas/json/block.json schema], the `script` property is described as: > ""Block type frontend and editor script definition. It will be enqueued both in the editor and when viewing the content on the front of the site."" From that description, I expect the `script` set in my block's `block.json` to load in the editor and on the front-end when my block is in use. I do not expect the script to load on the front-end when my block is not in use. If I activate TwentyTwentyTwo, everything works as expected. If I activate TwentyTwentyOne, my script appears on every front-end view, whether or not the block is loaded. The cause of this can be tracked to `wp_should_load_separate_core_block_assets()`, which has a short description of: > Checks whether separate styles should be loaded for core blocks on-render This implies at the beginning of the function documentation that the function will only apply to **core** blocks. The longer description helps a bit, but is muddied up in talking about core and third-party blocks separately when in reality it seems that they are treated the same. It mentions `block-library/style.css`, which itself implies this _might_ be talking about styles rather than all assets. The filter inside the function, `should_load_separate_core_block_assets`, defaults to `false` for themes that are not FSE and has a short description of: > Filters whether block styles should be loaded separately. The longer description refers only to ""core block assets"". ----- == Proposal My guess is that we can't just change the filter to default to `true`, though that would be ideal. :) I think the function docs could be clarified with something like: {{{ /** * Checks whether block assets should always load or only on-render. * * When this function returns true, block assets defined by the `script` and * `style` properties in `block.json` are loaded on-render. * * When this function returns false, these block assets are always loaded, * regardless of whether the block is rendered in a page. * * This only affects front end and not the block editor screens. }}} And the filter docs with something like: {{{ * Filters whether block assets should always load or load only on-render. * * Returning false loads all block assets, regardless of whether they are rendered * in a page or not. Returning true loads block assets only when they are rendered. }}} Previously #53505 " jeremyfelt Tickets Awaiting Review 45106 Concerns related to moving mce_external_plugins filter to WP_Scripts::__construct Script Loader 5.0 normal normal Awaiting Review defect (bug) new 2018-10-17T13:19:26Z 2019-01-16T22:59:17Z "In r43723 the `mce_external_plugins` filter was moved to a function called via `wp_default_scripts` which, in turn, is called from `WP_Scripts::__construct` (via `WP_Scripts::init`). While the `wp_default_packages_inline_scripts` function calling the `apply_filters( 'mce_external_plugins'` is only triggered in case the `did_action( 'init' )` returns true, there might be cases when the `WP_Scripts` object is being reinitialised after the `init` and thus code hooked to `mce_external_plugins` trying to enqueue or register a script causes an infinite loop, since the constructor of the `WP_Scripts` class is calling the filter, which calls the constructor again. This does not feel like something what would matter in 99% of time, but, for instance, this breaks core unit tests which are reinitialising the WP_Scripts object, eg.: `Test_WP_Customize_Selective_Refresh::test_register_scripts`. in case such a piece of code is being used. An example of a code used in a mu-plugin and breaking the mentioned test: {{{#!php registered->editor->extra['after']`. It will have two array values - one is `false` and one is the actual data `window.wp.oldEditor = window.wp.editor;` Or via debugging by putting a breakpoint in `wp-includes/class.wp-scripts.php` in `add_inline_script()` for `$script = (array) $this->get_data( $handle, $position );`" vanyukov Tickets Awaiting Review 45008 Inconsistent use of 'script_loader_src' and 'style_loader_src' filters when performing concatenation Script Loader 2.8 normal normal Awaiting Review defect (bug) new has-patch 2018-09-27T09:21:24Z 2018-09-27T09:21:24Z "When in admin, scripts and styles from default directories (in other words, from `/wp-includes` and `/wp-admin`) will by default be concatenated. But, there is inconsistency in how `script_loader_src` and `style_loader_src` filters are used in that case. `style_loader_src` is [https://core.trac.wordpress.org/browser/trunk/src/wp-includes/class.wp-styles.php?rev=43564#L162 not used] when doing concatenation. It receives only full URL of style and is used only in [https://core.trac.wordpress.org/browser/trunk/src/wp-includes/class.wp-styles.php?rev=43564#L329 that case]. `script_loader_src` is used twice. [https://core.trac.wordpress.org/browser/trunk/src/wp-includes/class.wp-scripts.php?rev=43583#L332 One case] is the same as for `style_loader_src`: only for final, full URL of script. But in [https://core.trac.wordpress.org/browser/trunk/src/wp-includes/class.wp-scripts.php?rev=43583#L279 second case], it is used when doing concatenation. It is not only inconsistent with its first usage or usage of `style_loader_src`, it also doesn't really makes sense. It filters path relative to root, not final URL, and result of that filtering is only used when checking if source is in default directories and nowhere else. I don't see what it can really do. This second case was introduced in [10357] by @azaozz. Before that, filter [https://core.trac.wordpress.org/browser/trunk/wp-includes/class.wp-scripts.php?rev=10356#L73 was used] the same way it is used now for the other case. In that same changeset, concatenation was also added for styles, but counterpart filter [https://core.trac.wordpress.org/changeset/10357#file7 was not added]. I propose that we remove second case of `script_loader_src`, used when doing script concatenation." dimadin Tickets Awaiting Review 59114 Infinite loop after upgrading from WordPress 6.1.3 to 6.2 Script Loader 6.3 normal normal Awaiting Review defect (bug) new 2023-08-15T20:20:09Z 2023-08-30T18:10:34Z "Regeristing a function with the 'wp_video_shortcode_library' filter hook that enqueues a script causes an infinite loop, resulting in WordPress running out of memory. It seems that the $wp_scripts global is being set to null at some point and being reinitialized, which causes this loop since the 'wp_video_shortcode_library' filter is called as part of the wp_default_scripts function in script-loader.php. This is my theory anyways. I'm not familiar enough with the WordPress codebase to say for sure. To recreate this issue, you can make a basic theme with an empty index.php, only the theme definition inside the style.css, an empty js file (to try to enqueue), and a functions.php that registers the hook. {{{#!php 'my-theme-buttons', 'src' => get_theme_file_uri( 'assets/blocks/buttons.css' ), ); // Add ""path"" to allow inlining asset if the theme opts-in. $args['path'] = get_theme_file_path( 'assets/blocks/buttons.css' ); // Enqueue asset. wp_enqueue_block_style( 'core/buttons', $args ); } ); }}} === Result Output inline. {{{ }}} The path /wp-content/themes/abc/assets/blocks/ is not needed. I want to delete it. Is there any solution? Or is it a bug? " s56bouya Tickets Awaiting Review 40134 Invalid data for scripts in footer Script Loader normal normal Awaiting Review defect (bug) new 2017-03-12T16:37:24Z 2017-03-12T16:37:24Z "During register scripts via wp_register_script in last param I can choose that script should be in footer. In function we see: {{{#!php add_data( $handle, 'group', 1 ); } }}} so footer scripts I should check use this code: {{{#!php get_data( $handle, 'group' ) ) { echo 'in footer'; } else { echo 'in header'; } }}} I check for this: admin-bar and I have false -> `in header`. We can see this code: {{{#!php add( 'admin-bar', ""/wp-includes/js/admin-bar$suffix.js"", array(), false, 1 ); }}} This should be in footer (and is, but I can't check it via my script). I think that this is bug." sebastian.pisula Tickets Awaiting Review 47789 "NGINX: Request for media-view.js leads to ""zero size buf in writer""" Script Loader normal normal Awaiting Review defect (bug) new 2019-07-28T13:14:52Z 2019-10-20T11:56:28Z "I do currently have an issue loading the media-view.js file in backend, which leads to multiple js errors on pages or media grid. Checking the logs show an ""zero size buf in writer"" error for these requests. The error occurs even on deactivated plugins and default theme. So I tried to debug this down. I am running multiple WordPress sites locally over NGINX (laravel) in development mode, where SCRIPT_DEBUG is true; so it tries to load the unminidfied version of the file. Replacing it´s content with the minified version solves the bug. I do currently not know, what causes the empty buffer." d.sturm Tickets Awaiting Review 49742 No longer able to enqueue multiple Google Fonts with wp_enqueue_style Script Loader normal normal Awaiting Review defect (bug) new 2020-03-31T16:03:07Z 2021-11-10T00:04:08Z "I'm using wp_enqueue_style to enqueue this Google Font file. Here is my code: wp_enqueue_style( 'google-fonts', 'https://fonts.googleapis.com/css2?family=Montserrat:ital,wght@0,300;0,400;0,700;1,400&family=Neuton:ital,wght@0,300;0,400;0,700;1,400&display=swap', [] ); This is in my functions.php file. However, when I view source on my loaded page, the URL for that font file is cut down to: https://fonts.googleapis.com/css2?family=Neuton%3Aital%2Cwght%400%2C300%3B0%2C400%3B0%2C700%3B1%2C400&display=swap&ver=5.3.2 As you can see, the first family param has been removed after being outputted through wp_enqueue_style. Is there a way to fix this without doing anything hacky? I think there may be an outdated way to build the URL to both to come through, but I'd rather be able to use what Google now provides. My original URL inside wp_enqueue_style is the URL generated by Google Fonts for me to embed. SO post here: https://stackoverflow.com/questions/60953810/why-cant-i-enqueue-multiple-google-fonts-in-wordpress-functions-php/60954323#60954323" tannerm Tickets Awaiting Review 40737 Script tags inside unclosed HTML comment in value passed to WP_Script->localize() breaks page Script Loader normal normal Awaiting Review defect (bug) new has-patch 2017-05-11T19:26:30Z 2017-06-01T18:45:45Z "Hi. Thanks for your time. I encountered an edge case with the WP_Script->localize() method that can cause malformed html and cause javascript on the page to break. Our site has a custom field for adding pixel tracking code html snippets. On the post edit admin page, the values from the custom fields are run through the localize method by the Wordpress-SEO plugin which adds their values to the wpseoReplaceVarsL10n var. One of our users pasted code into this field like the following: {{{ }}} This gets serialized to JSON by WP_Script->localize and ends up being output like this. I simplified the structure a bit for the example. {{{ }}} (again, you see ‘&‘ instead of just ‘&’) You can find these issues on: https://forcesail.ru/" forcesail Tickets Awaiting Review 47350 Add method to get JSON from a file without using file_get_contents() Script Loader 5.3 normal normal Awaiting Review enhancement new 2019-05-22T18:39:40Z 2019-05-22T19:51:49Z "This came up on a discussion about the use of `file_get_contents()` in WP Themes. Right now that function is banned and for good reason on w.org themes since it can be grossly abused and lead to malicious code. However, recently it became a recommendation in https://github.com/WordPress/gutenberg/blob/9ce596cd568d30c76fd4a0257e2872da91d4966a/packages/dependency-extraction-webpack-plugin/README.md#wordpress There was further discussion in the #core-editor slack channel - see https://wordpress.slack.com/archives/C02QB2JS7/p1558546491251400 for reference. The suggestion was to add a new method/function to get what is required, without forcing plugin and theme authors to use `file_get_contents()`, and we could add any security checks required in that function." aristath Tickets Awaiting Review 38548 Add new filters on wp_script_is/wp_style_is Script Loader 4.7 normal normal Awaiting Review enhancement new 2016-10-28T13:41:52Z 2019-03-26T13:30:07Z "Minification engines tend to group dependencies and then enqueue them in a single file so enqueues handles change their names. So imagine this situation: Handles `style-1` and `style-2` are now grouped into a file and the new handle name is `group-1` Once grouping is done `wp_style_is('style-1', 'done')` won't work as style-1 and 2 are now inside `group-1` so `wp_style_is('group-1', 'done')` would work but this is just known by the plugin that minifies the styles/scripts. I don't know if the point is clear enough. By adding a new filter this would help a lot to remap those handles names. The filter can be placed easily in `WP_Dependencies::query()` method like this: {{{#!php registered[ $handle ] ) ) { $query = $this->registered[ $handle ]; } break; case 'enqueued' : case 'queue' : if ( in_array( $handle, $this->queue ) ) { $query = true; } else { $query = $this->recurse_deps( $this->queue, $handle ); } break; case 'to_do' : case 'to_print': // back compat $query = in_array( $handle, $this->to_do ); break; case 'done' : case 'printed': // back compat $query = in_array( $handle, $this->done ); break; } return apply_filters( 'script_is_query', $query, $handle, $list, $this ); } }}} Any thoughts? " igmoweb Tickets Awaiting Review 60163 Block editor admin assets should use asset file version when in debug/local mode Script Loader normal normal Awaiting Review enhancement new 2023-12-28T15:08:56Z 2023-12-28T15:08:56Z "Admin assets defined in block.json are enqueued in the editor with the version property from block.json of if not defined, the version of WordPress. [source](https://github.com/WordPress/wordpress-develop/blob/455044e6261e64970fb9039dba52ceb47290a634/src/wp-includes/blocks.php#L273) That's fine for plugin release, but for development it means you can build a block using the [create block script](https://developer.wordpress.org/block-editor/reference-guides/packages/packages-create-block/), run `npm run start` and the editor ''style'' assets get compiled correctly as you work but the browser keeps showing the cached version stylesheet. Editor scripts however, [pull a version from the `index.asset.php`](https://github.com/WordPress/wordpress-develop/blob/455044e6261e64970fb9039dba52ceb47290a634/src/wp-includes/blocks.php#L194) so it's always refreshed on page reload. I'd love to see the order go something like: If dev mode (either `WP_DEVELOPMENT_MODE` or `WP_ENVIRONMENT_TYPE` constants then use the version of `index.asset.php`. If ''not'' dev mode, use the version from the block.json file. Finally, default to the version of WordPress. " helgatheviking Tickets Awaiting Review 51200 Consider a better way to deprecate JavaScript code Script Loader normal normal Awaiting Review enhancement new 2020-08-31T20:56:32Z 2020-08-31T21:30:53Z "Background: #51123 At the moment, we have some established functions for deprecating PHP functionality: * `_deprecated_function()` * `_deprecated_constructor()` * `_deprecated_file()` * `_deprecated_argument()` * `_deprecated_hook()` As well as some files to move deprecated functions to: * `wp-admin/includes/deprecated.php` * `wp-admin/includes/ms-deprecated.php` * `wp-includes/deprecated.php` * `wp-includes/ms-deprecated.php` * `wp-includes/pluggable-deprecated.php` We don't, however, have a similar way to deprecate JavaScript functionality, sometimes leading to more breakage than necessary when removing global objects or properties without backward compatibility considerations. [48923] attempted to improve things a bit introducing `deprecatedProperty()`. Some ideas previously suggested to further make sure we have a way to deprecate JavaScript code properly: * Have a clear deprecation policy of when the affected code should be removed. * Use the [https://developer.wordpress.org/block-editor/packages/packages-deprecated/ @wordpress/deprecated] package (suggested by @ocean90 in comment:33:ticket:51123). * Create a `deprecated.js` file for the code to be moved to (suggested by @desrosj on Slack)." SergeyBiryukov Tickets Awaiting Review 60734 Deregistering Open Sans Script Loader 6.4.3 normal normal Awaiting Review enhancement new 2024-03-09T02:15:43Z 2024-03-09T10:31:21Z "I have wasted an entire day trying to figure out why my Open Sans styles were not applying. This is counterproductive/suboptimal. As it turns out, Open Sans was packed in WP back in 2014, which is fine by me. More info: #28478 However it is **not** immediately **obvious** one needs to `wp_deregister_style('open-sans');` before he can register his own style. Please, consider making an exception and make `wp_register_style()` automatically `wp_deregister_style(X)` if X equals 'open-sans'. Otherwise consider other courses of action that may prevent others from incurring in the same problem I did. Thanks. " ecv80 Tickets Awaiting Review 40602 Implement immutable cache headers Script Loader normal normal Awaiting Review enhancement new 2017-04-29T00:01:18Z 2017-04-29T15:35:05Z "When you have js files that will not change in a certain version of Wordpress, why not set the immutable cache that is enabled on various browsers? https://hacks.mozilla.org/2017/01/using-immutable-caching-to-speed-up-the-web/ For example this url should never change output unless user changed the wordpress version, in which case the ver= will change, forcing browser to load that url. /wp-admin/load-scripts.php?c=gzip&load%5B%5D=jquery-core,jquery-migrate,jquery-ui-core,jquery-ui-widget,jquery-ui-mouse,underscore,mediaelement,jquery-ui-sortable&ver=4.7.4" programmin Tickets Awaiting Review 43403 Improve wp_add_inline_script() Script Loader normal normal Awaiting Review enhancement new 2018-02-24T12:47:09Z 2018-02-24T12:47:09Z "Just an idea for the moment: Instead of testing if the js has script tags and adding an error messages but also fixing the problem at the same time, why not accept both. If the passed data has tags just leave them (this would potentially fix #40276) and if not surround the code with plain `\n"", $this->type_attr, $src, esc_attr( $handle ) ); }}} adding defer or async attributes still requires usage of ""script_loader_src"" or ""script_loader_tag"" filters." szaqal21 Tickets Awaiting Review 59076 Proposal for removing the version numbers of the JS and CSS files when SCRIPT_DEBUG is set to true Script Loader normal normal Awaiting Review enhancement new 2023-08-11T18:14:26Z 2023-08-11T18:14:54Z I am proposing to remove the version numbers of the JS and CSS files when SCRIPT_DEBUG is set to true. As SCRIPT DEBUG is generally used for developers, in development environments, it's evident that the version numbers can make the changes to the files not reflect on the front end. So, I would suggest adding the functionality of removing the version tags of the scripts, and styles as well when using this constant. rajinsharwar Tickets Awaiting Review 60234 Script Modules API: Add a translations API Script Loader normal normal Awaiting Review enhancement new 2024-01-11T15:14:58Z 2024-02-27T15:47:35Z "Now that WordPress is going to support native ES modules through the new [https://core.trac.wordpress.org/ticket/56313 Modules API], we should start discussing possible translation APIs to support internationalization/localization, similar to what `wp_set_script_translations` provides for the Scripts API. Some of the initial considerations are: - It should support the dynamic loading of translations when used in conjunction with dynamic imports (`import()`) to avoid downloading all the translations on page load. - Ideally, it should download the translations required in the initial page load in parallel to avoid waterfalls on page load. - Ideally, it should rely only on available PHP and JavaScript APIs, and not require any specific tooling. - Ideally, the APIs should be as transparent as possible to the developers. Please share your opinions and ideas. Let's use this ticket for discussion." luisherranz Tickets Awaiting Review 60596 Script Modules API: Enable in the admin area Script Loader trunk normal normal Awaiting Review enhancement new 2024-02-21T23:18:18Z 2024-02-21T23:18:18Z "The script modules API added in #56313 only includes hooks to output modules on the front end of a site (`wp_head` and `wp_footer`). This feature should work in the admin area too. From https://core.trac.wordpress.org/ticket/56313#comment:49: > > This feature only works on the front end, not within the wp-admin area, is this intentional? > > It's not. Feel free to add a new ticket to add hooks for the admin." johnbillion Tickets Awaiting Review 43825 Style/script loading infrastructure: Etag header as a hash of script/style handles and their corresponding versions Script Loader normal normal Awaiting Review enhancement new 2018-04-21T08:27:55Z 2019-01-16T06:50:09Z "We've been exploring on how to bundle styles and scripts together for different block types in Gutenberg (https://github.com/WordPress/gutenberg/pull/6087#issuecomment-382888928) It looks like the inbuilt infrastructure for concatenating and bundling assets (load-styles.php and load-scripts.php) might be a good fit for bundling assets in Gutenberg. However, it looks like we will run into an issue with this approach. load-styles.php and load-scripts.php use the current WordPress version as the value of the Etag header. So if a plugin/theme developer modifies some CSS / JS for their block type, the browser will not attempt to fetch the latest content since the value of the Etag header will remain the same (since the WordPress version will remain the same). We can add some functionality in load-styles.php and load-scripts.php to support this: **Specify the value of the Etag header as a hash of the script/style handles and their corresponding versions.** So, if we get a request to load styles for paragraph and image block like this: > /load-styles.php?load=core-paragraph-block,core-image-block We can generate the Etag like this: > etag = hash_function( 'core-paragraph-block-v1.1-core-image-block-v8.3') and supply this value in the Etag header in the response to the browser. This will make sure that the next time the plugin/theme developer changes the CSS / JS for a block type (meaning changes the version of the script/style handle), the hash function will automatically generate a new value for the Etag header and the browser will therefore fetch the latest style / script bundle. **We can add this functionality in load-styles.php and load-scripts.php as an add-on to the current functionality (to preserve backward compatibility).** Maybe, this new functionality can be triggered if a specific URL parameter is included in the request to load-styles.php / load-scripts.php. Maybe, something like: /load-styles.php?etag=content_hash. Do you think we can go ahead with this approach? If yes, I can propose a patch for adding this functionality." kanishk.dudeja Tickets Awaiting Review 48880 Using JSON.parse instead of an actual object literal when localizing scripts Script Loader normal normal Awaiting Review enhancement new has-patch 2019-12-05T00:34:18Z 2019-12-06T20:17:43Z "As the V8 team at Google stated in their ""The cost of JavaScript in 2019"" [https://v8.dev/blog/cost-of-javascript-2019#json]"" blog post using {{{JSON.parse()}}} is generally faster (~18%) for configuration object literals such as the output of the localize method of the WP_Scripts class. As the output of the localize method is already rendered using {{{wp_json_encode()}}} the change would be quite trivial and backward compatible. Added a diff with additional changes to the block editor init script using the same method." naxvog Tickets Awaiting Review 38800 add WP_ADMIN_URL and WP_INCLUDES_URL constants Script Loader normal normal Awaiting Review enhancement new 2016-11-15T17:20:25Z 2017-09-29T06:27:09Z "If WP is installed in a sub directory we can use a subdomain pointing to wp-content directory and set the {{{WP_CONTENT_URL}}} in wp-config.php to hide the path WP is installed in. But the HTML code still yields information about the path because the WP default scripts and styles are loaded from wp-includes resp. wp-admin directory. Of course those URLs can be changed using the {{{script_loader_src}}} filter. But to obviate the need for using this filter and to remove this lack of consistency it should be possible to define {{{WP_ADMIN_URL}}} and {{{WP_INCLUDES_URL}}} in wp-config.php '''Sample Code''' For testing I've added two functions {{{#!php function wp_get_admin_url() { if ( defined( 'WP_ADMIN_URL' ) ) { return trailingslashit( WP_ADMIN_URL ); } return '/wp-admin/'; } function wp_get_includes_url() { if ( defined( 'WP_INCLUDES_URL' ) ) { return trailingslashit( WP_INCLUDES_URL ); } return '/wp-includes/'; } }}} Also I've made changes to wp-includes/script-loader.php. I've added the following lines to functions {{{wp_default_scripts()}}} and {{{wp_default_styles()}}} {{{#!php $admin_src = wp_get_admin_url(); $includes_src = wp_get_includes_url(); }}} Then I've changed every occurrence of {{{$scripts->add()}}} and {{{$styles->add()}}} to use those variables instead of the fixed path. This works as expected to hide the directory WP is installed in from the WP default scripts and styles. I'm pretty sure there's a lot more to change but I wanted to bring this up for discussion first and I'm eagerly waiting for feedback. Notes: I'm a newbie here so please excuse if I did't follow the usual procedure and let me know how to do better. And second please be bear with me that I'm not a native english speaker. Peter " petersplugins Tickets Awaiting Review 43781 adding apply_filters on $handle in localize Script Loader 4.9.5 normal normal Awaiting Review enhancement new 2018-04-16T14:26:34Z 2018-04-16T14:51:26Z "in functions.wp-scripts.php we have: return $wp_scripts->localize( $handle, $object_name, $l10n ); it would be nice to have an apply_filters on the $handle (with object_name as an argument optionally), since it would make overwriting it e.g. for a global concat minified file much easier & faster. (bc now I have to get the scripts, then loop over it, localize the group,...) while I could do the whole thing with an apply_filters within 1 line. " DuckDagobert Tickets Awaiting Review 40276 enhancement: add a $type parameter to wp_add_inline_script() Script Loader 4.7.3 normal normal Awaiting Review enhancement new 2017-03-27T16:45:16Z 2021-11-08T02:56:24Z "It would be helpful to add a $type parameter to wp_add_inline_script(). Currently, it can only output scripts of type text/javascript. If you want something of another type, you need to either use the script_loader_tag filter (which gets run for every script), or manually add the script using a wp_head action. This will require changing several functions: * wp_add_inline_script() * WP_Scripts::add_inline_script() * WP_Scripts::do_item() * WP_Dependencies::add_data() * _WP_Dependency::add_data() Along with the data structure (array) used by add_data." paulschreiber Tickets Awaiting Review 37162 wp_style_add_data and wp_script_add_data should accept SRI information Script Loader 4.5.3 normal normal Awaiting Review enhancement new 2016-06-24T01:34:38Z 2018-11-14T15:27:09Z "Subresource Integrity Hashes (SRI) is now recommended for many CDN sourced CSS and JavaScript as provided for in http://www.w3.org/TR/SRI/ . WordPress does not allow SRI code (or anything other than a set list) to be added via wp_*_add_data. The same applies to javascript loading in addition to stylesheet loading. wp_*_add_data should support these tags instead of currently silently ignoring them. The two tag keys are crossorigin and integrity. Example of recommended link tags that should be generated: {{{ }}} Expected (currently non-working usage) {{{ wp_enqueue_style('bootstrap', ""https://maxcdn.bootstrapcdn.com/bootstrap/4.0.0-alpha.2/css/bootstrap.min.css"", array(), null, 'all'); wp_style_add_data('bootstrap', 'crossorigin', 'anonymous'); wp_style_add_data('bootstrap', 'integrity', 'sha384-y3tfxAZXuh4HwSYylfB+J125MxIs6mR5FOHamPBG064zB+AFeWH94NdvaCBm8qnd'); }}} " michaelkrieger Tickets Awaiting Review 44211 Add cookie domain to `userSettings` script localize Script Loader normal normal Awaiting Review feature request new has-patch 2018-05-24T08:30:04Z 2020-10-12T19:56:06Z I have cookie path and secure status but I need have `domain` param in array too. I think that this will helpful. sebastian.pisula Tickets Awaiting Review 40485 Add function for retrieving metadata from registered script Script Loader 4.2 normal normal Awaiting Review feature request new has-patch 2017-04-19T17:15:32Z 2017-06-07T21:13:49Z "There is currently a function for adding metadata to a registered script (`wp_script_add_data()`), but no function for retrieving that metadata. '''My use case''' I am trying to write a unit test for a function in my plugin that generates data and calls `wp_localize_script()` to ensure the expected data is passed for localization. '''Other Use Cases''' I could see other use cases where a plugin could change a metadata value or add a new key if a certain value is assigned to a certain key." desrosj Tickets Awaiting Review 58873 Add function to pass variables to scripts Script Loader 5.7 normal normal Awaiting Review feature request new 2023-07-22T03:36:51Z 2023-07-22T03:36:51Z "Since WordPress 5.7 using `wp_localize_scripts` to pass variables to registered scripts throws a `_doing_it_wrong` notice. The suggested ""correct"" way of passing variables to scripts, using `wp_add_inline_script`, feels like a step backwards. - Instead of just passing a variable name and value through a PHP function, that abstracts all of this away, we now have to write fully qualified JavaScript code in PHP strings. - We have to actually parse/decode the values being passed on a case-by-case basis. `wp_localize_script` did this reliably. - Using `wp_add_inline_script` is more verbose and prone to errors. Static analysis tools will not work on PHP strings. - It makes for uglier code that is less human-readable. On a personal note, Converting to `wp_add_inline_script` feels a lot more like I'm ""doing it wrong"" than using `wp_localize_script`. It's simple, short and it works. (I do feel chagrined to see Query Monitor show up brown on every page load. But not enough to go and make my code uglier.) I also doubt other ""in the wild"" developers will forego the use of `wp_localize_script` because of the `_doing_it_wrong` notice. The `wp_add_inline_script` alternative is simply not as robust. Suggestion: Add a function `wp_pass_variables_to_script` (or probably a shorter name) to re-introduce the robust functionality provided by `wp_localize_script`." apedog Tickets Awaiting Review 47285 Better Management of External Asset Dependencies Script Loader normal major Awaiting Review feature request new 2019-05-15T18:36:15Z 2021-01-25T22:53:10Z "**Tl;Dr**: there **must** be a way for WordPress Plugins to indicate compatible versions of external dependencies, so as to reduce enqueuing multiple copies of the same external library. The issue is urgent with the ecosystem's migration to Blocks. **Problem** We've all been there; you install 3 plugins, and your website is enqueuing four copies of FontAwesome, and two copies of Bootstrap. Plus an extra one of each from your theme. Plus 3 different datepicker libraries and two `