Local incorrectly adds port number when logging into wp-admin of a site

[electricarts]

Hello,

the following behavior of Local is killing me: since I can’t set Firefox Developer as default browser in Local, I open WP Admin manually. Now when I enter https://testsite.test/wp-admin in FF, Local changes it to https://testsite.test:10084/wp-admin. I get an error message (Secure Connection Failed) and have to manually remove port 10084 to connect to the backend.

I remember reading here that this behavior (appending the port to the URL) was changed in an update. Or did I understand that wrong?

[ben.turner]

That sounds like maybe the url within the site’s database has been updated to include the port number.

First thing to check is if the Router Mode setting is set to “Site Domains” under “Preferences > Advanced.” That will ensure that Local can work without having to rely on specific site ports.

If that doesn’t work, then you’ll likely need to investigate what the URL is within the Database.

You can get an idea for what url is in the database by right-clicking on a site in Local and selecting “Open Site Shell”. Within the terminal that opens, run this command:

wp option get siteurl

From there, you can determine if you need to update the urls within the DB so that the port number isn’t included.

[electricarts]

Hey Ben,

Router Mode is set to “Site Domains”. When running the terminal command i get a error message:

Failed loading /Users/mario/Library/Application Support/Local/lightning-services/php-7.4.1+14/bin/darwin/lib/php/extensions/no-debug-non-zts-20190902/opcache.so:  dlopen(/Users/mario/Library/Application Support/Local/lightning-services/php-7.4.1+14/bin/darwin/lib/php/extensions/no-debug-non-zts-20190902/opcache.so, 9): no suitable image found.  Did find:
	/Users/mario/Library/Application Support/Local/lightning-services/php-7.4.1+14/bin/darwin/lib/php/extensions/no-debug-non-zts-20190902/opcache.so: code signature in (/Users/mario/Library/Application Support/Local/lightning-services/php-7.4.1+14/bin/darwin/lib/php/extensions/no-debug-non-zts-20190902/opcache.so) not valid for use in process using Library Validation: mapped file has no cdhash, completely unsigned? Code has to be at least ad-hoc signed.

What does it mean?
In which table in the database should I manually look for the “wrong” URL?

[ben.turner]

@electricarts

What does it mean?

That error message appears to be related to some security settings that we’ve seen under Macos.

• What version of Local is installed?
• What operating system are you using and what version of the OS is installed?

@electricarts

In which table in the database should I manually look for the “wrong” URL?

It’s probably easiest to use WP CLI to search for the URL within the database.

To do this, right-click on the site within Local and select “open site shell.” Within the terminal that opens run this command to search for the url:

wp db search testsite.test:10084

If that does find that URL within the database, then you can do a search and replace by issuing another command for wp-cli:

wp search-replace '/testsite.test:10084' '/testsite.test'

[electricarts]

Hey Ben,

this error message pops up when using the WP CLI command. So i can’t search for the URL in the database via WP CLI.

Local Version is 5.10.3+5332 and i’m using macOS 11.3.

[ben.turner]

Ahh, you’re right sorry I missed that. Since that error message relates to PHP 7.4.1, what happens if you use a different version of PHP?

You can either create a new blank site using the preferred environment or try changing the version of PHP from the site overview page.

[electricarts]

Ok. Changed the PHP version to 7.3.5 and the error is gone. Searched for the URL with the Port and got no result. There are only URLs without the Port in the DB.

What makes me wonder is that the behavior only occurs with FF Developer Edition. Any idea why this is happening?

[benjamin]

I have the same exact issue in Chrome. Happens about 80% of the time. I navigate to my site and it auto adds the port. I’ve never set anything in the DB with that port (search returns no results as well).

[electricarts]

@ben.turner

Could you please confirm that the behaviour is intentional or is this a bug?

I have now tried this again with a fresh page created in Local. I manually call up the admin area with https://abc.test/wp-admin and Local changes the URL to https://abc.test:10149/wp-admin/. This gives me an error message because of the certificate (URL of the certificate is no longer correct). Does this port have to be appended? This is killing me.

[ben.turner]

@electricarts

This gives me an error message because of the certificate

I think Firefox will always throw an error looking page because they don’t trust self-signed certificates. There isn’t anything that Local can do since this is a “feature” of Firefox.

@electricarts

Does this port have to be appended?

Appending the port isn’t something that should be happening unless Local has the Router Mode set to localhost.

I’ve been trying to replicate this behavior on my own machine and I haven’t been able to get Firefox Developer edition to redirect to that port.

Since you mention that changing to a different version of PHP fixes things, I wonder if Local needs to update the PHP 7.4.1 lightning service.

Can you try following the steps outlined in this FAQ and see if updating the PHP lightning service helps?

How can I manually update downloadable Lightning Services?

[electricarts]

Yes, FF is a bit bitchy. But the behaviour now also appears with other browsers. I have exactly the same problem in Safari and Brave.

Updating the services has not changed anything. I created a new page in Local as a test. Immediately after creating it, I tried to log in manually to the backend. And immediately after the login Local appends the port to the URL. Which is not a problem in http environments. But when calling via https, the problems occur. I have made a short video about this:

https://snaps.eacloud.de/local.mp4

[ben.turner]

I’m still not able to replicate this behavior on my machine running BigSur and Local 6.0. I recorded this screencast:

• Screen Recording 2021-07-19...

Which basically:

1. Create new site
2. Trust SSL cert in Local
3. Because I’m running BigSur, and it won’t allow Local to register the cert, I manually trust it in keychain (see this help doc for more info)
4. Try logging into wp-admin
5. noted that the initial login wasn’t over HTTPS, so manually re-log in over HTTPS

I’m really not sure where this is falling short on your machine, but there’s definitely something going on at a deeper level. If I were to guess, there’s some sort of configuration or setting WordPress is reading from when it gets that redirect url.

To be specific, when I go to the wp-admin url, I get redirected to the wp-login.php page with this url (note that my url doesn’t include the port number – does your redirect url include it?)

http://testing-ssl-login.local/wp-login.php?redirect_to=http%3A%2F%2Ftesting-ssl-login.local%2Fwp-admin%2F&reauth=1

[electricarts]

Hey @ben.turner,

my redirect doesn’t include the Port. https://test.test/wp-admin redirects to

http://test.test/wp-login.php?redirect_to=http%3A%2F%2Ftest.test%3A10154%2Fwp-admin%2F&reauth=1

Self-signed certificates have not only not worked since Big Sur, but at least since Catalina. I thought Local uses its own authority certificate (Root CA) to make the individual page certificates legal and accepted.

I don’t have to go into the keychain and manually set “Always Trust” for any Local page. Are you sure this is the way it has to be? I use Big Sur and don’t need to.

I just deleted all certificates in the keychain and then re-created the certificate for 5 sample pages in Local. So far the call works for these pages without port.

[ben.turner]

@electricarts

my redirect doesn’t include the Port.

I’m seeing the port number of 10154 in the url provided:

@electricarts

Self-signed certificates have not only not worked since Big Sur, but at least since Catalina

I don’t think that’s entirely true. I know that I’ve been using Local on macOS for a while now and have been able to use self-signed certs feature on High Sierra, Maverick, and Catalina. Firefox has definitely squacked about self-signed certs for a while now, but that’s not a Mac thing, it’s a FF thing.

@electricarts

I thought Local uses its own authority certificate (Root CA)

We don’t currently do this, but it is one possible solution that we’re considering.

@electricarts

re-created the certificate for 5 sample pages

Can you elaborate on this a little more? You should only have to trust a certificate once per domain. That certificate will be re-used for all pages on that specific domain.

---

Seeing that port number within the redirec_to portion of the url is interesting – it’s showing us that for whatever reason, WordPress thinks that it needs to include that in its redirect. I don’t think that WordPress does this out of the box, so I’m wondering if there are any plugins you are using, or other configuration options that are being used within the wp-config file that would be messing with what WordPress expects from the environment.

[electricarts]

@ben.turner

I’m seeing the port number of 10154 in the url provided:

Oh sorry! I am sooo blind!

@ben.turner

@electricarts

re-created the certificate for 5 sample pages

Can you elaborate on this a little more? You should only have to trust a certificate once per domain. That certificate will be re-used for all pages on that specific domain.

I have deleted all certificates in the keychain and then clicked again on “Trust” when starting the pages in Local. After clicking on “Trust” the certificates immediately appear in the keychain. Without having to confirm or set anything.

@ben.turner

@electricarts

Self-signed certificates have not only not worked since Big Sur, but at least since Catalina

I don’t think that’s entirely true. I know that I’ve been using Local on macOS for a while now and have been able to use self-signed certs feature on High Sierra, Maverick, and Catalina. Firefox has definitely squacked about self-signed certs for a while now, but that’s not a Mac thing, it’s a FF thing.

I have found online articles from 2016 where it is described how to get macOS X to accept self-signed certificates. Without manual trust in the keychain these certificates did not work.

But now to the most important point: After some testing I found out that when specifying the trailing slash the port number is not called. So, the call of https://test.test/wp-admin redirects with the port number. But the call of https://test.test/wp-admin/ redirects without port number!

I found an online article that describes a similar phenomenon:

[nginx - Port number being added to WordPress admin after Varnish install - Server Fault]

Does this help in any way?

Or will it help if I send you an export of an affected page from Local?

[ben.turner]

@electricarts

Or will it help if I send you an export of an affected page from Local?

Sure – if you’d like to export a site so I can take a look that would be helpful for replicating. I’m still not able to replicate and when I leave off the trailing slash, Local correctly redirects without the port number.

One thing I notice is that you keep mentioning “page” – Local and SSL certs with WordPress are associated with a domain. Is there some sort of custom setup that is being used (like a custom plugin, caching setting, or a WPmultisite), or are you using “page” and “site” interchangeably?

[electricarts]

@ben.turner

One thing I notice is that you keep mentioning “page” – Local and SSL certs with WordPress are associated with a domain. Is there some sort of custom setup that is being used (like a custom plugin, caching setting, or a WPmultisite), or are you using “page” and “site” interchangeably?

Attention! Ze Germans try to speak English. I mean site all the time.

Here is the the link to the exported site: [redacted]

[ben.turner]

Haha! Gotcha, I just wanted to make sure I wasn’t missing something

Thanks for passing along that site, it was really helpful to see an example and as a result, I think I have distilled the steps down for a reliable reproduction:

1. Create a new site in local

2. Trust the SSL cert for the site

3. Open a site shell and update the url within the DB to use the secure version of the url

   wp search-replace 'http://example.local' 'https://example.local'
   

4. Try to log into the WP-admin when the url does not have a trailing slash. So for example, using the above url, navigate to:

   http://example.local/wp-admin
   

   and not

   http://example.local/wp-admin/
   
   
   
   

Since this is such an odd issue, I recorded my QA session. Note that an Nginx site will handle the redirect correctly, but the Apache site will not:

• Screen Recording 2021-07-27...

I’ve created a bug within our internal bug tracker program, but I don’t have an ETA for when it will be fixed. As a workaround, I imagine you might be able to add an apache redirect at the site level and then restart the site.