Editing customized profile fields deletes blog aliases
principessaDS - May 21, 2008 - 12:58
| Project: | Pathauto |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed |
Description
Similar to "saving profile removes blog url aliases" found for 6.x-1.x-dev, if you edit a customized profile field, the blog aliases are deleted due to the fact that $edit['roles'] is not set. Thus $new_user->roles is overwritten with an empty array first, then the authenticated user role is added back in.
To reproduce:
- Have pathauto blog & blog feed set up
- Set up customized profile field under admin/user/profile/add/[fieldtype]
- Edit user's customized profile field & hit save
- Confirm blog & blog feed aliases have been deleted
So far the following quick fix seems to work for me, both in editing current users & creating new ones with/out blogging permission, but the authors may wish to do this in a different/better manner:
Replace lines 730-732 in pathauto.module
$new_user = $user;
$new_user->roles = isset($edit['roles']) ? $edit['roles'] : array();
$new_user->roles[DRUPAL_AUTHENTICATED_RID] = 'authenticated user'; // Add this backwith
$new_user = $user;
if($category == 'account'){
$new_user->roles = isset($edit['roles']) ? $edit['roles'] : array();
$new_user->roles[DRUPAL_AUTHENTICATED_RID] = 'authenticated user'; // Add this back
}Apologies in advance if I somehow missed a similar report for 5.x.2-2 when searching the issues queue.
#1
This makes sense to me - can you submit it as a patch?
#2
Patch made with Cygwin - let me know if there are any problems.
#3
Thanks for submitting this as a patch.
There are two more steps to repeat this consistently:
1) The bug doesn't show up for uid1 ever
2) The bug doesn't show up if the authenticated user role has the ability to create roles
Your patch fixed it for me. I updated it for 6.x and also changed it to fit with the coding standards: http://drupal.org/coding-standards
If Freso has an opinion on this then we can wait for that, but otherwise I think it's RTBC.
#4
@greggles: If you've tested it and it works, go ahead and commit it. I don't see anything wrong with it. :) Is it tested under 5.x though? If not, it should probably be tested there as well and backported if the bug should live on there.
#5
Committed to 6.x - thanks principessaDS!
Now to port...
#6
And committed to 5.x as well.
#7
Automatically closed -- issue fixed for two weeks with no activity.