Strange URL link under Master Cache Purge
-
Hi, using this plugin on many sites, working great. Have an unusual problem on two sites; one of which was duplicated from the other. Clicking the Master Cache Purge link in the admin toolbar goes to a “This site can’t be reached” error page, and the URL is: http://0.0.0.1/?the_purge=true.
Have tried deactivating all other plugins, uninstalling/reinstalling Master Cache Purge, no change. I assume it isn’t reading the site’s URL for some reason.
Any advice?
-
That’s weird… that URL actually gets the URI from server variables:
$_uri = sanitize_url( isset( $_SERVER['REQUEST_URI'] ) ?? '' );So… something in your browser or request is forcing that server variable to
0.0.0.1Now… because that is set, on your end, I would not even be able to fix it in the plugin to utilize something like:
$_uri= get_admin_url(null, $_SERVER['REQUEST_URI']);because the URL would end up like this:http(s)://yoursite.ext/wp-admin/0.0.0.1/?the_purge=trueAre you behind a proxy? Are you connected to a VPN? Is your network interfaces configured properly?
Only thing I can say, is maybe try a different browser… disconnect from your VPN/proxy…
Keep me posted
Searched around for some other solutions… looks like this is either an issue at your hosting provider not being configured properly, or your browser is modifying it.
PHP returning
0.0.0.1for$_SERVER['REQUEST_URI']usually indicates a misconfiguration in how the web server (like IIS or Apache) passes data to PHP, often misinterpreting it as an IP address or failing to populate the variable. It is frequently caused by encoded characters in the URL or issues with FastCGI settings.Potential Solutions and Troubleshooting:
- Check Server Configuration: Ensure your web server (Apache/IIS) is correctly configured to pass the requested URI to PHP. If using IIS, this might be a known FastCGI issue with special characters.
- Use Alternatives: If
$_SERVER['REQUEST_URI']is failing, try alternatives to construct the URL, such as$_SERVER['SCRIPT_NAME']combined with$_SERVER['PATH_INFO']or$_SERVER['QUERY_STRING']. - Debug PHP Environment: Use
phpinfo();to inspect all$_SERVERvariables and check ifREQUEST_URIis present and what its actual value is. - Check URL Encoding: Ensure the URL being requested does not contain invalid UTF-8 characters that could break the parsing.
Hi Kevin,
Thanks for your extensive research on this, much appreciated. The service we’re using is called GoHighLevel or just High Level. Their server is locked down in many ways, can’t do much configuring or testing at the server level. I know they use rocket.net as their CDN, otherwise don’t know much about their core configuration. I’ll try phpinfo() to see what I can find.
We have this same configuration with many other sites without problem so maybe there’s something wrong with the server setup.
-
This reply was modified 2 months, 3 weeks ago by
mquiggeorgia.
Update: I know for certain that the issue is with the GoHighLevel platform. Have spot-checked other GHL sites and they now have the same bad link. Checked sites on our other platform Hostinger and they are all fine. Haven’t gotten to
phpinfo()yet though.Appreciate the look out. Hopefully they will be able to correct it for you.
Not likely; their tech support is extremely slow and tedious. Might take weeks even to get a response. I do have the
_SERVERvariables fromphpinfo()if you’re interested. Would prefer to send another way than on this forum though.So
$_SERVER['REQUEST_URI']is correct fromphpinfo(), not connected to VPN… but I did discover that the problem is only on my desktop work computer — not laptop on the same network. Consistent across various browsers, incognito and not. Why it only occurs only on desktop, and only with websites hosted on the GHL platform, is a mystery. So I’ll troubleshoot further myself, again appreciate your help and you can close this ticket.-
This reply was modified 2 months, 3 weeks ago by
mquiggeorgia.
Hello again, Kevin… sorry to keep this going but thought you would want to know: not just an issue on my desktop, and not just an issue on GHL servers. Found at least one Hostinger site with same result. However, not consistent on Hostinger; it seems that some sites work fine. Also, a co-worker is experiencing the same
http://0.0.0.1issue. Haven’t asked her about VPN but I will.-
This reply was modified 2 months, 3 weeks ago by
mquiggeorgia.
-
This reply was modified 2 months, 3 weeks ago by
mquiggeorgia.
@mquiggeorgia I am posting an update today that may help with this. It’s a pretty large update so it’s taking a hot minute to post to the repos, but it should be up within the hour
@kevp75 That is excellent, thank you much! I’ll deploy it to our sites tonight.
@kevp75 PROBLEM SOLVED. Thank you sir for taking care of this!
@mquiggeorgia great to “hear”. glad its working out 🙂
You must be logged in to reply to this topic.