exclude_tree doesn't work in wp_list_pages

[onetrev]

This is a follow-up to #9153.

From my initial testing, if there are multiple exclude_tree arguments in wp_list_pages() it continues to only exclude the first ID in the list.

I am not sure if this ever fully worked for me in WP 3.9, as I've already updated all my sites, but in testing with WP 4.0 I am definitely seeing this issue. I am hoping someone else can confirm this bug still exists (exists again) and we can patch this up again as it definitely would be nice to have this bug fixed.

• on a related note, the codex still says [this bug exists]​http://codex.wordpress.org/Function_Reference/wp_list_pages#Parameters so if/when fixed I supposed this should be updated as well. Thanks!

[helen]

Thanks for the report, sorry we missed this. Is this still an issue?

[onetrev]

Yes, the bug still exists. I completed another test. This time with a totally fresh install of WP 4.1. No plugins running.

As per this bug report from way back #8683 the same thing still happens, whereby it only excludes the last tree (ID) listed.

Hopefully we can get this get this little bug fixed up for 4.2! Thanks!

[helen]

Would need unit tests demonstrating the bug along with the patch to fix it.

[dkotter]

So tried reproducing this today and was not able to, things worked fine for me. I'm using 4.2-beta2 for reference.

I tried using both the comma-delimited string notation:
wp_list_pages( array( 'exclude_tree' => '1,2,3' ) );

and using an array:
wp_list_pages( array( 'exclude_tree' => array( 1, 2, 3 ) ) );

and didn't experience any issues with either approach. Both excluded all pages (and any descendant pages they might have) that I passed in, not just the first one.

[DrewAPicture]

Hi @onetrev, can you please post a code snippet where you're seeing unexpected results with the exclude_tree argument?

[onetrev]

Hmm, okay well this is embarrassing. I was so darn sure I could reproduce this before I opened the ticket originally, but now through multiple attempts everything seems fine.

Suppose it's not a bad thing, as I think this can be safely closed as fixed. Sorry again for this mix up.