Code Quality: Use the null coalescing assignment operator for default value assignments

[Soean]

Description

Replacing further isset()/null guards that assign a default value with the null coalescing assignment operator (??=):

// Before
if ( ! isset( $size_data['width'] ) ) {
	$size_data['width'] = null;
}

if ( ! isset( $size_data['height'] ) ) {
	$size_data['height'] = null;
}

if ( ! isset( $size_data['crop'] ) ) {
	$size_data['crop'] = false;
}


// After
$size_data['width']  ??= null;
$size_data['height'] ??= null;
$size_data['crop']   ??= false;

Both forms are functionally identical; ??= is shorter and turns a nine-line block into three lines that read as a single list of defaults.

Scope

This is deliberately limited to blocks where every guard in a contiguous run can be converted, so no mixed styles are left behind within one function:

• WP_Image_Editor_GD::resize() and WP_Image_Editor_Imagick::resize() — the $size_data defaults (identical blocks in both classes).
• WP_Date_Query::build_mysql_datetime() — the $datetime defaults.
• WP_Translation_Controller — the $locale fallback in load_file(), is_textdomain_loaded(), get_files() and has_translation().
• register_post_status() — the $args defaults.

Why this is safe

• ??= requires PHP 7.4, which is already the minimum supported version.
• ??= and ! isset() test the same condition, so the default is applied in exactly the same cases.
• Assignment order is preserved everywhere it matters. In register_post_status() the compound guard above the block is left untouched and still runs first, $args->internal ??= false; still follows it, and publicly_queryable is still derived after public has been resolved.
• In WP_Date_Query::build_mysql_datetime() the preceding array_map( 'absint', $datetime ) turns any existing null into 0, which both isset() and ??= treat as set.
• No behavior change.

Not converted

Similar runs in WP_Query::parse_query(), WP_Post_Type::set_props() and WP_Taxonomy::set_props() contain guards that cannot be expressed as ??= — an elseif branch in the first case, compound conditions such as if ( null === $args['show_in_menu'] || ! $args['show_ui'] ) in the other two. Converting only the neighbouring guards would leave two styles interleaved in the same block, so those are left alone.

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

---

This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Core Committers: Use this line as a base for the props when committing in SVN:

Props soean.

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[github-actions]

Test using WordPress Playground

The changes in this pull request can previewed and tested using a WordPress Playground instance.

WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.

Some things to be aware of

• All changes will be lost when closing a tab with a Playground instance.
• All changes will be lost when refreshing the page.
• A fresh instance is created each time the link below is clicked.
• Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
  it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.

[irozum]

Clean, mechanical simplification — replaces isset()/null guard blocks with ??= across WP_Date_Query::build_mysql_datetime(), the GD/Imagick make_subsize() size-data defaults, four WP_Translation_Controller locale fallbacks, and the register_post_status() defaults, matching #65823. I traced each hunk by hand: ??= short-circuits on the same isset()-false condition the old code checked (including the register_post_status() chain, where publicly_queryable/exclude_from_search/etc. still resolve after public/internal are set, since assignment order is unchanged), so this is behavior-neutral as claimed.

Ran the affected suites plus lint/PHPStan: tests/phpunit/tests/date/query.php, Tests_Image_Editor_GD/Test_Image_Resize_GD, Tests_Image_Editor_Imagick/Test_Image_Resize_Imagick, WP_Translation_Controller_Tests, and isPostStatusViewable.php/wpInsertPost.php for the register_post_status() path — all green. composer lint:errors and PHPStan are clean too (the only lint hits are pre-existing, in files this PR doesn't touch). CI's one red job (PHP 8.5) is an unrelated themes_api() network flake, not caused by this diff.

No behavioral or test-coverage concerns from me — this looks ready.