Make WordPress Core

Opened 6 years ago

Closed 5 years ago

Last modified 5 years ago

#45747 closed enhancement (fixed)

Deprecate update_user_status

Reported by: spacedmonkey's profile spacedmonkey Owned by: sergeybiryukov's profile SergeyBiryukov
Milestone: 5.3 Priority: normal
Severity: normal Version: 3.0
Component: Users Keywords: has-patch good-first-bug commit
Focuses: multisite Cc:

Description

Deprecate the function update_user_status and replace with wp_update_user.

Attachments (2)

45747.diff (5.5 KB) - added by spacedmonkey 6 years ago.
45747.2.diff (8.5 KB) - added by SergeyBiryukov 5 years ago.

Download all attachments as: .zip

Change History (13)

@spacedmonkey
6 years ago

#1 @SergeyBiryukov
5 years ago

Should we provide back compat for make_spam_user and make_ham_user actions?

wp_maybe_update_network_user_counts() is hooked to them.

#2 follow-up: @spacedmonkey
5 years ago

@SergeyBiryukov This patch does keep those actions. It move them to wp-includes/user.php

#3 in reply to: ↑ 2 @SergeyBiryukov
5 years ago

  • Milestone changed from Awaiting Review to 5.2
  • Owner set to SergeyBiryukov
  • Status changed from new to reviewing

Replying to spacedmonkey:

This patch does keep those actions. It move them to wp-includes/user.php

Ah, I missed that. Thanks!

#4 @SergeyBiryukov
5 years ago

  • Milestone changed from 5.2 to 5.3

Missed the 5.2 Beta 1 deadline, moving to 5.3.

#5 @SergeyBiryukov
5 years ago

  • Keywords commit added

I could not get 45747.diff to work: simply passing $userdata['spam'] to wp_update_user() does not save the value in the database if it's not specifically handled in the function.

45747.2.diff fixes that, updates the docs, and also changes make_spam_user and make_ham_user to fire after the update, as they do in update_user_status(), not before.

#6 @SergeyBiryukov
5 years ago

  • Resolution set to fixed
  • Status changed from reviewing to closed

In 45708:

Users: Deprecate update_user_status() in favor of wp_update_user().

Props spacedmonkey, SergeyBiryukov.
Fixes #45747.

#7 @SergeyBiryukov
5 years ago

In 45709:

Coding Standards: Fix WPCS violations after [45708].

See #45747.

#8 follow-up: @azaozz
5 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

On one single test site after [45708] trying to update a user profile fails with "Sorry, marking a user as spam is only supported on Multisite." error. Seems to be coming from:

    if ( isset( $userdata['spam'] ) && ! is_multisite() ) {
        return new WP_Error( 'no_spam', __( 'Sorry, marking a user as spam is only supported on Multisite.' ) );
    }

Seems the site was set to "multisite" at some point then changed back to "single". The user table has spam and deleted fields with '0' as default values.

Changing the above check to ! empty( $userdata['spam'] ) would fix it. Not sure how common that is, but probably better to fix?

Last edited 5 years ago by azaozz (previous) (diff)

#9 in reply to: ↑ 8 @SergeyBiryukov
5 years ago

Replying to azaozz:

Changing the above check to ! empty( $userdata['spam'] ) would fix it. Not sure how common that is, but probably better to fix?

Sure, good catch!

#10 @SergeyBiryukov
5 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

In 45874:

Users: Adjust [45708] to make sure wp_update_user() does not issue a WP_Error if a single site was previously set up as Multisite and there's still a spam field in the user table.

Add a unit test.

Props azaozz, SergeyBiryukov.
Fixes #45747.

#11 @SergeyBiryukov
5 years ago

In 46683:

Test: Don't skip the tests intended for single site when running on Multisite, add them to the ms-excluded group instead.

See #39776, #45747.

Note: See TracTickets for help on using tickets.