wp_get_post_terms do not work with 'id=>name' argument

[dany2217]

Hi, i'm not sure is that really bug, let me explain it.
When i used code below it doesn't worked for me.

<?php
$terms = wp_get_post_terms($post_id, $taxonomy, array(
'fields' => 'id=>name',
));

// returns
// array(0 => 'term name 1', 1 => 'term name 2')

The term ID is just an index of array, so i tried to find the reason.
After trace the core code i found the problem in wp_get_object_terms function.

<?php
$terms = array_merge( $terms, get_terms( $args ) );

When $terms array was merged, the term ID ( array keys ) were reindexed.
I don't know what logic is the best in this situation, but the array_merge function is not right method i think.

<?php
// maybe something like this ?
$terms = $terms + get_terms( $args );

My english is poor, so take a look for code at first.

[ivankristianto]

@dany2217 welcome and thank you for opening this ticket.
The fields arguments only accept parameters 'all', 'names' or 'ids',
refer to this codex: ​https://codex.wordpress.org/Function_Reference/wp_get_post_terms
So it's not a bug.

[dany2217]

Hi @ivankristianto, thanks for your reply and advise.
I understood about supported arguments, but i think it will be better to support those arguments too.
Because wp_get_post_terms returns result of get_terms function (correctly array of get_terms result) and get_terms function supports arguments like id=>name. So there is only one problem about array_merge logic inside wp_get_object_terms function.
Its not a bug, so could you consider about it for feature release?
Thanks.

[boonebgorges]

I think that the behavior described here may be a regression, due to [40514]. It's likely that we can fix it by using array concatenation $array1 + $array2 rather than array_merge() in cases where the fields parameter implies a non-zero-indexed array. But this will need some automated tests to back it up.

I'm putting the ticket into 4.9 for more exploration.

cc @danielbachhuber, related to #40496 - I may ask you to verify a patch.

[pcarvalho]

i just stumbled on this too. I was wondering what should take precedence, and it seems $terms does.

so, the union ( $array1 + $array2 ) is the right call instead of array_replace.

[isuke01]

Yes, I can confirm, there is issue,
Refer to docs: ​https://developer.wordpress.org/reference/functions/wp_get_post_terms/
I can use args like 'id=>name' or 'id=>slug' - I can use args like in WP_Term_Query::construct
It was like: term_id->term_name now it is: standard_array_key_form_0->term_name

It was working. Im used that on a lot of sites, but now I getting reports, that is something wrong on pages, I figured out is this a problem ( 'id=>name' , etc.).

The question is - it was intended change?
Yes I see on : ​https://codex.wordpress.org/Function_Reference/wp_get_post_terms there is nothing about that.
Which Docs should I use ?

[miyauchi]

I created a patch which contains tests to represent this problem.

[miyauchi]

I improved the patch. :)

[boonebgorges]

@miyauchi Thanks very much for the patch, and especially for the test demonstrating the problem!

In 41293.3.patch​ I made a few modifications to 41293.2.patch​:

• I've moved the test to a more appropriate file
• I made the test a bit more targeted, using wp_get_object_terms() rather than wp_get_post_terms(), and using factory methods to create fixtures rather than edit_post().
• I changed the logic of the array_merge() vs array-concatenation routine, so that it more clearly reflects the cases in which concatenation must be used

Could others please have a look and verify the new patch?

[miyauchi]

Thanks @boonebgorges

I just added some coding standard fixes for this function as well. :)

[boonebgorges]

Thanks, @miyauchi! We generally don't do formatting changes on lines that are not otherwise being touched by a bugfix. See ​https://make.wordpress.org/core/handbook/contribute/code-refactoring/. But we are tracking the coding standards issues; see #41057.

[boonebgorges]

In 41809:

Taxonomy: Don't discard keys when merging queried terms from different taxonomies.

For values of fields like id=>parent, the keys of the array must be
maintained as part of the query results.

Introduced as part of #40496. See [38667], [40513].

Props miyauchi, dany2217, pcarvalho.
Fixes #41293.