[buddypress-trac] [BuddyPress Trac] #6086: bp_get_the_profile_field_is_required filter has nothing to check against.

[buddypress-trac]

#6086: bp_get_the_profile_field_is_required filter has nothing to check against.
--------------------------+-----------------------------
 Reporter:  tw2113        |       Owner:
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Future Release
Component:  Core          |     Version:
 Severity:  normal        |  Resolution:
 Keywords:  needs-patch   |
--------------------------+-----------------------------
Changes (by boonebgorges):

 * keywords:   => needs-patch
 * milestone:  Awaiting Review => Future Release


Comment:

 > From the looks of it, there would potentially be access to the "$field"
 global but the user would need to know about that and call it themselves
 in their hook callback.

 Yes, I think this is the reason. A couple considerations:

 - The `$field` global is an object, and passing it to the filter by
 reference (as it would be passed by default) may invite developers to do
 odd things with it. Not functionally different from directly referencing
 the global, but it makes it a bit more tempting.
 - The format of the `$field` global is pretty odd and specific to our loop
 implementation. IMO we should be discouraging reference to it, because it
 prevents us from making certain kinds of changes to this icky loop in the
 future.
 - If we're going to make a change to one hook, we should do it in all
 xprofile template hooks.

 How about if we pass the field id, and leave it to the devs to fetch the
 field object using `BP_XProfile_Field`? This would mitigate the issues
 I've described above.

--
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/6086#comment:1>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac