#23358 closed defect (bug) (fixed)
Switch to a usermeta key for email confirmation in Multisite
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | 4.5 | Priority: | normal |
Severity: | normal | Version: | 3.0 |
Component: | Options, Meta APIs | Keywords: | has-patch 2nd-opinion |
Focuses: | multisite | Cc: |
Description
Background: #23146
In send_confirmation_on_profile_email()
, an option is used to store the new email:
http://core.trac.wordpress.org/browser/tags/3.5.1/wp-admin/includes/ms.php#L238
A usermeta key should be used instead.
Attachments (6)
Change History (24)
#4
@
11 years ago
Mike's patch works well. 23358.diff adds some back-compat code to make sure that initiated e-mail changes before an upgrade are not broken.
#6
@
11 years ago
- Keywords needs-testing removed
23358.2.diff is a refresh against current trunk. Tested the move from *_option()
to *_user_meta()
and all appears to be working as intended at the DB level.
#7
@
11 years ago
- Milestone changed from 3.7 to Future Release
This has been like this for a long time. Rather than mess with this for now, let's do this earlier in a cycle.
#10
@
9 years ago
- Keywords needs-refresh removed
This applied correctly for mike. I might have forgotten to remove changes at the bottom of user.php from an earlier patch.
#11
@
9 years ago
- Milestone changed from Future Release to 4.5
- Owner set to ocean90
- Status changed from new to accepted
#12
@
9 years ago
What are your thoughts on an upgrade routine instead of _user_new_email_compat()
? With SELECT * FROM {$wpdb->options} WHERE option_name REGEXP '[0-9]+_new_email';
we could fetch all existing options.
#13
@
9 years ago
- Keywords 2nd-opinion added; early removed
Attached 23358.5.diff:
- IMO we don't have to provide a compat layer for the switch to user meta. It's unlikely that users whose options are still in the database are still interested in changing their email.
- But in case a user still wants to change their mail with an old key I've added an error message "Error while saving the new email. Please try again.".
- Something for another ticket: Shouldn't the email change links expire like password reset links, see [33019]?
Thoughts?
Related: mu:1581