Welcome the Technical Support section. Help us in assisting you by providing us with a concise and descriptive elaboration of your issues. Be specific and if possible, provide us with a step-by-step instruction in replicating your problem.
First- and lastname saving fails during registration
when using the functionality for firstname (FIELD_GIVENNAME) and lastname (FIELD_FAMILYNAME) as described here (
documentation.jomsocial.com/wiki/Using_f...name_on_registration
), the first and given name are currently not persistently stored upon registration.
Based on my testing, this has been introduced somewhere in between 4.2.5 and 4.3.2 when updating the saveProfile function in models\profile.php with the following line:
502: $table->remapFieldValue($userId, $fields);
Since the call order in controllers\register.php::registerUpdateProfile() is as follows:
619: //update the first/last name if it exist in the profile configuration
620: $this->_updateFirstLastName($user);
622: $pModel->saveProfile($user->id, $values);
The saveProfile call will overwrite the already saved first and last name and due to the remapFieldValue call the values for first and last name will be removed again.
Thank you for contacting us and reporting this.
I assign developer to investigate this further.
He'll contact you ASAP.
- Instead of saying: 'it's not working', explain the problem in detail.
- Screenshots with the URL visible in them and the problem marked are more than welcome.
- Tell us how to replicate the problem, we can't fix it if we can't find it.
- Make sure that your site/server meets JomSocial System Requirements
- Make sure to setup JomSocial Cron Job
- Always provide us with access details to the backend and ftp. We need it to debug problems.
- If you have a similar problem, but a solution you found isn't working, open a new thread instead of 'merging' with an existing one.
- Use the "Thank You" feature on any post that helped you
Thank you for the response. I have just updated the test system for which you have the details to 4.4 and the issue still exists (which is not really surprising since the relevant functions have not changed in that regard).
this would lead to those fields showing up twice - on the first and on the second page, that would be the reason why the instructions explicitly state to set it to "no" on registration..
I can live with the fields showing up twice temporarily, but did not read from your previous message that you were able to recreate the issue and accepted it as bug.