Simon Dowdles 10:10 am on July 14, 2023
Tags: 6-3 ( 70 ), dev-notes ( 542 ), dev-notes-6.3 ( 17 )

Registering scripts with `async` and `defer` attributes in WordPress 6.3

WordPress 6.3 introduces support for registering scripts with async and defer attributes as part of an enhancementenhancement Enhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature. to coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.’s existing Scripts APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways.. This addresses a long-standing Trac ticket, and adds the ability to define a loading strategy for scripts. Supported strategies are as follows:

Blocking (default, this strategy is not supplied)
Deferred (by supplying a defer loading strategy)
Asynchronous (by supplying an async loading strategy)

This enhancement was originally proposed in December 2022.

Why is this enhancement useful?

Adding defer or async to script tags enables script loading without “blocking” the rest of the page load, resulting in more performant sites via improved Largest Contentful Paint (LCP) performance. This leads to a better user experience. This has been common practice in web engineering for over a decade, yet to date there have been no core methods or a means of achieving this when registering/enqueuing scripts using core WordPress APIs.

Prior to this enhancement, developers have had to resort to less than ideal alternatives such as directly filtering the tags at the point of output (using the script_loader_tag filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output., or worse the clean_url filter), or handling the tagtag A directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.) output directly using wp_print_script_tag and the wp_script_attributes filter. Although fairly common practice (as it was the only means available prior), it is considered “hacky” as it does not take into account the dependency tree, or inline scripts for that matter, which can lead to interoperability issues or bugs with other scripts.

The difference between deferred (via the defer script attribute) and asynchronous (via the async script attribute) scripts is as follows:

Deferred scripts
Scripts marked for deferred execution — via the defer script attribute — are only executed once the DOM tree has fully loaded (but before the DOMContentLoaded and window load events). Deferred scripts are executed in the same order they were printed/added in the DOM, unlike asynchronous scripts.
Asynchronous scripts
Scripts marked for asynchronous execution — via the async script attribute — are executed as soon as they are loaded by the browser. Asynchronous scripts do not have a guaranteed execution order, as script B (although added to the DOM after script A) may execute first given that it may complete loading prior to script A. Such scripts may execute either before the DOM has been fully constructed or after the DOMContentLoaded event.

Summary of the changes

At a high level, the changes can be summarized as follows:

WordPress now adds support for specifying a script loading strategy via the wp_register_script() and wp_enqueue_script() functions.
These functions have new function signatures, with the prior $in_footer boolean parameter being overloaded to accept a new $args array parameter in order to facilitate an easy entry point for specifying a loading strategy for a script, while still retaining full backward compatibility for $in_footer implementations; this retains the means of specifying whether a script should be printed in the footer or not via a key within the new $args parameter. Note that the strategy can also be specified in a backwards-compatible way via wp_script_add_data().

Various additions and enhancements to the WP_Scripts class were made to facilitate the necessary business logic that prepares and outputs a script’s loading strategy.

Example 1: Specifying a loading strategy for a script

A loading strategy may be assigned via the wp_register_script() and wp_enqueue_script() functions by passing a strategy key value pair to the new/overloaded $args parameter.

The following example showcases a new script with handle 'foo' being registered as a deferred script:

wp_register_script( 
	'foo', 
	'/path/to/foo.js', 
	array(), 
	'1.0.0', 
	array(
		'strategy' => 'defer'
	) 
);

This exact same means of specifying a loading strategy may be achieved via the wp_enqueue_script() function.

Example 2: Specifying that a script be printed in the footer via the new API

The next example showcases a second script being specified for footer printing using the new API, while also supplying the async loading strategy at the same time:

wp_register_script( 
	'bar', 
	'/path/to/bar.js', 
	array(), 
	'1.0.0', 
	array(
		'in_footer' => true,
		'strategy'  => 'async',
	)
)

This exact same means of specifying footer printing may be achieved via the wp_enqueue_script() function.

Implementation details

This feature enhances the existing Scripts API by providing a simple means of specifying a loading strategy by extending commonly used & well known aspects of the Scripts API. It also takes into consideration a script’s dependency tree (its dependencies and/or dependents) when deciding on an “eligible strategy” so as not to result in application of a strategy that is valid for one script but detrimental to others in the tree by causing an unintended out of order of execution. This is near-impossible to achieve via the prior means of adding script loading strategy attributes when using the alternative “hacky” means outlined in the section above.

Technical implementation of the script loading strategy enhancements have been undertaken within the existing Scripts API, notably within the WP_Scripts class, and via enhancements to the familiar and commonly used wp_register_script() and wp_enqueue_script() functions.

A note on dependencies vs dependents
To avoid confusion regarding terminology, let’s clarify the difference between a script’s dependencies vs. its dependents. A script’s dependencies refers to the scripts that said script itself depends on, i.e they must be enqueued prior to said script being enqueued. A script’s dependents on the other hand refers to the scripts that depend on said script, i.e scripts that define said script in their dependencies array.

Changes to the `$in_footer` parameter of `wp_register_script()` and `wp_enqueue_script()` functions

The most notable change to the existing wp_register_script() and wp_enqueue_script() functions is the function signature change, where $in_footer (previously a boolean parameter) has been overloaded to also accept an array $args parameter, with any of the following keys:

(bool) in_footer
- Behaves just like prior implementation of the top level $in_footer param.
(string) strategy
- Accepts an intended loading strategy for the given script being registered/enqueued. Acceptable string values available at the time of implementation are defer for deferred scripts and async for asynchronous scripts.
- Defaults to blocking behavior, thus retaining backward compatibility for existing script registrations and enqueues.

Retaining backward compatibility

For prior/existing usage of the wp_register_script() and wp_enqueue_script() functions making use of the $in_footer boolean param, backward compatibility is retained via logic that explicitly sets the scripts group to the applicable value for footer or headerHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes. printing based on the boolean value passed to the new/overloaded $args parameter. Thus, full backward compatibility is retained and this is a non-breaking enhancement of the API.

While the changes introduced within this feature themselves are considered non-breaking, when making use of the new $args parameter (replacing/overloading the previous $in_footer parameter) in a pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party/theme/codebase powered by WordPress <6.3, there is one scenario where the $in_footer intention would be misunderstood by core. Take for example the following scenario:

wp_register_script( 
	'foo', 
	'/path/to/foo.js', 
	array(), 
	'1.0.0', 
	array( 
		'strategy'  => 'defer',
		'in_footer' => false, // Note: This is the default value.
	)
);

In WordPress >=6.3 this would be correctly evaluated as being printed in the head via the in_footer array key value being false (which is also the default).

In WordPress versions <6.3, however, the presence of the above array assigned to the $in_footer parameter would itself evaluate to a boolean value of true, the opposite of what may be intended by the developer. That being said, one could rightfully argue that in versions of WordPress that do not support deferred/asynchronous scripts, having them printed in the footer is the next best alternative.

The simplest way to prevent this interoperability problem is to pass the strategy via a different means than the $args param to wp_register_script() or wp_enqueue_script() functions.

It can be passed instead via wp_script_add_data(), in which case it will be understood by WordPress 6.3 but ignored by older versions.

wp_register_script( 
	'foo', 
	'/path/to/foo.js', 
	array(), 
	'1.0.0', 
	false
);
wp_script_add_data( 'foo', 'strategy', 'defer' );

Alternatively, interoperability between WordPress versions newer and older than 6.3 using a single function call per script can be achieved by wrapping script registrations/enqueues within a wrapper function that accounts for new and old function signatures, thus retaining total backward compatibility.

An example of such a script registration/enqueue wrapper may look something as follows:

myplugin_register_script( $handle, $src, $deps, $ver, $args ) { 
    global $wp_version;

    // If >= 6.3, re-use wrapper function signature.
    if ( version_compare( $wp_version,'6.3', '>=' ) ) { 
        wp_register_script(
            $handle,
            $src,
            $deps,
            $ver,
            $args
            );
        } else {
        // Extract in_footer value for older version usage.
        $in_footer = isset( $args['in_footer'] ) ? $args['in_footer'] : false;
        
        wp_register_script(
            $handle,
            $src,
            $deps,
            $ver,
            $in_footer
        );
    }
}

Intended vs. eligible loading strategies

It should be noted that while a developer may intend for a given script to contain a certain loading strategy, the final loading strategy may differ based on factors such as script dependencies/dependents and inline scripts.

For example, if a developer registers script foo with a strategy of defer, its dependencies must either use a defer or blocking strategy and its dependents must use a defer strategy in order for the intended execution order to be maintained. If a dependent of said script foo is then registered with a blocking intended strategy, script foo and all of its dependencies would then become blocking.

Newly added logic within the WP_Scripts class is responsible for exercising a series of logical checks that ensure that the final strategy for a given script handle is the most eligible strategy based on the factors outlined further above.

A handle will never inherit a strategy that is “more strict” than the one intended, i.e. a script marked for deferred loading will never be changed to asynchronous loading, but the reverse may indeed be the outcome if environmental factors warrant it.

Inline scripts

There are some nuances when applying a loading strategy to scripts (or scripts in the dependency tree) that have inline scripts attached to them, as this ultimately has an effect on the final outcome of an intended/eligible strategy.

Inline scripts that are registered in the before position, remain largely unchanged in behavior, given that they will inherently be parsed and/or executed before the main/parent script is parsed for immediate, deferred or asynchronous execution.

Inline scripts that are registered in the after position (the default for wp_add_inline_script()), however, will affect the final loading strategy of a main/parent script if said main/parent script has an async or deferred eligible strategy. This is largely due to the complexity in ensuring that inline scripts attached to deferred/asynchronous scripts execute at the appropriate and expected time, while not having a negative impact on the parent script itself, and the dependency tree as a whole.

Therefore, if a given script handle contains inline scripts in the after position, this script will be assumed to be blocking and any intended strategy such as defer/async will be removed, with the final eligible strategy being blocking. This, in turn, may affect the script’s dependency tree, and all scripts within it, may too, be treated as blocking scripts in a bid to retain correct execution order and functionality of the enqueued scripts. Logic is explicitly employed to ensure correct execution order of the script tree in these instances.

A follow-up ticketticket Created for both bug reports and feature development on the bug tracker. #58632 has been opened to continue ongoing discussions and proof of concept implementations to potentially introduce delayed execution of inline after scripts in the future which would preserve their loading order.

Migrating to the new API

Code implementations making use of legacy methods of adding async or defer attributes to script tags should migrate to the new API. These include scenarios where the attributes have historically been added to a script tag by way of the script_loader_tag filter, or worse via the clean_url filter.

The following examples show implementation that make use of the script_loader_tag and clean_url filters, which are now considered less-than-ideal approaches, and then show how it should be done using the new API:

MigrationMigration Moving the code, database and media files for a website site from one server to another. Most typically done when changing hosting companies. Consideration Example 1: Adding a `defer` attribute via the `script_loader_tag` filter

function old_approach( $tag, $handle ) {
// Only affects foo script.
    if ( 'foo' !== $handle) {
        return $url;
    }

// Modern implementations may employ WP_HTML_Tag_Processor here.
    return str_replace( ' src=', ' defer src=', $tag );
}
add_filter( 'script_loader_tag', old_approach, 10, 2 );

Migration Consideration Example 2: Adding a `defer` attribute via the `clean_url` filter

// WARNING: THIS HAS ALWAYS BEEN BRITTLE AND IS NOT RECOMMENDED.
function old_brittle_approach( $url ) {
    // Only affects foo script.
    if ( false === strpos( $url, 'foo.js' ) ) {
        return $url;
    }

    return "$url' defer "; // Assumes single-quoted attributes!
}
add_filter( 'clean_url', 'old_brittle_approach' );

If you are using an approach similar to the one above to add defer or async attributes to a script, please migrate to the new API by using any one of the approaches outlined earlier in this post.

—

Props: @joemcgill @flixos90 @westonruter @adamsilverstein @jyolsna @stevenlinx

#6-3, #dev-notes, #dev-notes6-3

Andrea Fercia 7:17 am on July 20, 2023

Thank you so much for this note. For accessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility), readability, and education, I’d like to remind that expanding abbreviations / acronyms on first use would be great. This isn’t ideal;
via improved LCP performance

This is better:
via improved Largest Contentful Paint (LCP) performance
- Simon Dowdles 10:28 am on July 25, 2023
  
  @afercia thank you for taking the time to raise this, it is a very valid point indeed. I have noted this for future publications, and will also communicate with the necessary parties of the 6.3 release in a bid to get this Dev Notedev note Each important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include a description of the change, the decision that led to this change, and a description of how developers are supposed to work with that change. Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase. updated. Thank you!
  - Andrea Fercia 12:07 pm on July 25, 2023
    
    Thank you @10upsimon
    - Simon Dowdles 1:21 pm on July 25, 2023
      
      @afercia change applied, thank you kindly!

Thank you so much for the async/defer update! I’ve got several websites that have been bandaided together and I’m excited to rip that off to use the built-in APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways.!

Now how about something for the defer CSSCSS Cascading Style Sheets. hack? 🙂

@tessawatkinsllc defer and async are not valid attributes of the element, I am not sure if this is what you were eluding to when you mentioned “defer CSSCSS Cascading Style Sheets. hack”?

Deferring non-critical CSS can be done in a number of ways, but the most common is by preloading the resource. See https://web.dev/defer-non-critical-css/ for a simple example of this.

Something like that! I use this function that basically adds the stylesheet for print media and then swaps out that attribute on pageload using the `onload` attribute and is called from a function I’ve hooked into the `style_loader_tag` filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output..

/**
 * Load CSS Asyncrhonously
 *
 * Trick to prevent stylesheets from blocking the page from rendering.
 *
 * @param string $handle The handle of the CSS file to load.
 * @param string $absolute_url The absolute URL of the CSS file to load.
 * @param string|bool $preconnect Optional. If true, will add a line to preconnect to the domain. If a string domain is provided, will use that. Default is false to disable preconnecting.
 * @param bool $echo Optional. If true, will echo the HTML contents. Default is true.
 * @param string|false $media Optional. The media attribute for the CSS. Default is `all`
 * @return string HTML markup that loads CSS async with a fallback and option to preconnect.
 */
function au_load_css_async($handle, $absolute_url, $preconnect = false, $echo = true, $media = 'all')
{
    $html = '';
    if ($absolute_url) {
        if ($preconnect) {
            if (!is_string($preconnect)) {
                $parsed_url = wp_parse_url($absolute_url);
                $preconnect = $parsed_url['scheme'] . '://' . $parsed_url['host'];
            }
            $html .= sprintf('<link rel="preconnect" href="%s" crossorigin="anonymous" />', $preconnect) . PHP_EOL;
        }
        $html .= sprintf(
            '<link rel="stylesheet" id="%1$s-css" data-async="true" data-preconnect="%3$s" href="%2$s" media="print" onload="this.onload=null;%4$s" />' . PHP_EOL . '<noscript><link rel="stylesheet" id="%1$s-css-fallback" href="%2$s" media="%5$s" /></noscript>',
            $handle,
            $absolute_url,
            $preconnect ? 'true' : 'false',
            $media && $media != 'all' ? sprintf('this.attr(\'media\', \'%s\');', $media) : 'this.removeAttribute(\'media\');', //If $media was specified to something other than "all", replace it. Otherwise remove the attribute.
            $media ? $media : 'all' //noscript fallback value
        ) . PHP_EOL;
        if ($echo) {
            echo ($html);
        }
    }
    return $html;
}

edo888 7:10 am on July 25, 2023
Hi,

It would be nice to have the ability to add custom attributes to script tags which can be later used inside javascriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/.: document.currentScript.getAttribute('...').

Something like
```
    array( 
        'strategy'  => 'defer',
        'in_footer' => false,
        'attributes' => array(
            'data-test' => 'test'
        )
    )
```
Thanks!
- Weston Ruter 9:11 pm on July 25, 2023
  Hi there. This is still possible using using the script_loader_tag filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output.. For example:
```
add_filter( 
	'script_loader_tag', 
	static function ( $tag, $handle ) {
		if ( 'foo' === $handle ) {
			$p = new WP_HTML_Tag_Processor( $tag );
			if ( $p->next_tag( 'script' ) ) {
				$p->set_attribute( 'data-test', 'test' );
				$tag = $p->get_updated_html();
			}
		}
		return $tag;
	}, 
	10, 
	2 
);
```
  Granted, this is neither as efficient nor concise as passing an
  attributes array to wp_register_script()/wp_enqueue_script(). Alternatively, we’re planning to make use of wp_get_script_tag() to construct the script tagtag A directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.), and in that case you’d be able to use the wp_script_attributes filter instead. See #58664. But again, that’s not as concise either as what you’ve proposed.
  
  I suggest opening a ticket with your use case.
- Tessa (they/them), AuRise Creative 6:21 pm on August 21, 2023
  I second this! I’m doing something similar to ensure scripts are compliant with specific cookie consent categories. Would love to be able to pass something like this when registering/enqueuing scripts:
```
array( 
    'in_footer' => true,
    'strategy'  => 'defer',
    'attributes' => array(
        'data-cookieconsent' => 'necessary' // preferences | statistics | marketing
    )
)
```
  And then see it outputted in the HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. automatically.
Michelle Blanchette 5:30 pm on August 19, 2023

From this post, I still didn’t understand how to actually migrate away from the old `script_loader_tag` filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. way of adding the script loading strategies.

Prior to this update, I’ve used that filter hook with `str_replace()` as described in this post to optimize the loading strategy of third-party scripts. This post mostly explains how to use the new loading strategy option when registering or enqueueing your own scripts, but it doesn’t explain what alternative hook we should use when migrating away from the old ways.

To cover this use case, I’m now using the following method in my custom theme:
“`php
/**
* Optimize critical path latency for scripts.
*
* Scripts are only optimized on frontend screens that are
* controlled by the theme. (ie. NOT wp-login.php)
*
* param string[] $handles The enqueued script handles.
*/
function mytheme_optimize_script_loading( $handles = array() ) {

if ( is_admin() || current_user_can( ‘edit_posts’ ) ) {
return $handles;
}

if ( is_singular() ) {

foreach ( $handles as &$handle ) {

if ( in_array( $handle, DEFER_SCRIPTS, true ) ) {
wp_script_add_data( $handle, ‘strategy’, ‘defer’ );
}

if ( in_array( $handle, ASYNC_SCRIPTS, true ) ) {
wp_script_add_data( $handle, ‘strategy’, ‘async’ );
}
}
}

return $handles;
}
add_filter( ‘print_scripts_array’, ‘mytheme_optimize_script_loading’, \PHP_INT_MAX, 1 );
“`

Is this the correct way to go about this?
- Michelle Blanchette 5:32 pm on August 19, 2023
  Oof… The message preview currently isn’t working for me, so I can’t tell how my code blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. is being formatted until I post it.
  
  Maybe this will come out better.
```
/**
 * Optimize critical path latency for scripts.
 *
 * Scripts are only optimized on frontend screens that are
 * controlled by the theme. (ie. NOT wp-login.php)
 *
 * @param string[] $handles The enqueued script handles.
 */
function mytheme_optimize_script_loading( $handles = array() ) {

	if ( is_admin() || current_user_can( 'edit_posts' ) ) {
		return $handles;
	}

	if ( is_singular() ) {

		foreach ( $handles as &$handle ) {

			if ( in_array( $handle, DEFER_SCRIPTS, true ) ) {
				wp_script_add_data( $handle, 'strategy', 'defer' );
			}

			if ( in_array( $handle, ASYNC_SCRIPTS, true ) ) {
				wp_script_add_data( $handle, 'strategy', 'async' );
			}
		}
	}

	return $handles;
}
add_filter( 'print_scripts_array', 'mytheme_optimize_script_loading', \PHP_INT_MAX, 1 );
```
  - Tessa (they/them), AuRise Creative 7:45 pm on August 21, 2023
    wp_script_add_data
    
    I’ve been using the `wp_enqueue_scripts` action instead, putting it at the very end like so:
    
    function prefix_optimize_scripts() { $wp_scripts = wp_scripts(); foreach ($wp_scripts->queue as $handle) { prefix_maybe_optimize_script($handle, $wp_scripts->registered[$handle], $wp_scripts); } } add_action('wp_enqueue_scripts', 'prefix_optimize_scripts', PHP_INT_MAX, 0);
    
    And then the function that actually does the optimization check:
    
    /** * Optimize Script * * @param string $handle the script's handle as it was enqueued * @param _WP_Dependency $data the script's enqueue/registration data * * @return void */ function prefix_maybe_optimize_script($handle, $data, $wp_scripts) { // Check if strategy is already set if (!array_key_exists('strategy', $data->extra)) { if (in_array($handle, ASYNC_SCRIPTS, true)) { wp_script_add_data($handle, 'strategy', 'async'); } elseif (in_array($handle, DEFER_SCRIPTS, true )) { wp_script_add_data( $handle, 'strategy', 'defer' ); // Check dependencies if (count($data->deps)) { foreach ($data->deps as $handle_dep) { prefix_maybe_optimize_script($handle_dep, $wp_scripts->registered[$handle_dep], $wp_scripts); } } } } }

Comments are closed.

Welcome!

Communication

Registering scripts with `async` and `defer` attributes in WordPress 6.3

Why is this enhancement useful?

Summary of the changes

Example 1: Specifying a loading strategy for a script

Example 2: Specifying that a script be printed in the footer via the new API

Implementation details

Changes to the `$in_footer` parameter of `wp_register_script()` and `wp_enqueue_script()` functions

Retaining backward compatibility

Intended vs. eligible loading strategies

Inline scripts

Migrating to the new API

MigrationMigration Moving the code, database and media files for a website site from one server to another. Most typically done when changing hosting companies. Consideration Example 1: Adding a `defer` attribute via the `script_loader_tag` filter

Migration Consideration Example 2: Adding a `defer` attribute via the `clean_url` filter

Welcome!

Communication

Why is this enhancement useful?

Summary of the changes

Example 1: Specifying a loading strategy for a script

Example 2: Specifying that a script be printed in the footer via the new API

Implementation details

Changes to the $in_footer parameter of wp_register_script() and wp_enqueue_script() functions

Retaining backward compatibility

Intended vs. eligible loading strategies

Inline scripts

Migrating to the new API

MigrationMigration Moving the code, database and media files for a website site from one server to another. Most typically done when changing hosting companies. Consideration Example 1: Adding a defer attribute via the script_loader_tag filter

Migration Consideration Example 2: Adding a defer attribute via the clean_url filter

Share this:

Changes to the `$in_footer` parameter of `wp_register_script()` and `wp_enqueue_script()` functions

MigrationMigration Moving the code, database and media files for a website site from one server to another. Most typically done when changing hosting companies. Consideration Example 1: Adding a `defer` attribute via the `script_loader_tag` filter

Migration Consideration Example 2: Adding a `defer` attribute via the `clean_url` filter