Open illori opened 9 years ago
i see no performance issue, since we load all fields information in one select and only maintained fields get a dataset.
Recommand to close until someone got a real performance issue with that.
i dont agree with this being closed, i think this should still be looked into. the fields shown are not all necessary and should be limited. i dont think it is a performance issue at first look but what if you have 100 buddies? is it then a performance hit? not to mention that we dont need all this info shown here, what if you have 20 custom profile fields? why do you need them all shown here?
actually looks like there is some code to not show disable the fields but i dont think it is working
$context['custom_pf'] = array(); $disabled_fields = isset($modSettings['disabled_profile_fields']) ? array_flip(explode(',', $modSettings['disabled_profile_fields'])) : array(); while ($row = $smcFunc['db_fetch_assoc']($request)) if (!isset($disabled_fields[$row['col_name']])) $context['custom_pf'][$row['col_name']] = array( 'label' => $row['field_name'], 'type' => $row['field_type'], 'bbc' => !empty($row['bbc']), 'enclose' => $row['enclose'], );
`// Gotta disable the gender option.
if (isset($context['custom_pf']['cust_gender']) && $context['custom_pf']['cust_gender'] == 'Disabled')
unset($context['custom_pf']['cust_gender']);
$smcFunc['db_free_result']($request);`
this is from profile-modify.php that should remove the fields that are set to not show on the memberlist right?
Like I mention from performance point of view it's not critical. 100 Buddies with 20 customs fields (where not all are maintained) are literay 1k datarows -> 1k is nothing even when als fields a maintained by all user 2k rows keeps nothing.
When you got complains about the displaying, than i don't care.
My thoughts are that your buddies list your more likely to want to see their information displayed. This differs from the generic memberlist which is just showing member information. Profile Fields allows showing/hiding on the memberlist.
I don't think a change is needed here.
The useful fields on the members list are likely not the same as the useful fields on the buddies list, so using the same setting to determine both lists isn't a good solution. But it is also problematic to assume, as the code currently does, that all custom profile fields belong on the buddies list. We should add another setting for the profile fields to specify whether they should be included on the buddies list. It'll just take another checkbox in the UI and another column in the table.
First of all you say rc 1 bitin rc 2
rc1 needs to be released, so this pr can wait.
A beautiful dream, as if it were really rc1d rc 2
especially a rc1
So what is target of this issue?
It is still marked for RC2 although I can argue this isn't a critical issue and while it needs to be done it can be easily be labeled for Final.
well my question was, what is here do now?
We should add another setting for the profile fields to specify whether they should be included on the buddies list. It'll just take another checkbox in the UI and another column in the table.
Since there aren't any other suggestions I suppose this still applies.
IMO the custom profile fields should not show on the buddy list unless they also show on the members list. currently all the fields show even if they are not on the members list. this can cause a lot of info to be loaded on that page that may not be important to see.