Skip to:
Content

Opened 20 months ago

Last modified 12 months ago

#3144 new enhancement

User Import: Update existing users instead of inserting as new

Reported by: jrf Owned by: johnjamesjacoby
Milestone: 2.8 Priority: normal
Severity: normal Version: trunk
Component: API - Importers Keywords: has-patch needs-testing 2nd-opinion
Cc: johnjamesjacoby, wordpress_nospam@…

Description

If a user is being imported with the same user name and email address as an existing user in the WP install, we can safely presume it is the same user and update the user account instead of inserting a new one.

Patch included.

The second patch build onto the first: If a user name changes during the import because of the WP user name sanitization, use the original user name as the display name for the user if none was set previously.

Attachments (2)

trac-3144-1-user-import-update-existing-user.patch (1.7 KB) - added by jrf 20 months ago.
Update existing user instead of importing as new
trac-3144-2-user-import-set-display-name-to-original.patch (2.2 KB) - added by jrf 20 months ago.
Use original username as display name

Download all attachments as: .zip

Change History (6)

@jrf
20 months ago

Update existing user instead of importing as new

@jrf
20 months ago

Use original username as display name

#1 @johnjamesjacoby
20 months ago

Historically, the reason we haven't overwritten existing users is because of how common usernames like "admin" are across platforms, and the general risk of blowing away the current user's account mid-migration.

Do we special-case these? Or maybe check that the user being overwritten is not the currently logged in user?

#2 @johnjamesjacoby
20 months ago

  • Keywords needs-testing 2nd-opinion reporter-feedback added
  • Milestone changed from Awaiting Review to 2.7
  • Owner set to johnjamesjacoby

#3 @jrf
20 months ago

  • Cc wordpress_nospam@… added
  • Keywords reporter-feedback removed
  • Milestone changed from 2.7 to Awaiting Review

Historically, the reason we haven't overwritten existing users is because of how common usernames like "admin" are across platforms, and the general risk of blowing away the current user's account mid-migration.

Do we special-case these? Or maybe check that the user being overwritten is not the currently logged in user?

Good point. The problem that creates, of course, is that all users who had accounts on the WP site and the external forum site would now have two accounts and that posts would not be correctly assigned to them.

That also goes for the admin user. Note: in the patch, I've set it up so that *both* the username as well as the email address have to match before a user is recognized as the same user.

We could choose to exclude the current user from this. That would be easy enough, but if that user was a (power-)user on the external forum, the problem would remain.

Maybe more differentiation is needed in what data is updated ?
As in, prevent passwords from being changed and prevent overwriting existing user data ?

#4 @johnjamesjacoby
12 months ago

  • Milestone changed from Awaiting Review to 2.8

Moving this into the 2.8 milestone.

Note: See TracTickets for help on using tickets.