-
Notifications
You must be signed in to change notification settings - Fork 0
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
Eliminate manual construction of script
tags
#58
Conversation
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). |
@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()
Thanks @westonruter. A new PR is now available for continued feedback/discussion here WordPress#4391 |
That was a separate PR but also a massive undertaking. See WordPress#498 |
@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 |
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; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(Yanked)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I mean:
$attributes['data-wp-executes-after'] = $handle; | |
$attributes['data-wp-executes-after'] = $handle; | |
$attributes['type'] = 'text/template'; |
There was a problem hiding this 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.
@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:
These may complicate themes & plugins that are filtering Update: See #55 (comment) which further addresses the back-compat issues related to the |
Aside: It's too bad that the GHA workflows aren't running on these intra-PR branches: wordpress-develop/.github/workflows/phpunit-tests.yml Lines 12 to 16 in 860d506
|
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. |
@westonruter is this something that you still intend on picking up, or did you determine that it was not feasible without backward compatibility breakage? |
@joemcgill The main hangup was updating all the tests, which now actually would be greatly simplified by |
@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. |
I've created a core ticket to move this forward in 6.4: https://core.trac.wordpress.org/ticket/58664 |
Amends
#54WordPress#4391This eliminates manual construction of
script
tags fromWP_Scripts
methods. It replaces manual construction withwp_print_inline_script_tag()
,wp_get_inline_script_tag()
, andwp_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 thewp_script_attributes
andwp_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 inWP_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.)