Are you sure that doing this fixed the issue of the computer’s username having special characters in it?
I’m having trouble visualizing how granting additional permissions to the Local desktop would help with this bug.
Hello,
I think I still have the error described here with special characters. Can you confirm that this is not yet solved ?
We haven’t released any fix for this and due to how low-level this is, there’s not much we can do about it at this time.
1 Like
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.
I know that this is a very old thread and is something that is unresolved in Local.
We’re trying to update and streamline our communication around bug reporting and fixing issues in Local. Because of this, I’ve moved this topic into the “Bugs” category which allows it to be up-voted.
If this is a problem that affects you, please up-vote this topic by clicking the “Vote” button at the top of the page.
Creating the account with no special characters fixed it on Win 11 20000.318
Thank you
1 Like
Hello,
It has been two years since this bug was reported, any news on the issue? It is quite annoying…
Thanks,
1 Like
Site creation fails when there are certain special characters (at least ampersand “&” seems to be one of those characters, might be others as well) in the admin password defined during the setup process. I believe the characters should be escaped properly (by Local) to allow the use of strong passwords as they are completely valid when setting up a WP site normally outside Local automatic setup.
You can finish the setup after the error message by going to your .local URL and continuing the setup manually. You can even use the same Local-breaking password you first used when trying to set up the site and WP will have no problem using it.
Steps to reproduce
- Add a new site
- When asked, insert an admin password with special characters like ampersand (&), possibly also single quote (’) and backtick (`)
Environment Info
- Windows 10 21H2 (19044.1766)
- nginx, PHP 7.4.1, MySQL 8.0.16
- Local 6.4.0+5927 (but this has been a bug for quite some time now)
Hello there, @ooksanen! 
I followed your steps and was not able to reproduce what you are experiencing.
Local is now on 6.4.1 - have you tried updating? You can find the latest release here:
Let me know if that helps!
Sam 
Hi @sammunoz and thanks for your reply!
Unfortunately the problem persists even on 6.4.1. I tried to create a new site with following info:
Site name: Test
Local site domain: test.local (default)
Local site path: ~\Local Sites\test (default)
Enviroment: Preferred (same as in my original post)
WordPress username: admintest
WordPress password: 123& (tried with 123&456 too, just to be sure)
WordPress e-mail: dev-email@flywheel.local (default)
Multisite?: No (default)
And the end result was the same, an “Error Installing WordPress for [Site name]”:
I tried some other special characters too, like backtick and single quote which I suspected might interfere with SQL commands if not properly escaped, but those seemed to work fine so it seems that only “&” breaks the installation.
EDIT: For clarification, OS, PHP, MySQL etc. were all the same in my last test as in my original post, except for Local, which I updated to 6.4.1 as per your suggestion.
If I remove the ampersand from admin password, install finishes correctly with all the other info being the same.
1 Like
Hi @ooksanen - thank you for that information!
To clarify, it was the "&" that broke the installation, and without it, everything worked fine?
I tried to reproduce this using an "&" and it still created the site. I’m using MacOS - I wonder if this is a Windows issue?
Sam
Yes, that is correct. If I remove the ampersand from the password (i.e. insert a password without “&”), the installation finishes correctly.
Could well be that the different character encoding used on Mac and Windows is the underlying issue here. Also I’m based in a Nordic country, not in US, so I’m not sure if there’s even further character encoding differencies between systems to accomodate for our umlauts and whatnot. 
If it’s of any help, here’s what my system says about the character encoding (these are all default Windows installation settings):
IsSingleByte : True
BodyName : iso-8859-1
EncodingName : Western European (Windows)
HeaderName : Windows-1252
WebName : Windows-1252
WindowsCodePage : 1252
IsBrowserDisplay : True
IsBrowserSave : True
IsMailNewsDisplay : True
IsMailNewsSave : True
EncoderFallback : System.Text.InternalEncoderBestFitFallback
DecoderFallback : System.Text.InternalDecoderBestFitFallback
IsReadOnly : True
CodePage : 1252
Hope this gets resolved as I use a password generator to generate unique passwords everywhere and I’d rather not exclude & from the characters in use.
1 Like
Hi @ooksanen - this is such great feedback and information, thank you so much for sharing it all here and being so thorough.
Happy to have you in the Local community & I’ll be sure to pass this information along to the team.
You rock!
Sam
Hi, just letting you know that this bug still persists and site creation fails with an error if password contains “&”.
Hello @ooksanen -
Thank you, I’ll flag this with the Local engineering team.
With a password without that character & are you still able to move forward?
Sam
Yes @sammunoz, that’s correct.
If I have an ampersand in my password, the site install will fail with the error I posted above and the .local address will require me to do a manual WP installation (“Test Site” in the screenshot below). If I do a manual install, WP accepts my password with ampersand without any trouble, as expected.
If, however, I don’t have an ampersand in my password, the site will install without any problems (“Test Site 2” in the screenshot below).
Just re-tested this on the latest version, 6.7.0+6354.
1 Like
Hi there @ooksanen,
I checked in with the team and this issue is basically the same issue as this related bug:
Basically, Local uses wp-cli to help with creating WordPress sites. Because of how the Windows terminal handles special characters, there are a number of things that break when special characters are used for things like usernames, and in this case, passwords.
This is a pretty hard bug to fix, so I don’t have any estimate for when this might be worked on or if it’s even possible to fix. But if you really need special characters in the password, you can always change the password with the WP admin. Updating the password in the wp-admin works because it doesn’t rely on the Windows terminal to interact with the site.
Hope that helps clarify this bug and gives you a workaround for more complex passwords!
Best,
Sam
1 Like