Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Eliminate manual construction of script tags #58

Conversation

westonruter
Copy link
Collaborator

@westonruter westonruter commented Apr 27, 2023

Amends #54 WordPress#4391

This eliminates manual construction of script tags from WP_Scripts methods. It replaces manual construction with wp_print_inline_script_tag(), wp_get_inline_script_tag(), and wp_get_script_tag() (which were added in WP 5.7). Doing so makes the code much more readable as well as more robust by automatically escaping attribute values and allowing the wp_script_attributes and wp_inline_script_attributes filters to apply to the attributes being printed. It also ensures the non-HTML5 CDATA wrapper comments are added consistently. This would seem to be a logical follow-up to Core-39941 which introduced these functions but didn't make use of them in WP_Scripts. This will facilitate adding CSP attributes to scripts that core prints. (I'm not sure why this wasn't done as part of the aforementioned Trac ticket.)

  • Update tests to account for changes in output (where double quotes are used instead of single, attribute order is changed, and CDATA wrappers are added when not in HTML5)

@joemcgill
Copy link
Collaborator

Thanks @westonruter, I'm a big fan of this idea but think it would be good to have time for discussion and feedback before deciding to make this change. Our plan is to wrap up the open feedback on #54 and then open a PR against the WordPress repo. Once we do, would you be willing to post a new comment on that PR with this suggestion (your PR to our fork/branch should still remain the same).

@westonruter
Copy link
Collaborator Author

@joemcgill You got it!

… of https://github.com/10up/wordpress-develop into update/print-script-tags

* 'feature/enhance-wp-scripts-api-with-a-loading-strategy' of https://github.com/10up/wordpress-develop:
  Updated formatting of wpLoadAfterScripts js function to satisfy WP coding standards
  Update js formatting within wpLoadAfterScripts function used in test cases
  Update js formatting within wpLoadAfterScripts function
  Updated function body for wpLoadAfterScripts to reflect updated function body in script-loader.php
  Rewrite function body for wpLoadAfterScripts to be ES5 and not require the use of eval()
@joemcgill
Copy link
Collaborator

Thanks @westonruter. A new PR is now available for continued feedback/discussion here WordPress#4391

@swissspidy
Copy link
Collaborator

I'm not sure why this wasn't done as part of the aforementioned Trac ticket

That was a separate PR but also a massive undertaking. See WordPress#498

@westonruter
Copy link
Collaborator Author

@swissspidy Thanks for that. I think that PR perhaps went too far by also attempting to become fully compliant with CSP Strict. If the scope is reduced to just utilize the helper functions for script construction, then a subsequent PR could then add the scope of eliminating inline event handlers. (Nevertheless, WordPress#4391 currently relies on onload event handler attributes for detecting when async/defer scripts have loaded to evaluate after scripts, which would also violate Strict CSP unless unsafe-hashes were added.)

if ( 'after-non-standalone' === $position ) {
$script_output = "<script%1\$s id='%2\$s-js-after' data-wp-executes-after='%2\$s'>\n%4\$s\n</script>\n";
$attributes['id'] = "{$handle}-js-after";
$attributes['data-wp-executes-after'] = $handle;
Copy link
Collaborator Author

@westonruter westonruter May 4, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(Yanked)

Copy link
Collaborator Author

@westonruter westonruter May 4, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I mean:

Suggested change
$attributes['data-wp-executes-after'] = $handle;
$attributes['data-wp-executes-after'] = $handle;
$attributes['type'] = 'text/template';

WordPress#4391 (comment)

Copy link

@10upsimon 10upsimon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@westonruter (cc @joemcgill ) this looks solid to me, thank you. Approving, although it's in draft form I assume you're good to release it into non draft @westonruter ?

I was also wondering of this has implications for any tests we've written. It might as we'll be outputting loading strategy attributes as async="true" and defer="true" as opposed to just async or defer from what I can see, so as a spin off I'll probably need to update the tests where script tags are manually constructed to reference the script functions used herein.

If you feel like we should do this as part of this branch, I can pick that up herein.

@westonruter westonruter marked this pull request as ready for review May 17, 2023 16:41
@westonruter
Copy link
Collaborator Author

westonruter commented May 17, 2023

@10upsimon yes, I mainly left it as a draft because the tests haven't been updated yet. Also, there is that suggestion corresponding with a suggestion in the main PR that hasn't been applied yet.

So yeah, tests will need to be updated. Implications of this are:

  1. If html5 support is not present, then the attributes will be rendered XHTML-compatible as async="async" and defer="defer".
  2. Double-quoted attributes will be used instead of single-quoted ones.
  3. The attribute order won't necessarily be the same as before.

These may complicate themes & plugins that are filtering script_loader_tag to mutate the HTML if using naive pattern matching. But they really should be updated to use WP_HTML_Tag_Processor now regardless. And with the introduction of the script loading strategies, they could eliminate use of the filter altogether. This will be important to include in the Dev Note.

Update: See #55 (comment) which further addresses the back-compat issues related to the clean_url filter.

@westonruter
Copy link
Collaborator Author

Aside: It's too bad that the GHA workflows aren't running on these intra-PR branches:

pull_request:
branches:
- trunk
- '3.[7-9]'
- '[4-9].[0-9]'

@joemcgill
Copy link
Collaborator

Aside: It's too bad that the GHA workflows aren't running on these intra-PR branches

There is an open Trac ticket for this, because coming up with an official way for PRs into feature branches to be checked would be nice to have.

@joemcgill
Copy link
Collaborator

@westonruter is this something that you still intend on picking up, or did you determine that it was not feasible without backward compatibility breakage?

@westonruter
Copy link
Collaborator Author

westonruter commented Jun 12, 2023

@joemcgill The main hangup was updating all the tests, which now actually would be greatly simplified by assertEqualMarkup in our main PR (see #73). But I recall we decided to postpone this to 6.4 to avoid potential back-compat issues with this change being conflated with the introduction of script loading strategies.

@spacedmonkey
Copy link

@westonruter I think this change is a good, I think for the sake of testing, commit size and revertablity, lets do this in another ticket / commit.

@westonruter
Copy link
Collaborator Author

I've created a core ticket to move this forward in 6.4: https://core.trac.wordpress.org/ticket/58664

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants