Whenever a password is made that contains the symbol “^”, a major bug occurs. First it wont let you log in, to wp-admin, as it says the password is incorrect.
Checking the MySQL Adminer, the password is completely NOT what was set during the site creation process. For some reason local creates its own random password.
See the video https://youtu.be/Wz35QBkcwzw where i show th eissue occur. Also what i didnt record is that i actually try the random password it gives, but that too doesnt not work either, even though its in the database.
I also tried to then change and save the password i used during the creation process to the database, restarted the site and tried again to login. Still doesnt work
So all in all, if “^” is used in the password, then you simply cannot log in no matter what you try.
I then tried the exact same password, but simply replacing ^ with a number and it all worked 100%.
You’re right that this is likely a bug, but there’s a low likelihood that this can be fixed.
One thing to note before diving too far into this – the password that you see within the database will always be different than the one that’s used to create the site. This is because WordPress doesn’t save the raw password within the DB, it saves a hashed string of the password. This is a security best practice and is pretty common in various projects.
As for why this bug is happening within Local: from the screenshot, it looks like this computer is a Windows computer. I just tried to create a site under MacOS with a password that contains a caret and am able to log into the site.
What’s probably happening is that when Local creates the new site, the Window’s shell isn’t correctly escaping the caret. If you really do require a password that contains a caret, then you can always create a site with a simple password and then update the password to something more secure from within the WP Admin since that won’t be using the non-posix compliant Windows shell.
Hope that helps clarify things and thanks for taking the time to explore Local!
Hey ben, thanks for the reply. Yeah figured it was something weird happening during the creation process. Not a big deal, as I easily make a PW without the carrt, just thought id note it here in case someone else runs into the issue.
Didn’t know that the PW in the MySQL wasn’t the same as the Wordpress admin PW, so learnt something as well. Confusing as the Username right above it is the admin username, so assumed the two were linked.
I had this issue on both Windows 8.1 & Windows 11.
In my case I wanted to use the password of an existing site which contains the symbol “^” so everyting worked the same through my password manager when the database from the existing site is imported.