Make WordPress Core

Opened 12 years ago

Last modified 2 years ago

#22249 assigned enhancement

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

Reported by: ryanve's profile ryanve Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version:
Component: Script Loader Keywords: has-patch needs-testing
Focuses: Cc:

Description

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

Attachments (12)

22249.diff (4.1 KB) - added by jtsternberg 10 years ago.
New method, get_script_attributes, to concatenate an array of script attributes passed through a filter.
22249-2.diff (9.4 KB) - added by jtsternberg 10 years ago.
Modifications based on feedback from boonebgorges and jeremyfelt
22249-3.diff (21.2 KB) - added by camdensegal 10 years ago.
Added enqueue/register styles attribute argument.
22249-4.diff (21.2 KB) - added by alex-ye 10 years ago.
22249.2.diff (6.8 KB) - added by ericlewis 9 years ago.
22249.3.diff (10.7 KB) - added by ericlewis 9 years ago.
22249.4.diff (13.6 KB) - added by ericlewis 9 years ago.
22249.5.diff (13.7 KB) - added by ericlewis 9 years ago.
22249.6.diff (16.3 KB) - added by ericlewis 8 years ago.
esc-attr-name.diff (1.1 KB) - added by joe_bopper 8 years ago.
22249.7.diff (16.3 KB) - added by joe_bopper 8 years ago.
22249.8.diff (31.1 KB) - added by mihai2u 7 years ago.

Download all attachments as: .zip

Change History (75)

#1 @alex-ye
12 years ago

  • Cc nashwan.doaqan@… added

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

#2 @jtsternberg
12 years ago

  • Cc justin@… added

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>

#3 @bpetty
12 years ago

Related: #19742

#4 @ryanve
12 years ago

#23236 would make this easier.

#5 @raphaelvalerio
12 years ago

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.

#6 @raphaelvalerio
12 years ago

  • Cc raphaelvalerio added

#7 @Volker_E.
12 years ago

  • Cc Volker_E. added

#8 @lkraav
11 years ago

  • Cc leho@… added

#9 @nacin
11 years ago

  • Component changed from General to Script Loader

#10 in reply to: ↑ description @jphase
10 years ago

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
10 years ago

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

#11 @jtsternberg
10 years ago

  • Keywords has-patch reporter-feedback 2nd-opinion needs-testing added

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

#12 @danielbachhuber
10 years ago

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

#13 follow-ups: @boonebgorges
10 years ago

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?

#14 in reply to: ↑ 13 @jeremyfelt
10 years ago

  • Milestone changed from Awaiting Review to Future Release

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
10 years ago

Modifications based on feedback from boonebgorges and jeremyfelt

#15 in reply to: ↑ 13 @jtsternberg
10 years ago

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

Last edited 10 years ago by jtsternberg (previous) (diff)

@camdensegal
10 years ago

Added enqueue/register styles attribute argument.

#16 @camdensegal
10 years ago

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
10 years ago

#17 @alex-ye
10 years ago

An update for @camdensegal patch..

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

Still needs testing...

Last edited 10 years ago by alex-ye (previous) (diff)

#18 @Viper007Bond
10 years ago

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

This ticket was mentioned in Slack in #core by boone. View the logs.


9 years ago

#20 follow-up: @bhubbard
9 years ago

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">
Last edited 9 years ago by bhubbard (previous) (diff)

#21 @boonebgorges
9 years ago

  • Keywords needs-docs needs-unit-tests added; dev-feedback reporter-feedback 2nd-opinion needs-testing removed

Yeah, let's move forward on this.

Responding to alexye's most recent patch:

@ericlewis
9 years ago

#22 @ericlewis
9 years ago

  • Keywords needs-docs removed
  • Milestone changed from Future Release to 4.5

attachment:2249.2.diff

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'
  )
) );
Last edited 9 years ago by ericlewis (previous) (diff)

This ticket was mentioned in Slack in #core by chriscct7. View the logs.


9 years ago

#24 @chriscct7
9 years ago

  • Owner set to chriscct7
  • Status changed from new to assigned

I'll try getting some unit tests done for this

This ticket was mentioned in Slack in #core by eric. View the logs.


9 years ago

@ericlewis
9 years ago

#26 @ericlewis
9 years ago

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?

#27 follow-up: @boonebgorges
9 years ago

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
9 years ago

#28 in reply to: ↑ 27 @ericlewis
9 years ago

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.

#29 follow-up: @westonruter
9 years ago

@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
9 years ago

#30 in reply to: ↑ 29 @ericlewis
9 years ago

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

#31 @ocean90
9 years ago

#24954 was marked as a duplicate.

#32 @ocean90
9 years ago

  • Keywords needs-refresh added

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

#33 @ericlewis
9 years ago

  • Owner chriscct7 deleted

This ticket was mentioned in Slack in #core by jorbin. View the logs.


9 years ago

#35 @jorbin
9 years ago

  • Milestone changed from 4.5 to Future Release

#36 @ericlewis
9 years ago

  • Keywords early needs-patch added; has-patch needs-unit-tests removed

@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
8 years ago

#37 @ericlewis
8 years ago

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.

This ticket was mentioned in Slack in #core by boone. View the logs.


8 years ago

#39 @ocean90
8 years ago

  • Type changed from feature request to enhancement

#40 @ocean90
8 years ago

#38137 was marked as a duplicate.

#41 in reply to: ↑ 20 @zodiac1978
8 years ago

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

#42 @swissspidy
8 years ago

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.

#43 @joe_bopper
8 years ago

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
8 years ago

#44 @joe_bopper
8 years ago

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.

#45 follow-up: @digitalmk
7 years ago

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

#46 in reply to: ↑ 45 @joe_bopper
7 years ago

  • Keywords has-patch needs-testing added; needs-patch removed

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.

#47 @mihai2u
7 years ago

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

#48 @mihai2u
7 years ago

  • Keywords needs-refresh removed

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
7 years ago

#49 @mihai2u
7 years ago

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.

Last edited 7 years ago by mihai2u (previous) (diff)

#50 @joe_bopper
7 years ago

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

#51 @mihai2u
7 years ago

@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?

#52 @mor10
7 years ago

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.

#53 follow-up: @mor10
7 years ago

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.

#54 in reply to: ↑ 53 @GaryJ
7 years ago

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.

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.

#55 @Mte90
5 years ago

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.

#56 @SergeyBiryukov
3 years ago

#54314 was marked as a duplicate.

This ticket was mentioned in PR #1775 on WordPress/wordpress-develop by emrancu.


3 years ago
#57

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

#58 @emrancu
3 years ago

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.

#59 @adamsilverstein
3 years ago

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

#60 @emrancu
3 years ago

@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

Last edited 3 years ago by emrancu (previous) (diff)

emrancu commented on PR #1775:


3 years ago
#61

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

#62 @johnbillion
3 years ago

  • Keywords early removed

This ticket was mentioned in Slack in #core-js by adamsilverstein. View the logs.


2 years ago

Note: See TracTickets for help on using tickets.