Fix: PHP 8.0 named parameters compatibility

[vidushigupta0607]

Problem

PHP 8.0 introduced named arguments (func(param: $value)), which creates compatibility risks for WordPress Core:

• Functions with reserved keyword parameter names ($string, $array, $class, etc.) cause parse errors when callers use named-argument syntax
• Parameter name mismatches between parent interfaces/abstract classes and child implementations break named-argument calls targeting the parent signature
• call_user_func_array() with associative arrays fails because PHP 8 treats string keys as named arguments, not positional indices

Root Cause

WordPress Core had no systematic audit or enforcement of PHP 8.0 named parameter compatibility. While wp_normalize_call_user_func_args() existed (introduced in WP 7.0), its usage was inconsistent, and reserved keyword parameter names were not actively prevented.

Solution

1. Fixed reserved keyword parameter names:

• Renamed wp_is_valid_utf8() fallback parameter from $string to $bytes (utf8.php:51) to match the primary branch and prevent parse errors with PHP 8.0+ named argument syntax
• Added inline documentation noting the parameter rename

2. Audited and wrapped call_user_func_array() calls:

• Reviewed all 22 Core call_user_func_array() sites across 9 files
• Wrapped dynamic callback calls with wp_normalize_call_user_func_args() where arguments contain user-provided or filter-derived values:
  • functions.php (wp_find_hierarchy_loop_tortoise_hare): 3 call sites
  • blocks.php: 8 call sites for block rendering callbacks
  • interactivity-api: directive callback sites
• Verified remaining sites as safe (internally-constructed positional arrays) with documentation comments

3. Escalated PHPCS enforcement:

• Updated phpcs.xml.dist to escalate Universal.NamingConventions.NoReservedKeywordParameterNames from warning to error severity
• Ensures CI blocks future commits introducing reserved keyword parameter names

4. Verified interface/abstract class alignment:

• Confirmed all parameter names match between parent interfaces/abstract classes and child implementations across all 45+ Core implementations
• No code changes required; all hierarchies are already compliant

Example Usage

Before: Function calls with reserved keyword parameter names would fail under PHP 8.0 named arguments

  // BEFORE — would break with PHP 8.0 named arguments:     
  function wp_is_valid_utf8( string $string ): bool { ... }
  wp_is_valid_utf8( string: "test" );  // Parse error!     

After: Parameter names are non-reserved and compatible

  // AFTER — works with PHP 8.0 named arguments:                                                                                                                                         
  function wp_is_valid_utf8( string $bytes ): bool { ... }                                                                                                                               
  wp_is_valid_utf8( bytes: "test" );  // ✓ Works             

Impact

This change ensures WordPress Core is compatible with PHP 8.0+ named argument syntax across all actively maintained code. The implementation:

• Prevents parse errors and fatal errors when plugins/themes use named arguments with Core functions
• Maintains consistency between function signatures in parent/child class hierarchies
• Properly handles dynamic callbacks via call_user_func_array() with named-argument data
• Enforces compliance in CI to prevent future regressions

Trac Link
https://core.trac.wordpress.org/ticket/59649

[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 vidugupta.

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.