FIX #29: Add async
and defer
, async main script
#30
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,39 @@ | ||
<?php | ||
|
||
/* --------------------------------------------------------------------------------------------- | ||
JAVASCRIPT LOADER CLASS | ||
Allow `async` and `defer` while enqueueing JavaScript. Based on a solution in WP Rig. | ||
--------------------------------------------------------------------------------------------- */ | ||
|
||
class TwentyTwenty_Script_Loader { | ||
|
||
/** | ||
* Adds async/defer attributes to enqueued / registered scripts. | ||
* | ||
* If #12009 lands in WordPress, this function can no-op since it would be handled in core. | ||
* | ||
* @link https://core.trac.wordpress.org/ticket/12009 | ||
* | ||
* @param string $tag The script tag. | ||
* @param string $handle The script handle. | ||
* @return string Script HTML string. | ||
*/ | ||
public function filter_script_loader_tag( string $tag, string $handle ) : string { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Type hinting against There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Cc @felixarntz and @westonruter There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I agree, this theme needs to support PHP 5.6 Type hinting will have to wait for the PHP 7.0 bump |
||
foreach ( [ 'async', 'defer' ] as $attr ) { | ||
if ( ! wp_scripts()->get_data( $handle, $attr ) ) { | ||
continue; | ||
} | ||
// Prevent adding attribute when already added in #12009. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Please update the link on a line of its own to point to the actual Trac ticket
|
||
if ( ! preg_match( ":\s$attr(=|>|\s):", $tag ) ) { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Would |
||
$tag = preg_replace( ':(?=></script>):', " $attr", $tag, 1 ); | ||
} | ||
// Only allow async or defer, not both. | ||
break; | ||
} | ||
return $tag; | ||
} | ||
|
||
} | ||
|
||
$loader = new TwentyTwenty_Script_Loader; | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Since this theme is not build using proper OOP principles (encapsulation, polymorphism etc.), I see no reason to put this code in a separate class. There is no dependency injection used anywhere so we can just write procedural code. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Keeping it as a class makes it nicely isolated and easy to remove if/when core finally allows for There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I understand the rationale, but it just mixes class-based with procedural code, which is a bit inconsistent. I'm all for keeping certain functionalities in separate files and including them in the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I am actually of the oppinion that encapsulation, even just for the sake of it, is fine. I do not like including a class file that has side effects though. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I agree with @dingo-d here that, given how the rest the theme is coded, we shouldn't break that paradigm by introducing a class for functionality like this, as that can make the code harded to understand than everything following one approach. I suggest introducing a single function attached to the filter. |
||
add_filter( 'script_loader_tag', [ $loader, 'filter_script_loader_tag' ], 10, 2 ); |
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.
Can we use docblock style comments instead these big huge blocks?
We should use standard PHP practices.
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.
Afaik this format is the expected format for WordPress coding standards. It's the same format used in previous default themes.
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.
See https://developer.wordpress.org/coding-standards/inline-documentation-standards/php/#6-file-headers
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.
Yeah, previous themes had some issues that passed through because TRT wasn't involved 😄We're trying to polish this one out so that we can say: look at 2020 🙂