Bug: Breaking changes to `wp_register_script` and `wp_enqueue_script` functions

[vasartam]

#12009 introduced a breaking change to the API that breaks existing PHP 8.0 code.

I had my production site broken after automatic update to WordPress 6.3.0 due to the changes to the wp_register_script function API.

I use PHP 8.0 and I call the wp_register_script function using named parameters:

<?php
wp_register_script(
        'rk-scripts-vendors',
        THEME_URL . '/dist/vendors.min.js',
        deps: array(),
        ver: filemtime( THEME_DIR . '/dist/vendors.min.js' ),
        in_footer: true,
);

After automatic update to WordPress 6.3.0 the site started responding with the following error:

Unknown named parameter $in_footer in /var/www/rk.loc/wp-content/themes/rk/src/features/setup/assets.php:58
Stack trace:
#0 /var/www/rk.loc/wp-includes/class-wp-hook.php(310): rk_theme_load_assets()
#1 /var/www/rk.loc/wp-includes/class-wp-hook.php(334): WP_Hook->apply_filters()
#2 /var/www/rk.loc/wp-includes/plugin.php(517): WP_Hook->do_action()
#3 /var/www/rk.loc/wp-includes/script-loader.php(2225): do_action()
#4 /var/www/rk.loc/wp-includes/class-wp-hook.php(310): wp_enqueue_scripts()
#5 /var/www/rk.loc/wp-includes/class-wp-hook.php(334): WP_Hook->apply_filters()
#6 /var/www/rk.loc/wp-includes/plugin.php(517): WP_Hook->do_action()
#7 /var/www/rk.loc/wp-includes/general-template.php(3053): do_action()
#8 /var/www/rk.loc/wp-content/themes/rk/header.php(14): wp_head()
#9 /var/www/rk.loc/wp-includes/template.php(785): require_once('...')
#10 /var/www/rk.loc/wp-includes/template.php(720): load_template()
#11 /var/www/rk.loc/wp-includes/general-template.php(48): locate_template()
#12 /var/www/rk.loc/wp-content/themes/rk/front-page.php(2): get_header()
#13 /var/www/rk.loc/wp-includes/template-loader.php(106): include('...')
#14 /var/www/rk.loc/wp-blog-header.php(19): require_once('...')
#15 /var/www/rk.loc/index.php(17): require('...')
#16 {main} thrown in /var/www/rk.loc/wp-content/themes/rk/src/features/setup/assets.php on line 58

For changes to be backwards compatible in this case a new argument $args should have been added before the $in_footer argument like so:

<?php
wp_register_script( $handle, $src, $deps = array(), $ver = false, $args = array(), $in_footer = false )

That way the existing code that relies on PHP 8.0 named parameters would not be broken.

Similar API changes have been applied to wp_enqueue_script function, and it also needs attention. Possibly there are other significant API changes like this one.

Need to fix this backwards compatibility issue.

[Clorith]

Hiya, welcome to WordPress trac!

Although this is unfortunate, WordPress only advertised beta support for PHP 8.0 or later until the release of WordPress 6.3, and despite this change, it explicitly does not support the use of named arguments at this time.

You can read more about WordPress and how it supports PHP versions at ​https://make.wordpress.org/core/handbook/references/php-compatibility-and-wordpress-versions/

Since this is explicitly not supported at this time, I'm going to close thia ticket for now, but if you'd like to discuss it further replies are always possible! (and apologies for the sort of dire t status of wontfix, it is the closest status that fits the scenario)

[vasartam]

Replying to Clorith:

Hiya, welcome to WordPress trac!

Although this is unfortunate, WordPress only advertised beta support for PHP 8.0 or later until the release of WordPress 6.3, and despite this change, it explicitly does not support the use of named arguments at this time.

You can read more about WordPress and how it supports PHP versions at ​https://make.wordpress.org/core/handbook/references/php-compatibility-and-wordpress-versions/

Since this is explicitly not supported at this time, I'm going to close thia ticket for now, but if you'd like to discuss it further replies are always possible! (and apologies for the sort of dire t status of wontfix, it is the closest status that fits the scenario)

Thanks for the fast and clear reply. I acknowledge the reason the ticket is closed, so no worries.

Now I see what made the WordPress team come up with that decision, thanks for pointing this out.