activity field may be not properly updated if it's called not like by default

bb_func_usernfo.php

line 17,

update fails if the value of $dbUserAct (setup_options.php) is not 'activity'

Why would you want to change that in the first place? :}

Why would you want to change that in the first place?

- I think it is because he uses external users table where this field may be called differently...

Ok I agree such bug exists and for fixing it you will need to put:

$$dbUserAct=$_GET['activity'];
updateArray(array($dbUserAct),$Tu,$dbUserId,$user);

Will be fixed in the next miniBB release.

Thanks!

Same thing on line 76: (bb_func_usernfo.php)

call_user_func('parseUserInfo_'.$ix,$row[$i])

$ix has value of user defined field. The functions above line 76 are defined by the keys of $dbUserSheme.

Regarding your last post: that's absolutely right because we can't create the function which in its name uses the dynamic variable.

You would need to redefine such function yourself in bb_plugins.php, for example

if($action=='userinfo'){
function parseUserInfo_customActivityField($val){
/* code here */
}
}

However I am in doubt why would you need the function for activity field? It's displayed only for admin/moderator and there can't be anything custom to display.

For other fields follow my advice.

I was wondering why you do not use the keys of $dbUserSheme instead of the user defined values to create the function names.

Anyway, I will refine the functions,
Thanks.

If you know the way how the function can be defined using a dynamic variable in it's name, I would be happy to know ;-)

I ment the function name you define in the

call_user_func('parseUserInfo_'.$ix,$row[$i])

part.

If you use the key of $dbUserSheme instead of $ix, you don't need to redefine the function itself.
But maybe I'm missing something here.

I added the redefined function to bb_plugins and all works well!
Thanks again

I think if it works with re-defining, it's good :-) I don't remember already why I have programmed it that way (with the value of $dbUserSheme not the key), but probably there was some reason which I am not supposed to remember ;-)

[and usually if I can't remember the reason it flows up in the future bringing new bug, so let's leave it for a while... it anyway should work in all aspects and is universal approach like now]

usually if I can't remember the reason it flows up in the future bringing new bug

I find this statement true almost every day so I learned not to change too much if not needed ;).