bp_get_the_profile_field_is_required filter has nothing to check against.

[tw2113]

We pass in a boolean value, but we don't pass in anything like the current field that could be used to conditionally change the boolean value we return.

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.

[boonebgorges]

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.

[tw2113]

Looked through the file and at least for this one file, these two were the only ones that made sense to need a field id parameter.

[boonebgorges]

Looks like the patch needs refreshing and the documentation needs updating. Otherwise the change looks good.

[tw2113]

Will do, for both this and 7325 a little bit ago.

[tw2113]

In 11365:

Adds field IDs to bp_get_the_profile_field_is_required and bp_get_the_profile_field_visibility_level filters.

Fixes #6086.