-
- 24,544 Posts
I suspect that UpdateProfile does just what its name suggests -- update the user's modUserProfile object. The username and password are part of the modUser object.
You might be able to write a postHook that would update the username.
-
- 708 Posts
Ah, I see. I didn't realize they were separate things.
Is there another way to allow users to update their username from the front-end?
Todd
discuss.answer
-
- 24,544 Posts
I don't know of one. I think it would take a custom snippet, though it might be possible to use a custom postHook with UpdateProfile.
The hook would look something like this (untested):
$submittedName = $hook->getValue('username');
if ( (!empty($submittedName) ) && ($submittedName !== $modx->user->get('username') ) ) {
$modx->user->set('username', trim($submittedName) );
$modx->user->save();
}
-
- 708 Posts
Thanks Bob, I'll try your example and let you know.
Going back to your first reply about modUser and modUserProfile, is there a specific reason why two different objects would be used for the user profile? Could it be a security thing?
Not knowing how or why MODX was designed the way it is it seems, with my limited understanding, that the user profile info would all fall under the same umbrella (object), so to speak.
Todd
-
- 708 Posts
Once again Bob you've knocked it out of the park. Your snippet works a treat.
Thank you.
Todd
-
- 1,154 Posts
This seems strange, one workaround would be to let them modify the users fullname, which can definitely be changed, in fact its in the sample updateprofile snippet in the docs. And indeed username is not one of the values provided.
I don't know what your site looks like but when you build pages you can let users be identified by fullname rather than username and then the lack of changing would be less serious.
Eko, I think the honest answer is that Modx doesn't really deal with user issues, its one of the gaps in the system. Even the extended profile in a JSON is probably not optimal. Keep in mind a lot of sites don't need users at all.
However there are tools like BobRay's classExtender that solve these problems pretty easily. Remember Modx is supposed to be a contained system, where ALL customization should happen outside that core, never hack the core because you can always modify an extra, snippet or other tool. So its supposed to be compact.
If it handled these issues, it would be great, but what would happen when you didn't like those default behaviors?
So, users are an extra module by necessary. Doesn't make it easier to climb that hill, though. But, most of the tools we need are out there.
[ed. note: nuan88 last edited this post 5 years, 11 months ago.]
-
- 708 Posts
Hi nuan88,
Users are identified by their first name, not their full name or username.
Thanks for your explanation and yes, I see your point. There often seems to be at least one solution to any problem.
Todd
-
- 24,544 Posts
I'm glad (and a little surprised) that the snippet worked out of the box.
I don't really know the thinking behind the separation of the modUser and modUserProfile object into separate objects in two different tables. It may be speed-related, since the modUser object is quite small. Also, given a user ID, you can pull either the modUser object or the modUserProfile independently, depending on what you need. If you have a user ID you can get the user's email, for example, without retrieving the modUser object since the modUserProfile contains the user ID in its internalKey field.
Another possibility is that in the very early Etomite days, the modUser object was all there was. When they realized that people needed more user information in the DB, they created a separate table for the extra data rather than modifying the modUser object, and included the extended field so that you could put whatever you needed into the user profile.
For info on what's where:
modUser:
https://bobsguides.com/modx-object-quick-reference.html#modUser
modUserProfile:
https://bobsguides.com/modx-object-quick-reference.html#modUserProfile
