WordPress.org

Make WordPress Core

Opened 2 years ago

Closed 15 months ago

Last modified 13 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 2 years ago.
45747.2.diff (8.5 KB) - added by SergeyBiryukov 16 months ago.

Download all attachments as: .zip

Change History (13)

@spacedmonkey
2 years ago

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

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

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

  • Milestone changed from 5.2 to 5.3

Missed the 5.2 Beta 1 deadline, moving to 5.3.

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

In 45709:

Coding Standards: Fix WPCS violations after [45708].

See #45747.

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

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