error password

So the initial password you set as a new user does not work, but when you reset it, the new password does work? That’s strange because new and reset passwords utilize the exact same process.

It’s possible for security plugins to alter other files where the changes persist after the plugin is deactivated. You may need to refresh all the core files. Before doing that, let’s be sure there’s not something else at play. Deactivate all plugins and switch to a default twenty* theme. Test a new user now. If it still fails to work, try the Re-install version x.x.x button for core WP on the updates admin screen. Or update if that’s appropriate.

That button doesn’t always work reliably in refreshing files, but it’s much easier to use than manually refreshing files. If the re-install/update button resolves the problem, then great, otherwise proceed with the manual method.

Obtain a fresh WP download of whichever version you use. Then follow the manual “update” instructions, even though in using the same version you aren’t really updating.

Hello Bcworkz, thanks for your intervention again.

To be sure that the translation of my words is what I say, here is again the description of the problem encountered:
I create a new user. I click on the link in the activation email received, and I immediately enter the site where I can navigate perfectly. I disconnect, I enter my identifiers and there… “ERROR: The username or password you entered is incorrect”.

I deactivated all my plugins -one by one- I deleted my “ithemes security” plugin which offered 2FA and the problem disappeared. I put back a single plugin and there the anomaly started again.

So I contacted plugin support and explained the situation. So far no response.

With a different theme, the problem persists.
But I will still apply the solution you suggest and reinstall the WP core

• This reply was modified 1 year, 10 months ago by mand01.
• This reply was modified 1 year, 10 months ago by mand01.

I just did a manual WP update and the problem is still there.

How did you create the new user? Using the user registration form, or from the backend as admin? Either way, the new user wouldn’t normally be taken directly to the site from the email link. The email link should take them to a password reset form. If you set a password for the user as admin, it should work to login, but it is not disclosed to the user in the email, so they’d need to reset it in order for them to know their own password.

Thanks for trying the manual update method. Something is active that’s altering normal behavior. Have you tested this with no plugins active and using a default twenty* theme? Also check if there is a /wp-content/mu-plugins/ folder. If there is and it contains any files, they are active must-use plugins. Rename the folder to disable them.

I created the new user outside of the WP admin, using the user login form.

Yes, I deactivated all plugins, I activated a theme twenty.
There is no Mu folder

What is the email link for the new user? It’s supposed to be something like
https://example.com/wp-login.php?action=rp&key=2W3HakMa5akFCOfDgKFK&login=newusername

The wp-login.php?action=rp part should take them to the password reset form where they’d set their desired password. They shouldn’t be automatically logged in like you’ve described.

Yes ,it’s a same link.

I wonder if you have some stale cookies in your browser that’s confusing your testing efforts. If you are using a unique, never used before username as a test, then cookies wouldn’t be a factor. If you’ve reused a test name, they might be a factor.

That shouldn’t affect a wp-login.php?action=rp link in any case. Somehow in your case this link is being redirected. If you’ve refreshed all the core files and are testing in a default state, any redirect would have to be external to WP, such as a .htaccess rule. Is there anything in .htaccess related to redirecting or rewriting wp-login.php requests?

Salut bcworkz,
I regularly clear my browser cache, I used a new user test each time.
I specify that I never had problem of connection myself as admin.
As for the htaccess file, it is almost empty:

`# BEGIN WordPress
# Les directives (lignes) entre ??BEGIN WordPress?? et ??END WordPress?? sont générées
# dynamiquement, et doivent être modifiées uniquement via les filtres WordPress.
# Toute modification des directives situées entre ces marqueurs sera surchargée.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* – [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ – [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

# END WordPress

# Wordfence WAF
<Files “.user.ini”>
<IfModule mod_authz_core.c>
Require all denied
</IfModule>
<IfModule !mod_authz_core.c>
Order deny,allow
Deny from all
</IfModule>
</Files>

# END Wordfence WAF`

I have a feeling that the problem is in the wp-login.php file.

We presumably have the exact same wp-login.php, yet I cannot replicate the behavior that you’re experiencing. If you have a recent manual update, use no plugins and a default theme, you have the same installation that I’m testing with. Any aberrant behavior would thus have to external to WP, or there is some old code somewhere that didn’t get deleted or replaced during manual update.

It is likely that we have the same file.
I deleted the old wp-login.php to replace it with a new one directly from a complete wordpress file.
Result: still the same problem. So it’s not from the file in question.

Maybe try creating a new installation in a sub-folder? If the same behavior is observed, there’s something odd about your server configuration. If proper behavior is observed, there’s something odd about this specific installation. While it doesn’t directly resolve the problem, it narrows down where to look for it.

I know you properly manage your browser’s cookies and cache, but all the same maybe it’d be worth testing with a browser you don’t normally use, or even a computer you don’t normally use, if you have access to one. Or at least use incognito or safe mode. Just to eliminate possible client side causes, no matter how unlikely it is they’d be the culprit.

It’s an idea indeed, to create a WP subfolder.
I will see that.

I just did the recommended manipulation: I installed a WP in a subdomain and I find myself with the same connection anomaly.

I don’t understand.

You’re not the only one. Did you obtain a fresh download .zip from www.ads-software.com for the installation? We don’t want to replicate any strangeness related to your initial installation.

This is indicating something odd about the server configuration. But admin user being OK, the problem being with new users with lesser roles contraindicates a server issue. What if you created a new admin user? The initial admin user created during installation never does the email/set password process, it’s established through a different mechanism.

If you get aberrant behavior with a new admin user, then I lean strongly towards server configuration, though I cannot imagine how that could be. There’s nothing odd about your .htaccess. All the same, maybe try removing the WordFence portion. It’s the only thing non-standard that’s left and even though it’s in public root, it can influence sub-folders.