Site cannot be reached (localhost) with original site with different domain/port

Support
1

access.log (16.3 KB)
error.log (778 Bytes)

Issue Summary

I have about 7 perfectly working sites (Apache and Nginx); one will always fail, consistently, when attempting to run any page other than the static home page. Reviewed, extensively, all JSON and conf files.

Troubleshooting Questions

  • Does this happen for all sites in Local, or just one in particular?

Just one. The only visible difference is this: the “working” instance (which I don’t trust due to weird domain) has a different setup in sites.json. Notably, domain name and folder name pattern is different than all other sites. When the non-home page fails, it is attempting to reach localhost:10004/home - the http for the “working” instance. The calling instance (a brand new test import to Local on a Mac from db dump and files) shows 100028 with sites.json. Something is causing it look for the wrong instance.

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

Replication

Ok. I reviewed every file (especially conf files) I could think of down in Mac Application Support within Library. All seem fine and to follow the same basic patterns for the two main webservers (Apache, Nginx). The only suspect one is in sites.json where there is a difference between the domain name and the runtime structures. Example: the weird one has a screen name like “dev-sample” and a domain like “sample” (it should be “devsample”). The weird one also has an unusual folder name of “dev-sample” instead of “devsample”. Attempts to fix the problem by doing a raw import (db dump and file zip via BackWPUp) still has the problem of running only the home page. The import looks perfect except when it fails it is looking for the wrong http route. Nothing weird in the proxies I can see (Network, Advanced). Something is buried inside the weird but working instance. So when I import to a new local instance it has the same issues. I am attaching the access and error logs for this brand new (but not working) instance. It is clean except for the immediate failure as described.

Steps I did with brand new instance. (1) Created from source files as described. (2) entered instance. (3) ran static home page - visible (4) ran menu item to call another page. Failure at this point as it now is looking for the wrong http number (10004 instead of 10028)

System Details

  • Which version of Local is being used?
    6.3.0+5756

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

    • For example: macOS Catalina or Windows 10 Professional
      Catalina
      Sorry about the double log upload (I thought the upload had failed)

access.log (16.3 KB)
error.log (778 Bytes)

Security Reminder

Local does a pretty good job of scrubbing private info from the logs and the errors it produces, however there’s always the possibility that something private can come through. Because these are public forums, always review the screenshots you are sharing to make sure there isn’t private info like passwords being displayed.

2

This is now fixed by author.

I am the problem (not Local). Within sites.json (Mac OS - Library/Application Support/Local) I had an incorrect setting. This arose from me mucking about with the source files (copy and rename of folders - that sort of thing). What happened is that 2 of the instances that appear on the main Local Screen (the “site name”) were essentially duplicates. HOWEVER, the problem child had a different set of Local assignments for HTTP. Local had tried to sort my mess out (A Moody Blues Problem - Not in Your Wildest Dreams would the coders ever think of what I had come up with) with reasonable attempts at a JSON file for the instance. Anyway, I did a check of where Local had used a specific HTTP assignment (10004 in my case) and sure enough it was in use elsewhere within the instance (hbs files etc).

The fix was simple. I had to edit the sites.json file so it followed the naming pattern of a standard Local instance. Example - get rid of a “-” in the name of the folder and reset my domain name to be in agreement with normal conventions. domainname.local.

It’s working fine now. Documented for anyone else listening to Moody Blues while working on sites and not paying attention.

1 Like
3

@msunny010101 Ha, thank you for the laugh! The joys of chasing down those elusive errors… I’m glad to hear you were able to get things into a working state again.

4

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