enhancement: add a $type parameter to wp_add_inline_script()

[paulschreiber]

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]

I originally wrote this up because of MathJax, which wants a block like this:

<script type='text/x-mathjax-config'>

An even more widespread example is the ld+json structured data Google uses everywhere:

<script type='application/ld+json'>

[ronalfy]

+1 for this. I currently need to inline some JSON (application/ld+json) and the type parameter must be set.

[galbaras]

Related to https://core.trac.wordpress.org/ticket/51124

[jonsurrell]

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

I see the workaround used ​was to filter with ​script_loader_tag. ​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. ​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.

​add_inline_script documentation can be found here. Its signature is:

<?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 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 ​wp_print_script_tag() or ​wp_get_script_tag() directly. These accept attributes and are more suitable for arbitrary script tags that may not be JavaScript.