\IPS\Member::profileFields

[Marcher Technologies]

Could we get a flag on this method that will allow it to return fields configured with "Member can see?" set to no? Right now, if I want to use such a field programmatically I am *forced* to issue an additional query, the field's value is not obtainable with this method, nor any method in \IPS\Member...

[Marcher Technologies]

On a similar subject, could this method possibly cache the results against repetitive queries made due to calls for profile fields of the same member on the same page? Especially when viewing comments of content items where there is back and forth between a few specific members, this would save several unnecessary queries for data we've already loaded when we are doing something like the above, using a hidden profile field programatically in such areas. I see it already does this for the fields shown via "Display format" config.

[Mark]

I could add a $location parameter that gets passed along to \IPS\core\ProfileFields\Field::values() - would that work for you?

[Marcher Technologies]

29 minutes ago, Mark said:

I could add a $location parameter that gets passed along to \IPS\core\ProfileFields\Field::values() - would that work for you?

Reviewing the code, yeah, it's that it's passing \IPS\core\ProfileFields\PROFILE instead of defaulting to it and letting us pass it there, so that would indeed work.

[Mark]

Done.

[Marcher Technologies]

Thanks ever so much for this. Extremely helpful.

I just wanted to note there seems to be a rather odd (execution order?) issue in regards to using the constants in the \IPS\core\ProfileFields namespace if it so happens to be the first time the class is being called.

{{$fieldData = \IPS\Member::loggedIn()->profileFields( 2 );}}

works fine, but

{{$fieldData = \IPS\Member::loggedIn()->profileFields( \IPS\core\ProfileFields\STAFF );}}

results in "Undefined constant 'IPS\core\ProfileFields\STAFF'" in that situation. The only solution I can think of would be to move said constants into the \IPS\core\ProfileFields\Field class itself, but that's a fairly large change - in the meantime using the value of the constant desired instead of the constant itself as in example one works fine.

To be very clear, not complaining at all, I'd rather have to do that than issue a direct query for the data(a try/catch block in a template is verrry messy, I've found, so saving that alone is extremely helpful), and I didn't see that one coming in making the request either - it's very subtle.