wp_list_filter() is inexact when dealing with nested arrays

[scribu]

To reproduce:

add_action('init', 'test_admin_notices', 11);
function test_admin_notices() {
    global $wp_taxonomies;
    print_r( wp_filter_object_list( array_values( $wp_taxonomies ), array( 'object_type' => array( 'post' ) ), 'and', 'object_type' ) );
}

This is because array_intersect_assoc() does a strict comparison: (string) $elem1 === (string) $elem2

Using a manual loop fixes the problem.

Context: #14084

I just came across this problem. The bug breaks get_taxonomies( $args, $output, $operator ) when $args = array('object_type' => array($custom_post_type)), but the patch fixes it. Can we get this in 3.2?

While we're at it, we should use get_object_vars() instead of casting to array, in case the object has non-public properties, which we don't care about.

Replying to scribu:

While we're at it, we should use get_object_vars() instead of casting to array

Done.

Need unit-tests: ​http://unit-tests.trac.wordpress.org/browser/wp-testcase/test_includes_functions.php#L254

Performance benchmark?

add unit tests

add unit tests, i'm not exactly certain of the correct behaviour and cases for test_filter_object_list_nested_array_or and also test_filter_object_list_or_nested_array_or_field, any guidance would be appreciated. any other cases required?

It seems using a foreach is actually faster than array_intersect_assoc().

Using wplf-test.php​ I get:

wp_list_filter_old: 1.6865890026093
wp_list_filter_new: 1.3801169395447
wp_list_filter_new2: 1.871533870697

wp_list_filter_new is the one in 16137.patch​.

wp_list_filter_new2 uses an if + get_object_vars(). Although I made this suggestion, I think it's better to just use casting to arrays.

Speed test

Fix typo in function names

In [18606]:

Properly handle nested arrays in wp_list_filter(). Props scribu, SergeyBiryukov. fixes #16137

​http://unit-tests.trac.wordpress.org/changeset/433