• Resolved mquiggeorgia

    (@mquiggeorgia)


    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?

Viewing 12 replies - 1 through 12 (of 12 total)
  • Plugin Author Kevin Pirnie

    (@kevp75)

    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.1

    Now… 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=true

    Are 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

    Plugin Author Kevin Pirnie

    (@kevp75)

    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.1 for $_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 $_SERVER variables and check if REQUEST_URI is 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.
    ~ google.com
    Thread Starter mquiggeorgia

    (@mquiggeorgia)

    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.
    Thread Starter mquiggeorgia

    (@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.

    Plugin Author Kevin Pirnie

    (@kevp75)

    Appreciate the look out. Hopefully they will be able to correct it for you.

    Thread Starter mquiggeorgia

    (@mquiggeorgia)

    Not likely; their tech support is extremely slow and tedious. Might take weeks even to get a response. I do have the _SERVER variables from phpinfo() if you’re interested. Would prefer to send another way than on this forum though.

    Thread Starter mquiggeorgia

    (@mquiggeorgia)

    So $_SERVER['REQUEST_URI'] is correct from phpinfo(), 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.
    Thread Starter mquiggeorgia

    (@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.1 issue. 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.
    Plugin Author Kevin Pirnie

    (@kevp75)

    @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

    Thread Starter mquiggeorgia

    (@mquiggeorgia)

    @kevp75 That is excellent, thank you much! I’ll deploy it to our sites tonight.

    Thread Starter mquiggeorgia

    (@mquiggeorgia)

    @kevp75 PROBLEM SOLVED. Thank you sir for taking care of this!

    Plugin Author Kevin Pirnie

    (@kevp75)

    @mquiggeorgia great to “hear”. glad its working out 🙂

Viewing 12 replies - 1 through 12 (of 12 total)

You must be logged in to reply to this topic.