Make WordPress Core

Opened 13 years ago

Closed 8 years ago

#15115 closed defect (bug) (fixed)

if filter show_password_field is set to false, you cannot add new users

Reported by: pampfelimetten's profile pampfelimetten Owned by: wonderboymusic's profile wonderboymusic
Milestone: 4.4 Priority: normal
Severity: minor Version: 3.0.1
Component: Users Keywords: has-patch
Focuses: Cc:

Description

Steps to reproduce:

  1. add_filter('show_password_fields', false);
  1. Try to add a new user, after entering the data you get the error message "ERROR: Please enter your password.".

Attachments (1)

15115.diff (1.2 KB) - added by coffee2code 13 years ago.
Aforementioned patch.

Download all attachments as: .zip

Change History (9)

#1 @coffee2code
13 years ago

  • Keywords has-patch added
  • Severity changed from major to minor

This is true. As the OP states, disabling display of password fields via

add_filter( 'show_password_fields', '__return_false' );

causes the password fields not to be shown on the user creation admin form (http://example.com/wp-admin/user-new.php).

My understanding of the filter's purpose is to make it possible to prevent users from using the profile form to change their password. This situation is indeed covered by the application of this filter in wp-admin/user-edit.php. The application of this filter in wp-admin/user-new.php does not seem appropriate (no sense in creating a user if you can't supply their password).

Attached is a patch, 15115.diff, which removes the filter from the user creation form.

Relatedly (though separate ticket at best): should those with create_users capability not have this filter applied to them at all? That way admins would always be able to edit user passwords. (Of course, this could be implemented via a plugin or the code adding the filter in the first place.)

@coffee2code
13 years ago

Aforementioned patch.

#2 @pampfelimetten
13 years ago

Well, I've discovered the bug because I wanted to use the filter, and there are scenarios where it can be useful. Removing it wasn't my intent at all, I'd rather like to see it improved.

What I want to do: We have a pretty big cms-like installation with 1000s of users. There is an intermediate management level called stationmanagers between the admins and authors. They can add new users to their station. But to keep it as simple as possible, we want to autogenerate the password which is sent to the new user, so we want to disable the password input field for the stationmanagers.

Maybe it would be a good idea to use different filters for users-new.php and user-edit.php? And of course fix the issue that using the filter prevents the user-new to function at all, as I've described in the ticket description.

Last edited 13 years ago by pampfelimetten (previous) (diff)

#3 @mdawaffe
13 years ago

  • Milestone changed from Awaiting Review to Future Release

+1 on 15115.diff

Agreed it's confusing. Workaround for now would be to roll a better plugin than __return_false().

#4 @chriscct7
9 years ago

  • Keywords dev-feedback added

I agree, the filter applying on new user makes no sense. Adding for core review

#5 @wonderboymusic
8 years ago

  • Keywords dev-feedback removed
  • Milestone changed from Future Release to 4.4

#6 @wonderboymusic
8 years ago

  • Owner set to wonderboymusic
  • Resolution set to fixed
  • Status changed from new to closed

In 34582:

Profile: on user-new.php, don't allow the password fields to be hidden. When hidden, you can't add a user.

Props coffee2code.
Fixes #15115.

#7 @DrewAPicture
8 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

There was a duplicate of this hook in user-edit.php. We need to move the hook doc since the original was removed in [34582].

#8 @DrewAPicture
8 years ago

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

In 34590:

Docs: Relocate the hook doc for the show_password_fields filter to its duplicate, since the original was removed in [34582].

Adds a changelog entry noting the adjustment in behavior, and simplifies the conditional logic.

Fixes #15115.

Note: See TracTickets for help on using tickets.