html5_script_support variable is misleading

[jamieburchell]

The $html5_script_support variable used in wp_sanitize_script_attributes() is misleading.

It reads that if the theme supports HTML5 script, use the longform attribute version foo="foo", otherwise only the attribute name. While technically the function returns the correct string due to its placement in the ternary operator, its meaning is backwards.

I believe that the variable should be:

$html5_script_support = is_admin() || current_theme_supports( 'html5', 'script' );

and used thus:

$attributes_string .= $html5_script_support ? ' ' . esc_attr( $attribute_name ) : sprintf( ' %1$s="%2$s"', esc_attr( $attribute_name ), esc_attr( $attribute_name ) );

[westonruter]

@jamieburchell do you want to add a patch for your suggestion?

The $html5_script_support variable used in wp_sanitize_script_attributes() is misleading.

It reads that if the theme supports HTML5 script, use the longform attribute version foo="foo", otherwise only the attribute name. While technically the function returns the correct string due to its placement in the ternary operator, its meaning is backwards. This patch addresses this.

Trac ticket: https://core.trac.wordpress.org/ticket/64128

[sabernhardt]

The $html5_script_support variable and the function go back to [50167].

[westonruter]

In 61052:

Script Loader: Fix logic inversion with $html5_script_support in wp_sanitize_script_attributes().

The value was actually whether HTML5 was not supported.

Follow-up to [50167].

Props jamieburchell, sabernhardt.
See #39941.
Fixes #64128.

[desrosj]

In 61196:

Build/Test Tools: Ensure all db WP-CLI commands work.

This ensures that the presence of a self-signed certificate from a MySQL/MariaDB container will not cause db WP-CLI commands run using env:cli in the local development environments to fail.

Follow up to [60735].

Props westonruter, mukesh27.
Fixes #64128. See #63876.

[desrosj]

Please ignore [61196]. This was meant for #64218,