Page profiler endpoint fatals on PHP 8 when the request has no `b` (background selectors) field

从 inc/rest.php 第 958-994 行附近开始，这里会读取 b 参数并传给 count()，并检查第 142-160 行附近的路由注册。用提供的 REST 请求或纯 PHP 检查来复现，然后让缺失、为 null 或字符串类型的 b 表现为没有后台选择器，而不触发 fatal。还要覆盖 :987 和 :993 处的嵌套计数。完成意味着这些情况正常返回或返回标准错误响应，而不是 HTTP 500，并且有效请求仍会存储优化数据。

Description

POST /wp-json/optml/v1/optimizations (the public page profiler endpoint) reads b with get_param( 'b' ) and calls count() on it without checking its type. b is not declared in the route args, so when it is missing (or null, or a string) PHP 8 throws TypeError: count(): Argument #1 ($value) must be of type Countable|array, null given at inc/rest.php:974. WordPress then answers HTTP 500 "There has been a critical error on this website." and a PHP fatal is written to the error log.

This happens after the HMAC and Origin checks, so it needs a valid page token. That token is printed in the page source for every logged-out visitor on a page that is not profiled yet, so any HTTP client (not only the bundled script) can trigger the fatal and the log line. The bundled script always sends b, so normal visits are not affected.

The nested values have the same problem: count( $above_fold_bg_selectors ) (:987) and count( $bg_urls ) (:993) fatal on null. The bundled script sets each entry to null first and only replaces it when it finds URLs (assets/js/modules/main.js:231-237), so a null there is likely rare but possible.

Expected: a missing or malformed b is treated as "no background selectors" (or rejected with the normal code: error response), never a fatal.

Step-by-step reproduction instructions

1. On a test site running PHP 8.x with Optimole 4.2.17 active (the route is registered even when the plugin is not connected), run:

   wp eval '
   $u  = "repro-profile-id"; $t = time(); $pu = home_url( "/" );
   $r  = new WP_REST_Request( "POST", "/optml/v1/optimizations" );
   $r->set_header( "content-type", "application/json" );
   $r->set_header( "origin", "https://" . wp_parse_url( home_url(), PHP_URL_HOST ) );
   $r->set_body( wp_json_encode( [ "d" => 1, "a" => [ 1 ], "u" => $u, "t" => $t, "pu" => $pu, "h" => wp_hash( $u . $t . $pu, "nonce" ) ] ) );
   var_dump( rest_do_request( $r )->get_data() );
   '
   

2. Result (from reading the code and the PHP check in step 5; I did not run it on a live site): PHP Fatal error: Uncaught TypeError: count(): Argument #1 ($value) must be of type Countable|array, null given in .../inc/rest.php:974.
3. Add "b" => new stdClass() to the body and run it again: it should get past :974 with no fatal and return "Optimization data stored successfully" (it stores a small profile transient for repro-profile-id).
4. Over HTTP as a logged-out client: open a not-yet-profiled page, copy pageProfileId, _t, hmac and pageProfileUrl from the optimoleDataOptimizer script in the page source, and POST them as u, t, h, pu (plus d, a) to /wp-json/optml/v1/optimizations with Content-Type: application/json and Origin: https://<site host>, leaving out b. The response is HTTP 500 with "code":"internal_server_error" and the fatal above is logged.
5. Pure PHP check of the same lines (PHP 8.4.19), body decoded with json_decode( $body, true ) as WP_REST_Request does:

   b absent           => TypeError: count(): Argument #1 ($value) must be of type Countable|array, null given
   b is {}            => Optimization data stored successfully
   b null             => TypeError: count(): Argument #1 ($value) must be of type Countable|array, null given
   b string           => TypeError: count(): Argument #1 ($value) must be of type Countable|array, string given
   b inner url null   => TypeError: count(): Argument #1 ($value) must be of type Countable|array, null given   (the :993 count)
   

Screenshots, screen recording, code snippet or Help Scout ticket

b is read after the signature and origin checks and counted without a type check:
https://github.com/Codeinwp/optimole-wp/blob/v4.2.17/inc/rest.php#L958-L976

if ( wp_hash( $url . $time . $current_url, 'nonce' ) !== $hmac ) { ... }
$bg_selectors = $request->get_param( 'b' );
...
if ( count( $bg_selectors ) > 100 ) {

Nested counts: https://github.com/Codeinwp/optimole-wp/blob/v4.2.17/inc/rest.php#L983-L994

The route only declares d, a and u, with permission_callback => '__return_true':
https://github.com/Codeinwp/optimole-wp/blob/v4.2.17/inc/rest.php#L142-L160

The token is printed for logged-out visitors on unprofiled pages:
https://github.com/Codeinwp/optimole-wp/blob/v4.2.17/inc/manager.php#L515-L523 and https://github.com/Codeinwp/optimole-wp/blob/v4.2.17/inc/admin.php#L1070-L1083

The bundled script's null placeholder for nested entries:
https://github.com/Codeinwp/optimole-wp/blob/v4.2.17/assets/js/modules/main.js#L226-L237

Core does not catch it: call_user_func( $handler['callback'], $request ) in WP_REST_Server::respond_to_request() (wp-includes/rest-api/class-wp-rest-server.php:1293 in WordPress 7.1.3, :1181 in 6.2). The fatal error handler then answers with status 500 (wp-includes/class-wp-fatal-error-handler.php:212 in 7.1.3). REST is not a protected endpoint, so no recovery mode email is sent (wp-includes/class-wp-recovery-mode.php:176-178).

A likely fix is to declare b in the route args (type => object, default => []) or to guard with is_array() before each count() and foreach, at :974, :987 and :993.

Environment info

• Optimole 4.2.17 (inc/rest.php is the same on master and development at 63f3f7c)
• Any WordPress version the plugin supports (5.5 and later; core lines cited from 7.1.3 and 6.2)
• PHP 8.0 and later. On PHP 7.4 count( null ) only logs a warning and the request goes on.

Is the issue you are reporting a regression

No. The same code has been there since the endpoint was added in 4.0.0.

Found while writing the WordPress compatibility checks for Optimole.