Add ability to set or remove attributes on enqueued scripts and styles.

[ryanve]

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.)

[alex-ye]

Yes It might be a good idea , I was needing something like this when I was using LessCSS sometimes you need to change "rel" value to "stylesheet/less" .

[jtsternberg]

This is also needed for some 3rd party scripts. Outbrain looks like:

<script type="text/javascript" async="async" src="http://widgets.outbrain.com/outbrain.js"></script>

[bpetty]

Related: #19742

[ryanve]

#23236 would make this easier.

[raphaelvalerio]

This feature would also be useful for removing type='text/javascript', since it's redundant in HTML5. As far as I know, currently the only way of using a <script> element without the type attribute is to hardcode it into your theme.

Styles do have a filter hook you can use to alter the markup:

add_filters( 'style_loader_tag' )

(see wp-includes/class.wp-styles.php, line 83)

I haven't tried hooking into this filter, but I think the whole <link> element is a string, not an array, which could be improved upon. But at least it's hookable.

Scripts, on the other hand, have no filter to hook. Not only that, but the <script> element is printed to the site with a simple echo statement right in the function, so there's no variable to modify.

This happens in wp-includes/class.wp-scripts.php, in the do_item() function on line 125. I toyed around with adding in a filter. Although this doesn't correspond exactly to what you're asking, here's one solution for the script tag side of things:

Replace lines 122-125 of wp-includes/class.wp-scripts.php with:

$attrs = array( 'type' => 'text/javascript' );

$attrs = apply_filters( 'script_loader_attrs', $attrs );

$attrs_string = '';

if(!empty( $attrs ) ) {
	foreach ( $attrs as $key => $value ) {
		$attrs_string .= "$key='" . esc_attr( $value ) . "' ";
	}
	$attrs = ltrim( $attrs_string );
}

if ( $this->do_concat )
	$this->print_html .= "<script " . $attrs . " src='$src'></script>\n";
else
	echo "<script " . $attrs . "src='$src'></script>\n";

You can then use add_filter in your themes/plugins like so:

add_filter( 'script_loader_attrs', 'my_function' );

function my_function( $attrs ) {
   $attrs = array('async' => 'async', 'charset' => 'utf8') // whatever attributes you want

   // alternatively, eliminate type='text/javascript' by emptying $attrs:
   // $attrs = '';

   return $attrs;
}

The code above will always produce XHTML type attributes, e.g. async='async'. I'd need to add in a little code in the loop if the author wanted the more succinct async HTML5 version of the boolean.

For backward compatibility, the code will default back to including type='text/javascript' if no filter hooks in.

If people are interested in trying this solution, I could upload a diff file.

[jphase]

Replying to ryanve:

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 );

I think Solution 1 makes complete sense from a developer's standpoint. This solution could keep any previous filters intact and provide a simple type check on the second param to change the way this is rendered. I'd be happy to help submit a diff for this or #23236 if any help is needed.

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.)

[jtsternberg]

New method, get_script_attributes, to concatenate an array of script attributes passed through a filter.

[jtsternberg]

With 22249.diff, you would be able to modify/remove the default type="text/javascript" as well as add your own attributes (like async="async").

[danielbachhuber]

I like the first option, although we could just as easily do both. The use case is something I run into regularly.

[boonebgorges]

22249.diff​ is a pretty cool idea. A couple thoughts I had while looking the patch over:

• There was a suggestion earlier about making wp_register_script() accept an array for $src. 22249.diff doesn't include this, but hides everything in a filter. By not making this accessible as a function argument, it buries the functionality a bit. It also suggests that changes to these attributes are generally something you'd want to do on a specific site or with a specific theme - acting on *someone else's* scripts - rather than in a plugin that registers its own scripts. I can imagine situations where the plugin/theme registering the script would want to pass some custom attributes, and it seems pretty hackish to require them to add a filter for that purpose. So I'd suggest adding array support. (I'm not 100% sure that it makes sense to do this by allowing $src to be an array - in which case the variable name and docs would certainly have to be changed - or if another param should be added to the function for the attributes.)
• Related: 'src' is not being passed to the new filter, but is hardcoded into the <script> tag. I can imagine some benefits of putting 'src' into the $default_attributes array and allowing it to be filtered as well. You'd probably need some sanity checks after the filter to make sure that 'src' hasn't been removed from the array.
• Could stylesheets use the same treatment?

[jeremyfelt]

Big +1. All major browsers now support async, which would be very helpful. defer is likely less important because of in_footer, though still helpful. I'm sure there are other attributes I'm not aware of that could be included and result in more plugins using wp_enqueue_scripts() rather than something else.

I like the idea of $src being an array. It could also make sense to turn the $in_footer parameter into an array - maybe array( 'in_footer' => false, 'attributes' => array( 'type' => 'text/javascript' ) ). This may better imply the order of output. Including text/javascript as default may also be overkill - not sure.

Related #12009

[jtsternberg]

Modifications based on feedback from boonebgorges and jeremyfelt

[jtsternberg]

[22249-2.diff](https://core.trac.wordpress.org/attachment/ticket/22249/22249-2.diff) Contains updates to:

• Change $in_footer param for wp_register_script and wp_enqueue_script to an $args array where 'attributes' could be passed with an array of attribute key/value pairs. Also accepts 'in_footer' as a parameter and has a back-compat check for a passed non-array value.
• Includes the src attribute/value, the type attribute/value, and any attributes passed in via the new $args param on wp_register_script and wp_enqueue_script in the array of attributes passed to the new script_loader_attributes filter.

If this passes muster, and all agree, I can apply the same treatment to the css side of things.

[camdensegal]

Added enqueue/register styles attribute argument.

[camdensegal]

I've added the same functionality for wp_enqueue_style and wp_register_style. Though instead of having the attributes in a sub-array I have it as the main array because the argument being replaced ($media) is also an attribute.

[alex-ye]

An update for @camdensegal patch..

• Style media attribute is always a string.
• Use the double-quotation strings only when necessary.

Still needs testing...

[Viper007Bond]

[30403] allows you to do this but it'd still be nice to be able to control this more easily than via a filter.

[bhubbard]

Any update on this, I would really like to use this filter for Cloudflare:
​https://support.cloudflare.com/hc/en-us/articles/200169436-How-can-I-have-Rocket-Loader-ignore-my-script-s-in-Automatic-Mode-

I also want to use it to add the integrity and crossorigin when I register Bootstrap scripts from BootstrapCDN:

<link href="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.5/css/bootstrap.min.css" rel="stylesheet" integrity="sha256-MfvZlkHCEqatNoGiOXveE8FIwMzZg4W85qfrfIFBfYc= sha512-dTfge/zgoMYpP7QbHy4gWMEGsbsdZeCXz7irItjcC3sPUFtf0kuFbDz/ixG7ArTxmDjLXDmezHubeNikyKGVyQ==" crossorigin="anonymous">

[boonebgorges]

Yeah, let's move forward on this.

Responding to alexye's most recent patch:

• The back compat trick for the $in_footer argument seems fine to me, though we need better docs for it. Here's the format for associative array param documentation: ​https://make.wordpress.org/core/handbook/best-practices/inline-documentation-standards/php/#1-1-parameters-that-are-arrays We also need a @since tag explaining this change.
• It would be nice to see a copy of this that doesn't have unrelated whitespace/codestyling cleanup.
• I'd feel more comfortable about the changes if we had some unit tests, especially surrounding the use of the repurposed $in_footer and $media params.

[ericlewis]

attachment:2249.2.diff

• removes the coding standards fixes, ​please don't include them in the future :)
• Fixes inline docs.

Still need unit tests here if anyone wants to give that a go.

@boonebgorges @jeremyfelt @danielbachhuber if we're going to modify the function signature, can we go all in?

<?php
wp_enqueue_script( array( 
  'handle' => 'd3',
  'src' => 'https://cdnjs.cloudflare.com/ajax/libs/d3/3.5.12/d3.js',
  'attributes' => array( 
    'async' => 'async'
  )
) );

[chriscct7]

I'll try getting some unit tests done for this

[ericlewis]

Had a ​good chat with @boonebgorges about the demerits of refactoring our script loader to use an array hash.

In attachment:22249.3.diff​

• Instead of changing $in_footer to an array hash, add a sixth argument for element attributes. Placing a script in the footer seems like a separate responsibility to think about when writing code.
• Create separate methods on WP_Scripts for get_script_attributes() and get_concatenated_script_attributes().
• Add tests.

Do we still want to offer a filter for script attributes now that its available on the register/enqueue functions?

[boonebgorges]

Cool, this is shaping up nicely.

The method name get_concatenated_script_attributes() threw me for a loop, because 'concatenated' has a different and more frequently used meaning in the context of scripts/styles. I'd suggest something like get_script_attribute_html().

Did we actively decide not to give the same treatment to wp_enqueue_style()?

Why are we passing around $handle and $src in get_concatenated_script_attributes(), etc, but getting $args and $attributes from object properties?

Can we not do the weird ternary formatting in get_script_attributes()? If it's so confusing, just make it an if/else :)

Do we still want to offer a filter for script attributes now that its available on the register/enqueue functions?

You mean 'script_loader_attributes'? I guess I'd keep it - seems like there might be legit cases where programatically modification is appropriate - but I'd move it to get_script_attributes().

[ericlewis]

Replying to boonebgorges:

The method name get_concatenated_script_attributes() threw me for a loop, because 'concatenated' has a different and more frequently used meaning in the context of scripts/styles. I'd suggest something like get_script_attribute_html().

Totally.

Did we actively decide not to give the same treatment to wp_enqueue_style()?

Let's land on an implementation for scripts first.

Why are we passing around $handle and $src in get_concatenated_script_attributes(), etc, but getting $args and $attributes from object properties?

The script object's property for $src is not an expanded URL (no base URL or version query string). That happens in WP_Scripts->do_item(). I've introduced WP_Scripts->get_script_src() in attachment:22249.4.diff​ which extracts this src expansion logic. Using this in get_script_attributes() removes the need to toss around $src. Also has tests.

Can we not do the weird ternary formatting in get_script_attributes()? If it's so confusing, just make it an if/else :)

100% yes.

Also in attachment:22249.4.diff​, I've renamed the filter for a script's attributes from script_loader_attributes to just script_attributes, and removed the $src parameter. Handle should be useful enough.

[westonruter]

@ericlewis can get_script_src() use esc_url_raw() instead of esc_url() when it returns? It would be more useful to add HTML entities via esc_url() at the point where it gets written into HTML, so the method can be used for other purposes (e.g. listing out scripts enqueued in the response for a given request to render in Selective Refresh partials).

[ericlewis]

Replying to westonruter:

@ericlewis can get_script_src() use esc_url_raw() instead of esc_url() when it returns?

Sounds good. Added in attachment:22249.5.diff​

[ocean90]

#24954 was marked as a duplicate.

[ocean90]

22249.5.diff​:

• Needs a refresh after recent changes
• "The sixth argument was added. " should be "Introduced the $attributes parameter."
• In get_script_src() spaces should be added when using variables as array keys, $this->registered[$handle]; => $this->registered[ $handle ];
• IMO get_script_attributes() shouldn't return the $src value. I'd call it get_(script)_additonal_attributes(). That would solve all the special cases which makes the code a bit too complex right now.
• This shouldn't go in without support for styles. Note that WP_Styles has already _css_href( $src, $ver, $handle ).

[ericlewis]

@ocean90 said

IMO get_script_attributes() shouldn't return the $src value. I'd call it get_(script)_additonal_attributes().

that sounds good to me.

Let's revisit this in 4.6 early.

In the meantime, if anyone would like to write a new patch with @ocean90's considerations in mind, be my guest. Our implementation for scripts has come together, so the next patch can include an implementation for styles.

[ericlewis]

I've refreshed the patch in attachment:22249.6.diff​, comments inline.

@ocean90 said:

IMO get_script_attributes() shouldn't return the $src value. I'd call it get_(script)_additonal_attributes(). That would solve all the special cases which makes the code a bit too complex right now.

This implementation would make preserving the existing attribute order of type and then src cumbersome, so the current implementation seems like an okay amount of complex.

This shouldn't go in without support for styles. Note that WP_Styles has already _css_href( $src, $ver, $handle ).

attachment:22249.6.diff​ has the beginning of an implementation, but it's complicated.

We're planning on adding an $args parameter to wp_register_script(), which holds the extra attributes for the script. wp_enqueue_style() already accepts the $media value which it shoves in to the $args parameter in the underlying WP_Scripts->add() call.

[ocean90]

#38137 was marked as a duplicate.

[zodiac1978]

Replying to bhubbard:

I also want to use it to add the integrity and crossorigin when I register Bootstrap scripts from BootstrapCDN:

<link href="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.5/css/bootstrap.min.css" rel="stylesheet" integrity="sha256-MfvZlkHCEqatNoGiOXveE8FIwMzZg4W85qfrfIFBfYc= sha512-dTfge/zgoMYpP7QbHy4gWMEGsbsdZeCXz7irItjcC3sPUFtf0kuFbDz/ixG7ArTxmDjLXDmezHubeNikyKGVyQ==" crossorigin="anonymous">

This is a interesting idea, but not well supported enough, I think.

See:
​https://wiki.mozilla.org/Security/Guidelines/Web_Security#Subresource_Integrity
​https://w3c.github.io/webappsec-subresource-integrity/
​http://caniuse.com/#search=integrity

[swissspidy]

Subresource integrity is an official W3C recommendation and as such more browsers will add support for it. +1 for supporting it in WordPress.

See also #33948.

[joe_bopper]

Hi,

Notably, this patch uses esc_attr on line 501 to escape the attribute names. This isn't correct as it only clears out invalid utf8 characters and quotes, whereas valid attribute names need to be cleared of all the following characters [\t\n\f \/>"\'=]+.

Cheers.

[joe_bopper]

It was also on line 285 of class.wp-styles.php. W3C reference for what can't be used in an attribute name is here: ​https://html.spec.whatwg.org/multipage/syntax.html#attributes-2.

[digitalmk]

Has there been any traction with this? Or with #33948? Been seeing this use case quite often, recently.

[joe_bopper]

Replying to digitalmk:

Has there been any traction with this? Or with #33948? Been seeing this use case quite often, recently.

Not to my knowledge and notably people will still be using esc_attr instead of esc_attr_name.

[mihai2u]

@joe_bopper
I attempted to apply the patch, but it got 3 rejects:

? Please select a patch to apply 22249.7.diff​ (16.3 KB) - added by joe_bopper 15 months ago.
patching file src/wp-includes/class.wp-scripts.php
Hunk # 2 FAILED at 347.
patching file src/wp-includes/class.wp-styles.php
Hunk # 2 FAILED at 217.
patching file src/wp-includes/functions.wp-scripts.php
Hunk # 4 FAILED at 291.

I'm interested in helping out with the testing this, as it's a useful feature which can help a lot with the websites perceived performance in hands of capable developers.

[mihai2u]

I was able to apply the patch correctly on WordPress 4.7-alpha and got both esc-attr-name​.diff and 22249.7.diff patches to it to allow for easier development / testing.

I encountered some conflicts when refreshing to the latest Wordpress version, but they were fairly easy to solve
​https://github.com/xwp/wordpress-develop/pull/304

[mihai2u]

I've tested the script's ability to add async and defer:

<?php
wp_enqueue_script( 'twentyseventeen-skip-link-focus-fix', get_theme_file_uri( '/assets/js/skip-link-focus-fix.js' ), array(), '1.0', true, array( 'async' => 'async', 'defer' => 'defer' ) );

The generated script tag included the necessary attributes:

<script type='text/javascript' src='http://wordpress-develop.local/wp-content/themes/twentyseventeen/assets/js/skip-link-focus-fix.js?ver=1.0' async='async' defer='defer'></script>

The update to an array attribute inside wp_register_style and wp_enqueue_style I've seen in 22249-3.diff was not present anymore in the 22249.7.diff, hence I didn't find a way to test adding / overriding the stylesheet tag attributes.

I think this should move forward as it's a much welcomed addition to avoid having to manipulate the strings using the script_loader_tag filter whenever an async or defer attribute is needed.

[joe_bopper]

Cheers for the refresh mihai2u. I've tested your patch and it works for me.

[mihai2u]

@ocean90 can I further support to move this ticket forward?
Would this stand a chance to be put on the radar for a potential 4.9.2 inclusion?

[mor10]

There is significant overlap between this ticket and #12009.

In my view, async / defer is a separate conversation from general script attributes as these specific attributes are booleans and play unique roles in how the browser renders scripts. Separating the two conversations will allow us to move forward on solutions for each of them in a more meaningful way. Right now there is a lot of crosstalk between the tickets and the two different issues are discussed as if they are one and the same, which in my opinion they are not.

[mor10]

async and defer have unique roles in the context of the script tag and should be handled separately from other attributes. ​More details. As mentioned in 12009, there are three possible script loading conditions: nothing (default), async, and defer. If async or defer are used, they are added to the script tag as booleans without values:

<script async src="javascript.js"></script>

IMO these script loading attributes are significant enough to warrant their own parameter in the affected functions. Something like this:

<?php
wp_enqueue_script( 'label', 
                   get_theme_file_uri( 'script.js' ), 
                   array(), 
                   '1.0', 
                   false, 
                   defer, 
                   array( 'data-attribute' => 'value' ) 
);

which would output the following code in <head>:

<script type='text/javascript' src='[...]/script.js?ver=1.0' defer data-attribute='value'></script>

The new property could either be blank (not filled in) or contain the word async or the word defer. Alternatively it could be captured using some sort of attribute/value pair like script-loading="async" or similar. The main point is separation of concerns: async / defer are kept as stand-alone parameters and outputs in the overall function.

[GaryJ]

Replying to mor10:

If async or defer are used, they are added to the script tag as booleans without values:

A reminder that even the W3 Recommendation for HTML 5.2, includes coverage of XHTML syntax (XML-serialized HTML), which, among other things required by XML proper, disallows boolean attributes.

• ​https://www.w3.org/TR/html52/introduction.html#html-vs-xhtml

There may well be other issues that stop WP from being delivered as application/xhtml+xml, but let's not introduce new code that moves core output further away from polyglot markup.

[Mte90]

Just a ping to know the status of this ticket and a suggestion.
Working with different web services often happen that to script doesn't want only defer/async but also an id or custom data-* attributes.
Right now I am doing with wp_print_scripts with an echo to avoid any issues but is not very wordpress friendly.

[SergeyBiryukov]

#54314 was marked as a duplicate.

There is not option for setting script attributes ( like 'async', 'crossorigin', 'defer', 'integrity', 'nonce', 'referrerpolicy', 'type' ).
I have added support to add custom attribute/s to script tag with the wp_enqueue_script method.

Trac ticket: https://core.trac.wordpress.org/ticket/22249

[emrancu]

Hi There,
We need to add custom attribute specially type="module" for Modern JavaScript. Specially when we work with React JS, Vue JS, Vite Build Tool then we must need type="module" in script.

But There is no direct option for setting custom attribute to script tag.

I have completed the task in ​https://github.com/WordPress/wordpress-develop/pull/1775 PR.

[adamsilverstein]

@emrancu note that since WP 5.7, you can add attributes to script tags using wp_print_script_tag, ideally we will also add this support directly to wp_enqueue_script.

[emrancu]

@adamsilverstein Thank you so much for your response.

We need to add custom attributes in the admin-end (also front-end).

When do you add this support directly to wp_enqueue_script ? Maximum developers waiting for this feature, are using React, Vue, Vite, and Others JS (Modern JS).

Recently I am developing an open-source plugin development framework (​https://www.wppluginmaster.com), where I need to add this support.

@adamsilverstein, I need to know that any problem with my pull request ? Please tell me, it will help me to better understand. I am new to WordPress and new in contribution.

Thanks
❤️WordPress

WordPress 5.7 has wp_print_script_tag function but it is for front-end only but I need a custom attribute for admin-end.
I will solve the issue on my end with this type of custom function.

Thanks