__group__,ticket,summary,owner,_component,_version,priority,severity,milestone,type,_status,workflow,_created,modified,_description,_reporter
Candidates for Closure,49192,All plugin style tags are empty after upgrade to 5.3.2,,Script Loader,5.3.2,normal,major,Awaiting Review,defect (bug),new,reporter-feedback,2020-01-13T21:51:00Z,2020-01-20T16:10:06Z,"I have run into serious problems today. One of our main sites (https://www.biodiversityireland.ie) which has been around a long time and is always stable was being updated. It was running 5.2.4. All plug-ins were updated and the site was verified working perfectly.
Finally WordPress 5.3.2 was installed and the problems began. The front-end is fine but CSS is missing from all of the back-end plug-ins. These are not obscure plug-ins either they are those like WooCommerce, LiteSpeed Caching and so forth. Many are on the 20 tested for 5.3.2.
Strangely nothing was shown in the console which could cause it and I did the whole disabling plug-ins approach with no results. Finally I believe I have found what's wrong. All of the CSS links in the admin screen are empty!! See attached screenshot from the developer tools in Chrome.
In order to be thorough I performed the exact same steps on another site which was on the same version. Exactly the same results, all was fine across the board until the 5.3.2 was installed.
I cross checked with another site on the same theme and the links are not empty prior to 5.3.2.
I'm hoping someone can help me with this or has had the same issue since I would prefer not to have to go hacking in a downgrade.
I've done a few hours of testing and the closest I found were these two gentlemen whose issues were similar but not the same since my styles are empty and missing completely.
https://zerogravitymarketing.com/updating-to-wordpress-5-3-caused-admin-css-issues/
https://wordpress.org/support/topic/wordpress-backend-css-broken-after-updating-to-5-3/",nbdcadmin
Candidates for Closure,55695,error on script_loader.php,,Script Loader,5.9.3,normal,normal,Awaiting Review,defect (bug),new,reporter-feedback,2022-05-07T13:29:41Z,2022-05-07T16:22:55Z,"i'm have problem in wp-includes/script_loader.php and placed this
{{{
if (!is_null( $wp_styles) and !is_null( $wp_styles->queue)) {
}}}
in line 2740 (and closed after block) and solved this error
Maycon
",maycon3
Candidates for Closure,59132,Create two filters in wp_scripts() and wp_styles().,,Script Loader,4.2,normal,normal,Awaiting Review,enhancement,new,reporter-feedback,2023-08-17T18:19:00Z,2023-11-27T21:00:48Z,"I'd like to know if it's possibile to change this:
{{{#!php
init();
if ( ! did_action( 'init' ) ) add_action( 'init', array( $this, 'init' ), 0 );
}
}}}
Sasa
",stodorovic
Candidates for Closure,34591,"BugFix to WP_Scripts::do_item(), remove doubled ""//""",,Script Loader,4.3.1,normal,normal,Awaiting Review,defect (bug),new,needs-unit-tests,2015-11-05T11:01:37Z,2017-02-05T09:08:07Z,"Current code in `do_item()` of class.wp-script.php on line 172:
{{{
$src = $this->base_url . $src;
}}}
may produce duplicate slashes `""//""`, resulting in problems.
This might be fixed with code:
{{{
$src = $this->base_url . $src;
}}}
Currently:
* WP_Scripts contains: `""public $base_url; // Full URL with trailing slash""` and
* script-loader.php contains calls `$scripts->add()` with initial `""/""` in relative paths
Together this produces doubled slashes `""//""`. For example:
http://www.ocelovehaly.cz/ll//wp-includes/js/jquery/jquery.js?ver=1.11.3
This makes W3TC include script in minified version, but not to remove it from the original HTML.
Including jQuery twice makes LayerSlider not to work.
Please, could you bugfix class.wp-script.php on line 172?
Thank you :-)",jan.mazanek
Candidates for Closure,54956,"[5.9] wp_block_type args - ""style"" and ""script"" are always loaded on Frontend",,Script Loader,5.9,normal,normal,Awaiting Review,defect (bug),new,needs-unit-tests,2022-01-27T17:15:29Z,2022-07-19T13:58:22Z,"Before 5.9 - `style` and `script` are loaded when the block is added to specific page.
After 5.9 - `style` and `script` are always loaded, on all pages, all the time, everywhere, regardless if the block is displayed on specific page or not.
More info about my use case:
- `style` and `script` both reference a registered script/style, which have multiple dependencies (`wp_register_style` has `$deps` array defined that references more registered styles)
Temporary fix I did to the client code:
- Replacing `style` and `script` with `styles` and `view_script` fixed the issue
However this ""fix"" requires specific WP Core version - 5.8.3 should use `style` and `script`, while 5.9 should use `styles` and `view_script`.",pkostadinov
Tickets with Patches,46089,Memory exhaustion when setting script translations on `wp-i18n`,,Script Loader,,normal,normal,Future Release,defect (bug),new,needs-unit-tests,2019-01-24T00:47:26Z,2021-02-04T05:53:32Z,"A memory exhaustion occurs given the following snippet of code:
{{{#!php
Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 262144 bytes) in /srv/www/editor/htdocs/wp-includes/class.wp-dependencies.php on line 324
}}}
Memory exhaustion occurs here:
https://github.com/WordPress/WordPress/blob/4e3e9ca9cf893190609728848caf224034fd1ef0/wp-includes/class.wp-dependencies.php#L338
I think it stems from this line:
https://github.com/WordPress/WordPress/blob/4e3e9ca9cf893190609728848caf224034fd1ef0/wp-includes/class.wp-scripts.php#L517
Where `wp-i18n` is adding itself as a dependency.
Could probably do for a simple check to ensure that the incoming handle is not `wp-i18n`.",aduth
Tickets with Patches,35963,Only remove item from WP_Dependencies::to_do if it was successfully processed,,Script Loader,,normal,normal,,defect (bug),new,needs-unit-tests,2016-02-26T12:37:32Z,2019-06-04T21:20:31Z,"If WP_Dependencies::do_item returns false, the item is removed from being processed again. Due to this, if an item gets switched to the footer, it is never actually outputted. A common scenario is depending on jquery which depends on jquery-core and jquery-migrate. jquery is processed right, but jquery-core and jquery-migrate are moved to the bottom but still removed from the list.
The following example demonstrates:
{{{#!php
registered['jquery'];
wp_dequeue_script('jquery');
wp_deregister_script('jquery');
wp_register_script('jquery', $jquery->src, $jquery->deps, $jquery->ver, true);
}
}, 0);
}}}
Attached is a very simple patch to resolve this",pcfreak30
Tickets with Patches,37185,"wp_print_styles() doesn't call ""wp_print_styles"" action when ""$handles"" argument passed",,Script Loader,3.3.1,normal,normal,,defect (bug),assigned,needs-unit-tests,2016-06-26T13:53:32Z,2019-06-04T21:24:27Z,"In {{{wp_print_styles()}}}, there is ""wp_print_styles"" action calls when function is used with optional ""$handles"" argument.
{{{if ()}}} statement should be deleted ( like {{{wp_print_scripts()}}} ).
Unit tests are passed.",evgenniy
Unpatched Bugs,37756,Allow inline scripts on script aliases,,Script Loader,4.5,normal,normal,Future Release,defect (bug),new,needs-unit-tests,2016-08-21T06:46:10Z,2019-12-13T22:21:50Z,"It appears if {{{add_inline_script}}} is called on {{{jquery}}} then it gets ignored, and requires to use {{{jquery-core}}}
The same may apply to styles but not tested. Inline scripts should work on both the main script and the aliases.
",pcfreak30
Unpatched Enhancements,51124,Can we get an additional parameter in wp_add_inline_script to set the script type?,audrasjb*,Script Loader,,normal,normal,Future Release,feature request,accepted,needs-unit-tests,2020-08-24T15:55:12Z,2021-11-08T02:55:50Z,"Hi everyone,
This is probably a feature that not many developers out there will use but I think it would be nice to have.
One of my plugins uses `wp_add_inline_script` to inject an inline script into the page. Said inline script gets assigned `text/javascript` as type automatically and there doesn't seem to be a way to change that (if there is please let me know and I'll gladly close this ticket.)
My plugin needs said inline script to contain a JSON string and so it currently hooks into `script_loader_tag` to change its type to `application/json` which feels a bit like a hack. It would be nice if we could set the script type via parameter (eg. `wp_add_inline_script( 'some-handle', '...', 'before', 'application/json' );`) (or maybe via filter hook before `script_loader_tag` happens?)
Thoughts?",hcabrera
Unpatched Bugs,53741,wp-admin/css/common.min.css is loading on the front-end,,Script Loader,5.8,normal,normal,Future Release,defect (bug),new,needs-docs,2021-07-22T14:35:24Z,2021-11-02T15:35:47Z,"The stylesheet `wp-admin/css/common.min.css` is loading on the front-end. This is overriding styles on the front-end of the site with admin styling.
",mdahlke
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,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.
{{{
}}}
This catches some interesting edge behavior in the browser. Notice the code comment is not actually closed correctly because it has {{{--!>}}} instead of {{{-->}}}. When testing that in html, I noticed that browsers seem to treat it as closing the comment and it doesn't break the page. It must be a common enough mistake.
If the field value is changed it have the proper {{{-->}}}, there are no issues. It also requires the {{{`
",kanlukasz
Tickets with Patches,13078,Make wp_register_style and wp_enqueue_style consistent,,Script Loader,3.0,normal,normal,,defect (bug),new,has-patch,2010-04-22T01:08:39Z,2019-06-04T21:05:46Z,"When fixing #13056, I noticed that wp_register_style and wp_enqueue_style had a few odd differences.
1. Enqueue truncates the $handle variable after the first '?' while register (and all other wp_style functions) accept any string.
2. Register set the default for $media to 'all', while enqueue set it to false. (fixed in the #13056 patch).
Moreover, since the two functions are practically the same, I've grouped them together in a private _wp_register_style function with an additional $enqueue boolean. Both enqueue and register call _wp_register_style.
I've omitted the truncate behavior mentioned above. If there's any reason for it in one, and not the other, or in both, feel free to correct me.
We could also just remove the truncate behavior from enqueue. It's a minor patch, and comes down to coding style.",koopersmith
Tickets with Patches,39991,jQuery UI Datepicker Localization Error with PHP date 'S',,Script Loader,4.6,normal,normal,Future Release,defect (bug),new,has-patch,2017-02-28T20:03:37Z,2018-10-25T18:10:04Z,"When localising the datepicker, the UK default WordPress date format is not converted correctly to jQuery UI's format.
The default PHP format for the UK is `jS F Y`
The script-loader.php function `wp_localize_jquery_ui_datepicker()` converts this to `dS MM YY`, however the `S` is invalid and an ordinal suffix cannot be created with the datepicker.
There is no easy solution to add in the ordinal suffix, but a better solution than printing the stray `S` is to strip this out by modifying the `str_replace()` function call to do so.
{{{
// Convert the PHP date format into jQuery UI's format.
$datepicker_date_format = str_replace(
array(
'd', 'j', 'l', 'z', // Day.
'F', 'M', 'n', 'm', // Month.
'Y', 'y', // Year.
'S' // Invalid
),
array(
'dd', 'd', 'DD', 'o',
'MM', 'M', 'm', 'mm',
'yy', 'y',
''
),
get_option( 'date_format' )
);
}}}
",devonto
Tickets with Patches,22249,Add ability to set or remove attributes on enqueued scripts and styles.,,Script Loader,,normal,normal,Future Release,enhancement,assigned,has-patch,2012-10-21T23:29:13Z,2022-06-02T10:08:08Z,"I think it should be easier to customize the loading of scripts and styles (easier to customize the markup generated by the script/style system). Proposed solutions:
'''Solution 1:''' Allow `wp_enqueue_script`, `wp_enqueue_style`, `wp_register_script`, `wp_register_style` to accept an array of attributes as the `$src` parameter. For example:
{{{
wp_enqueue_script( 'my-plugin', array(
'src' => 'http://example.com/js/app.js'
'defer' => ''
'data-my-plugin' => 'custom data attr value'
), array('jquery'), null, true );
}}}
'''Solution 2:''' Add a filter before the markup is generated that allows devs to filter the attributes while they are in array format. For example:
{{{
add_filter('script_loader_attrs', function ($attrs, $handle) {
unset ( $attrs['type'] );
'my-plugin' === $handle and $attrs['data-my-plugin'] = 'plugin data';
$attrs['src'] = remove_query_arg( $attrs['src'] );
return $attrs;
}, 12, 2);
}}}
In class.wp-scripts.php it might look something like:
{{{
$attrs = (array) apply_filters('script_loader_attrs', $attrs, $handle);
}}}
and/or:
{{{
$attrs = (array) apply_filters(""{$handle}_script_loader_attrs"", $attrs );
}}}
----
I imagine that solution '''2''' would be easier to implement than '''1''', and '''2''' allows for themes/plugins to modify scripts/styles w/o re-registering resources.
The key feature of both solutions is the ability to modify the attrs while in array format. There are other ways that one could achieve the same results, but the array is '''by far the cleanest'''. Dirty alternatives include:
* Use `preg_replace()` on the markup after it is generated (see #22245)
* Use output buffers and PHP's DOMElement interface
* Filter away the ""print_scripts_array"" and regenerate the markupmanually.)",ryanve
Tickets with Patches,52465,Allow a relation type in resource hints to be used multiple times,,Script Loader,,normal,normal,Future Release,enhancement,new,has-patch,2021-02-07T17:37:27Z,2021-11-10T01:58:25Z,"`wp_resource_hints` function restricts to one time the usage of a relation type for a resource hint.
This can be a problem for `preconnect` which can be used with and without `crossorigin` attribute at the same time for performance reason.
As an example, a CDN should have two preconnect like this:
{{{
}}}
Please check this post as reference:
[https://crenshaw.dev/preconnect-resource-hint-crossorigin-attribute/#:~:text=Summary,be%20downloaded%20from%20that%20origin.&text=If%20CORS%20won't%20be,two%20resource%20hints%20are%20necessary]
I attached a patch which will allow to use multiple times a resource with different configurations. This patch also avoid a resource to be printed multiple times if all attrs are the same.
e.g:
{{{#!php
'//mycdn.test/',
],
[
'href' => '//mycdn.test/',
'crossorigin' => 'use-credentials',
],
[
'href' => '//mycdn.test/',
],
[
'href' => '//mycdn.test/',
'crossorigin' => 'anonymous',
],
];
foreach ( $domains as $domain ) {
if ( 'preconnect' === $relation_type ) {
$hints[] = $domain;
}
}
return $hints;
}
add_filter( 'wp_resource_hints', 'preconnect_mycdn', 10, 2 );
}}}
will print:
{{{
}}}
",GeekPress
Tickets with Patches,58302,Deprecate and disable the unused compression_test() and wp_ajax_wp_compression_test(),,Script Loader,,normal,normal,Future Release,enhancement,new,has-patch,2023-05-12T18:47:43Z,2024-01-29T20:28:09Z,"The functionality to test whether the web server compresses output was added 14 years ago (WP 2.8). At the time it wasn't a very common practice to compress web pages and assets on the server level, and compressing scripts and stylesheets in PHP was considered a good page load speed increase.
Over the years this has changed. Now most (nearly all?) servers compress output, and compressing from PHP is considered ""bad practice"" as it is slower and consumes more resources. For that reason the compression of the (concatenated) scripts and stylesheets was removed from `load-scripts.php` and `load-styles.php` in [43580] about 4 years ago. Since then the above functionality has been unused.",azaozz
Tickets with Patches,31281,Register JavaScript/Underscore templates using the WP Dependency API,,Script Loader,,normal,normal,,enhancement,new,has-patch,2015-02-10T11:14:43Z,2019-06-04T21:13:58Z,"It would be much easier to handle JavaScript templates when they could get registered using `wp_register/enqueue_script()`. This would allow tight binding between (Backbone) scripts and their respective templates. It would also allow to easily switch out single (core or plugin) templates to extend the UI with custom extensions in plugins. Further more it would have the benefit of more fine grained control of what template to load where and therefore a lower memory footprint.
For a brief look at the overall concept I'm proposing, please [https://gist.github.com/franz-josef-kaiser/6f5448d83558427c5e7d visit this Gist]. This is pretty much what I'm currently using.
So instead of stuffing all templates as endless `
}}}
(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,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,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 `