[wp-trac] [WordPress Trac] #40276: enhancement: add a $type parameter to wp_add_inline_script()

[WordPress Trac]

#40276: enhancement: add a $type parameter to wp_add_inline_script()
---------------------------+------------------------------
 Reporter:  paulschreiber  |       Owner:  (none)
     Type:  enhancement    |      Status:  new
 Priority:  normal         |   Milestone:  Awaiting Review
Component:  Script Loader  |     Version:  4.7.3
 Severity:  normal         |  Resolution:
 Keywords:  2nd-opinion    |     Focuses:
---------------------------+------------------------------
Changes (by jonsurrell):

 * keywords:   => 2nd-opinion


Comment:

 I'll share thoughts and questions to try to understand the needs and
 possible ways forward.


 I see the workaround used [https://plugins.trac.wordpress.org/browser
 /mathjax-latex/trunk/class-mathjax-latex.php?rev=3222403#L237 was to
 filter] with
 [https://developer.wordpress.org/reference/hooks/script_loader_tag/
 script_loader_tag].
 [https://developer.wordpress.org/reference/hooks/wp_script_attributes/
 wp_script_attributes may also be a good filter for this].

 The primary use case for this is when third-party libraries expect a
 specific script tag? Is this a common issue today? A nice alternative is
 to load the third party library and initialize it from within a script
 module with provided data.
 [https://developer.wordpress.org/reference/hooks/script_module_data_module_id/
 There is a related filter for Script Modules]:
 `script_module_data_{$module_id}`. This filter is used for providing
 arbitrary data, although the data is always printed as `<script
 type="application/json">`.

 -----

 If support for this is added, what would that look like.

 [https://developer.wordpress.org/reference/functions/wp_add_inline_script/
 add_inline_script documentation can be found here]. Its signature is:

 {{{#!php
 <?php
 wp_add_inline_script( string $handle, string $data, string $position =
 'after' ): bool {}
 }}}

 That could be adapted somehow to accept more options.

 Things becomes less clear in `WP_Dependencies::add_data`. These inline
 scripts are stored as "extra" data in `before` and `after` keys. If
 additional information is required, it could be stored as more extra data,
 for example in `before-options`. This requires more data to be passed
 through the system.

 The most problematic part of the proposed change seems to me that
 `add_inline_script`
 [https://core.trac.wordpress.org/browser/tags/6.8.2/src/wp-includes/class-
 wp-scripts.php#L474 adds to an array of data]. This means that it should
 be possible to add an arbitrary number of inline scripts. This becomes a
 problem if one inline script expects to be evaluated as JavaScript in a
 script tag, while another has different expectations. In this case they
 can conflict and it's unclear what should be done.

 -----

 **My position is that `wp_add_inline_script` is only suitable for
 JavaScript script tags and modifying the type attribute should not be
 supported.** Other types of script tags would best be printed by using
 [https://developer.wordpress.org/reference/functions/wp_print_script_tag/
 wp_print_script_tag()] or
 [https://developer.wordpress.org/reference/functions/wp_get_script_tag/
 wp_get_script_tag()] directly. These accept attributes and are more
 suitable for arbitrary script tags that may not be JavaScript.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/40276#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform