Login can be blocked if primary_blog is set to a blog the user no longer belongs to that is marked as spam

[westi]

We block logins for user who's primary blog is marked as spam (for historical reasons).

We don't actually check that the user is still a member of the spam blog before blocking the log in.

Which is confusing when you try and work out why they are unable to log in.

[westi]

Fix

[nacin]

I thought we had mostly eliminated primary_blog along with the user dashboard. I guess not — but it feels like that should go into the trash too.

Patch looks good.

[martythornley]

Adds filter 'wp_authenticate_user_for_blog'

[martythornley]

Added a new filter 'wp_authenticate_user_for_blog' to check or not check against user's primary blog.

[brianhogg]

Removes check for user blog as spam when logging in, adds replacement filter

[brianhogg]

The patch also updates the is_user_spammy() function to take a user object, to avoid having a hard-coded 1 == $user->spam check, if that should be in a separate patch let me know.

[nacin]

Related: #19714 and #20774.

[nacin]

In 24848:

Remove "special" multisite spam check in the authentication API.

The spamming of a site no longer directly affects a user of said site.

Moves the spam check to the wp_authenticate filter. Networks in need
of enhanced spam-fighting should leverage this same technique.

Allow is_user_spammy() to accept a WP_User object.

props willnorris, brianhogg.
fixes #24771. see #19714.

[brianhogg]

How does updating the codex for a future feature/change work - do we add an update before it's released or queue it somehow for after?

[DrewAPicture]

Replying to brianhogg:

How does updating the codex for a future feature/change work - do we add an update before it's released or queue it somehow for after?

Sometimes we edit it whenever the change is made, and sometimes we just mark needs-codex for future reference when we do the codex sprint for a new release.

When the new Code Reference is in place and auto-parsing docblocks in the source, there will be less/no need for adding the needs-codex keyword and more emphasis on providing complete inline documentation.

So in the case of this ticket, we would wait, though I anticipate the Code Reference will be in place (hopefully) before we do the 3.7 codex sprint.