You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Magic tags for {@user.field} multi-select relationship taxonomy fields have inconsistent output and passed values to helper functions.
If multiple terms are assigned to the field:
In a query for a CPT, {@user.field} outputs only the first term, and it's the Term ID.
In a query for a CPT, {@user.field,helper_function} passes false to the helper.
In a query over users, {@field} passes a formatted string of Term Names with "and".
In a query over users, {@field,helper_function} passes an array of term arrays.
This was found to be an issue with taxonomy relationship fields associated with users.
It's not yet known whether the issue also applies to relationship fields from or to other object types or single-select fields.
Not included in the example, but also problematic, are {@user.field.term_id} and {@user.field.term_id,helper}
It's also notable that when adding fields to a user, a field key that is the same as a taxonomy key is allowed; this is not allowed on post types. While this did not seem to be the cause of the issue, as the tests check fields with two different names, it is confusing.
It's also notable that in the var_dump()s of the term arrays, term_id, term_taxonomy_id, parent, count, term_group, object_id, term_order, and pod_item_id are all of type string, while integer would most likely be appropriate.
Possible Workaround
Extensive unit tests.
Site Health Information
It's a LocalWP multisite on WP 6.3.1 with no other plugins active.
Hi @pd-cm
Could you please test my patch for this issue? #7153
It's also notable that when adding fields to a user, a field key that is the same as a taxonomy key is allowed; this is not allowed on post types. While this did not seem to be the cause of the issue, as the tests check fields with two different names, it is confusing.
Users do not have taxonomies by default in WordPress, therefore these are not reserved keys for users.
When using relationship fields these taxonomies are not stored as term relationships but as metadata.
Description
Magic tags for
{@user.field}
multi-select relationship taxonomy fields have inconsistent output and passed values to helper functions.If multiple terms are assigned to the field:
{@user.field}
outputs only the first term, and it's the Term ID.{@user.field,helper_function}
passes false to the helper.{@field}
passes a formatted string of Term Names with "and".{@field,helper_function}
passes an array of term arrays.This was found to be an issue with taxonomy relationship fields associated with users.
It's not yet known whether the issue also applies to relationship fields from or to other object types or single-select fields.
Not included in the example, but also problematic, are
{@user.field.term_id}
and{@user.field.term_id,helper}
It's also notable that when adding fields to a user, a field key that is the same as a taxonomy key is allowed; this is not allowed on post types. While this did not seem to be the cause of the issue, as the tests check fields with two different names, it is confusing.
Originally reported in this thread where the field names and taxonomy names are in a mix of German and English, changing through the course of the conversation: https://wordpress.org/support/topic/compare-cpt-taxonomy-to-users-relationship-field/ . A PHP approach to expected behavior was provided on page 2: https://wordpress.org/support/topic/compare-cpt-taxonomy-to-users-relationship-field/page/2/#post-17019774
Version
2.9.19
Testing Instructions
Screenshots / Screencast
Term 2
isterm_id
4
.Term 3
isterm_id
5
.It's also notable that in the
var_dump()
s of the term arrays,term_id
,term_taxonomy_id
,parent
,count
,term_group
,object_id
,term_order
, andpod_item_id
are all of typestring
, whileinteger
would most likely be appropriate.Possible Workaround
Extensive unit tests.
Site Health Information
It's a LocalWP multisite on WP 6.3.1 with no other plugins active.
Pods Package
The text was updated successfully, but these errors were encountered: