WordPress.org

Make WordPress Core

Opened 20 months ago

Closed 12 months ago

Last modified 9 months ago

#45747 closed enhancement (fixed)

Deprecate update_user_status

Reported by: spacedmonkey Owned by: 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 20 months ago.
45747.2.diff (8.5 KB) - added by SergeyBiryukov 12 months ago.

Download all attachments as: .zip

Change History (13)

@spacedmonkey
20 months ago

#1 @SergeyBiryukov
17 months 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
17 months ago

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

#3 in reply to: ↑ 2 @SergeyBiryukov
17 months 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
17 months ago

  • Milestone changed from 5.2 to 5.3

Missed the 5.2 Beta 1 deadline, moving to 5.3.

#5 @SergeyBiryukov
12 months 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
12 months 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
12 months ago

In 45709:

Coding Standards: Fix WPCS violations after [45708].

See #45747.

#8 follow-up: @azaozz
12 months 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 12 months ago by azaozz (previous) (diff)

#9 in reply to: ↑ 8 @SergeyBiryukov
12 months 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
12 months 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
9 months 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.