URL changes to using port when accessing wp-admin

Issue Summary

Accessing the frontend works fine, but any access of wp-admin adds a port into the url: https://site.local:10079/wp-admin/. What causes this, and how to fix permanently? I know I can switch to using localhost as the URL; that is not ideal, so please do not mention unless a step in fixing the issue.

Troubleshooting Questions

  • Does this happen for all sites in Local, or just one in particular? Occurs every time I’ve created a new site in the recent months.

  • Are you able to create a new, plain WordPress site in Local and access it in a Browser? Yes

Replication

Describe the steps that others can take to replicate this issue. If you have screenshots that can help clarify what is happening, please include them!

  1. Create a new site: PHP 7.4, Apache, Mysql 5.7.28
  2. Trust SSL
  3. Access wp-admin directly through browser

System Details

  • Which version of Local is being used? 5.10.1+5267

  • What Operating System (OS) and OS version is being used? macOS 11.2.3

  • Attach the Local Log. local-lightning.log (10.6 KB)

I’m seeing the same thing: URL shift and a browser warning that it cannot make a secure connection.

  • Local 5.10.3 on MacOS Mohave
  • PHP 7.3.5 and MySQL 8.10.6 (Preferred configuration)
  • Apache server

The problem seems only to occur when using Apache. But it’s intermittent. Sometimes I see it and sometimes I don’t. I was tearing my hair out yesterday until I traced it to Apache.

1 Like

Yes, it does appear to be limited to Apache. And I can also confirm its intermittent: if I attempt to access the admin after creating a site, I get redirect, but after restarting my machine I was able to access the admin without the redirect.

I suspect some sort of SSL bug with Apache…? Don’t know if that’s a thing, but that’s what it seems like…?

Either that, or perhaps the SSL issue arises because of the issue with the URL. Apache seems somehow to be redirecting the URL that I enter in the browser.

I’m sorry you are running into this issue!

I’ve tried to replicate on my macOS Catalina machine (macOS 10.15.7) but wasn’t able to get that behavior that you mention.

A couple of things to come to mind:

Do you have the latest version of the Apache Lightning service? Making the update process for Lightning Services easier is something we are wanting to do, but this FAQ has the info to get you going:

For reference, here’s a screenshot of the versions that I have installed under my 5.10.3 version of Local.

The other thing that comes to mind is about the SSL piece of this. Are either of you using a plugin or some sort of way of “forcing SSL?”

Lastly, what browser are you using? I’m doing this QA under the latest version of Chrome, but are either of you using Firefox or something else?

1 Like

I’ll try to force a reinstall of Apache Lightning Service; I am not forcing SSL AFAIK (just the WordPress URLs) and I experience using Brave, though IIRC I’ve also experienced using Chrome.

@ben.turner Removed Apache 2.4.43+6 Lightning Service and re-downloaded following the steps provided; issue persisted with a new install.

After reinstalling the Apache Lightning Service, I created the following sites and tested various setups; results:

The redirect occurs regardless if the SSL is trusted or not. If the WordPress Address is changed, then you can no longer access the admin (without changing the URL back).

1 Like

It seems to be browser independent. I’m seeing it in Chrome and also in Firefox.

Can either of you record a screencast so I can look and see what other things are happening when the issue happens?

Also, there’s a new version of Local that was just released. I don’t think it has anything that would fix this specifically, but it might be worth a try to see if updating helps:

@ben.turner I’ve described everything that I do… is there something specific you’d be looking for?

Screen recording below:

Screenshot of Local (5.10.4+5377):

Nice! Thanks for the screencast!

That specific error:

ERR_SSL_PROTOCOL_ERROR

Is a tricky one to zero in on. @crstauf – When you encounter this issue, do you have the same error?

In a general sense, this is the browser telling you that it doesn’t like the certificate. This is a very vague message, some of the items in this page would be good to try (though it’s for windows)

To summarize the ones I’d try under Mac:

  1. Check the date/time of your system. Consider having it set from a server so that everything is in sync.
  2. Clear the browser cache in case on older version of the certificate is present.
  3. Any antivirus software installed that might be messing with the local site’s certificate?
  4. In a similar fashion, any VPNs installed? I know that Local is offline software, but depending on the vpn, that might hijack and mess with the SSL certificate.

Let me know if any of those help or lead you to a solution!

Mostly wanting the exact error messages seen as well as a better idea for the context of where a request started and where you end up.

When you encounter this issue, do you have the same error?

Yes, mentioned in a previous comment.

To summarize the ones I’d try under Mac:

  1. Already in place
  2. Receive same error in incognito
  3. Nothing beyond macOS
  4. Yes, I have Cloudflare WARP installed and setup with Cloudflare Teams

Is it the SSL issue that’s causing the URL issue – or is it the other way around?

It’s not clear to me why the port is appearing in the URL. Is there a mechanism by which an SSL certificate problem could cause that? I’ve never seen it anywhere else.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.

I’m sorry for leaving this topic dangling, but I was mostly at a loss for what might be causing this.

I think that this is a related issue to another topic where not including the trailing slash under apache causes the issue:

Maybe neither ? :skull:

I think that what’s happening is that because Local’s router (which is basically a proxy) is running nginx, but the end site is running Apache, there’s something incorrect with how the two services are communicating.

In the above reply I linked to, I recorded my QA session and at around the 2:00 min mark and the 5:20 min mark, I get odd HTTP response codes for the various URLs. For example, as a logged out user, trying to access the wp-admin, I think there should be a 302 response to the wp-login.php page but instead there are 200 responses.

For the Apache site, it just breaks but for some reason nginx fails gracefully and shows the site.

I’ve filed a bug with the Local team, but I don’t have an ETA for when it will be worked.

I’ve been running into this issue as well.

Here’s what I am seeing, again, specific to apache like other accounts:

https://mysite.local/wp-admin/  

That redirects ok)

https://mysite.local/wp-admin  

That redirects to https://mysite.local:10003/wp-admin/ (note the trailing slash now) and results in ERR_SSL_PROTOCOL_ERROR

I also noticed this when I was using some custom redirects from files that used to be in root folders, in a legacy site. These redirects caused the ERR_SSL_PROTOCOL_ERROR :slight_smile:

RewriteRule ^js/(.*)$ /wp-content/js/$1 [R=302,NC,L]
RewriteRule ^css/(.*)$ /wp-content/css/$1 [R=302,NC,L]
RewriteRule ^enterprise/(.*)$ /wp-content/enterprise/$1 [R=302,NC,L]
RewriteRule ^images/(.*)$ /wp-content/images/$1 [R=302,NC,L]
RewriteRule ^svg/(.*)$ /wp-content/svg/$1 [R=302,NC,L]
RewriteRule ^fonts/(.*)$ /wp-content/fonts/$1 [R=302,NC,L]

However, when I changed them as follows, they did not:

RewriteRule ^js/(.*)$ https://%{HTTP_HOST}%/wp-content/js/$1 [R=302,NC,L]
RewriteRule ^css/(.*)$ https://%{HTTP_HOST}/wp-content/css/$1 [R=302,NC,L]
RewriteRule ^enterprise/(.*)$ https://%{HTTP_HOST}/wp-content/enterprise/$1 [R=302,NC,L]
RewriteRule ^images/(.*)$ https://%{HTTP_HOST}/wp-content/images/$1 [R=302,NC,L]
RewriteRule ^svg/(.*)$ https://%{HTTP_HOST}/wp-content/svg/$1 [R=302,NC,L]
RewriteRule ^fonts/(.*)$ https://%{HTTP_HOST}/wp-content/fonts/$1 [R=302,NC,L]

I’m pretty sure it has something to do with the nginx proxy that the LocalWP software is using, and how it is handling the WordPress redirects, but I am at a loss to be able to fix it…

Very annoying. Hoping this will help solve this (rather old) problem for everyone?

LocalWP…??

Bueller…???

.

@ben.turner Any progress? This is still an issue. I started experimenting with service workers which require an SSL, and now I can’t access my WordPress admin, even with nginx.