Inconsistent $operator documentation for wp_filter_object_list()

[marian1]

The description of the wp_filter_object_list() uses the uppercase form of the operator:

 * If an object has more properties than those specified in arguments,
 * that will not disqualify it. When using the 'AND' operator,
 * any missing properties will disqualify it.

The $operator parameter description likewise documents the accepted values and default using uppercase:

 * @param string      $operator Optional. The logical operation to perform. 'AND' means
 *                              all elements from the array must match. 'OR' means only
 *                              one element needs to match. 'NOT' means no elements may
 *                              match. Default 'AND'.

Both the DocBlock description and the $operator parameter description therefore indicate that uppercase operators should be used.

However, the function declaration uses the lowercase default 'and':

function wp_filter_object_list( $input_list, $args = array(), $operator = 'and', $field = false )

The documentation therefore contradicts the function declaration regarding the casing of the default value and does not explain that the operator is case-insensitive.

wp_filter_object_list() passes $operator to WP_List_Util::filter(), which normalizes it to uppercase before validation:

$operator = strtoupper( $operator );

if ( ! in_array( $operator, array( 'AND', 'OR', 'NOT' ), true ) ) {
        $this->output = array();
        return $this->output;
}

Consequently, lowercase, uppercase, and mixed-case variants produce the same result.

At a minimum, the DocBlock for wp_filter_object_list() should state the actual default and document that the argument is case-insensitive. For example:

 * @param string      $operator Optional. The logical operation to perform. 'AND' means
 *                              all elements from the array must match. 'OR' means only
 *                              one element needs to match. 'NOT' means no elements may
 *                              match. The value is case-insensitive. Default 'and'.

Broader inconsistency

As a related issue, casing is not used consistently across the public functions and methods that ultimately pass $operator to WP_List_Util::filter():

Function or method	Default value	Documented values
get_post_types()	'and'	'and', 'or', 'not'
get_post_stati()	'and'	'and', 'or'
get_taxonomies()	'and'	'and', 'or'
get_post_types_by_support()	'and'	'and', 'or', 'not'
wp_filter_object_list()	'and'	'AND', 'OR', 'NOT'
wp_list_filter()	'AND'	'AND', 'OR', 'NOT'
WP_List_Util::filter()	'AND'	'AND', 'OR', 'NOT'

Although these differences do not affect the filtering results, they make the accepted values and their case sensitivity unclear without tracing the complete call chain.

A broader follow-up could establish consistent casing across these functions.

wp_filter_object_list() documents its $operator default as 'AND', but the function signature declares $operator = 'and'.

The mismatch dates to the function's introduction in 3.0.0. Neither casing is wrong at runtime, since WP_List_Util::filter() uppercases the operator before validating it, so the patch corrects the documented default to 'and' and notes that the value is case-insensitive — the sentence that reconciles the uppercase operator names above it with the lowercase default.

wp_list_filter() and WP_List_Util::filter() already document 'AND' as both their default and their declared value, so they are left alone.

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

## Use of AI Tools

[westonruter]

We should also add typing for this parameter so that PHPStan can flag incorrect usage. Since it is case-insensitive, we can use 'and'|'AND'|'or'|'OR'|'not'|'NOT' (granted, 'And' should also be allowed, but PHPStan can't type all the the variations practically).

We could also consider just standardizing on lower-case for the sake of typing, but still support it as being case-insensitive. This would promote better consistency in terms of code style.