[wp-trac] [WordPress Trac] #58664: Eliminate manual construction of script tags in WP_Scripts

[WordPress Trac]

#58664: Eliminate manual construction of script tags in WP_Scripts
-------------------------------------------------+-------------------------
 Reporter:  westonruter                          |       Owner:
                                                 |  westonruter
     Type:  defect (bug)                         |      Status:  accepted
 Priority:  normal                               |   Milestone:  6.4
Component:  Script Loader                        |     Version:  6.3
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch has-unit-tests 2nd-        |     Focuses:  javascript
  opinion                                        |
-------------------------------------------------+-------------------------

Comment (by westonruter):

 Replying to [comment:16 azaozz]:
 > Replying to [comment:15 westonruter]:
 > > For a discussion about the use of output buffering to ensure IDE
 intelligence for inline script tags with `wp_print_inline_script_tag()`
 extended to support passing a closure, see
 [https://wordpress.slack.com/archives/C5UNMSU4R/p1693591315595499 thread
 in #core-js]. For example:
 > >
 > > {{{#!php
 > > <?php
 > > wp_print_inline_script_tag(
 > >     static function () {
 > >             ?>
 > >             <script>
 > >                     var foo = 'bar';
 > >                     /* JS code goes here */
 > >             </script>
 > >             <?php
 > >     }
 > > );
 > > }}}
 >
 > Using a lambda function there looks a bit like a "weird hack" :)

 It does look weird. But the benefit is cross-IDE syntax highlighting and
 intelligence.

 > Seems `wp_print_inline_script_tag()` is not particularly suitable for
 this kind of usage. Wouldn't it be better to try to improve it instead of
 wrapping all "normal" scripts in WP in that PHP code?

 The issue isn't that `wp_print_inline_script_tag()` needs to be improved
 ''per se'', but that there should be a way to construct inline script tags
 using that function while also retaining IDE features. Since inline
 scripts in PHP don't get any linting performed, it's important to get as
 much IDE support as possible to catch bugs.

 > Also I don't think it is a good change for
 `wp_print_inline_script_tag()` to accept a callback as well as a string.
 Seems to just make it all more complex and maybe a bit confusing without
 much benefits. These are all "hard coded" scripts in wp-admin that can
 (and should) be tweaked or updated as needed.

 The benefits are:

 1) Retaining syntax-highlighting and IDE intelligence features.
 2) Constructing the ultimate `script` tag with filters applying on the
 attributes, allowing `nonce` to be added for CSP.

 If the JS isn't passed through `wp_print_inline_script_tag()`, then there
 would have to be an alternative way to obtain the `nonce` attribute for
 CSP. For example there could be `the_script_tag_attributes()`:

 {{{#!php
 <script <?php the_script_tag_attributes(); ?>>
 var foo = 'bar';
 /* JS code goes here */
 </script>
 }}}


 And this `the_script_tag_attributes()` could apply the same
 `wp_inline_script_attributes` filters as `wp_get_inline_script_tag()`
 does. But the problem is that it wouldn't have the `$javascript` argument
 to pass to those filters.

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