We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 28042 ☆ A M B ☆
    • 24,524 Posts
    Since these links are all relative, the browser uses the value from your [[++site_url]] tag in the base META tag. The site_url is generated on page load by the config.inc.php file - it is generated from several values taken from the reported SERVER values. For example, to determine it it's an HTTPS request
    $isSecureRequest = ((isset ($_SERVER['HTTPS']) && strtolower($_SERVER['HTTPS']) == 'on') || $_SERVER['SERVER_PORT'] == $https_port);
    

    And to get the host:
    $http_host= array_key_exists('HTTP_HOST', $_SERVER) ? $_SERVER['HTTP_HOST'] : 'localhost';
    

    So for some reason the server hiccups and reports itself as being the IP address, and reports HTTPS as being 'on'.

    Do you recall if you had done something in the host's secure area immediately before loading the page in question? Could it be a cookie holdover from such a secure page request causing the server to still report itself as being on HTTPS?

      Studying MODX in the desert - http://sottwell.com
      Tips and Tricks from the MODX Forums and Slack Channels - http://modxcookbook.com
      Join the Slack Community - http://modx.org
      • 17578
      • 33 Posts
      I hadn't been working in the host area or in MODX when this happened.

      I just got off the phone with a Media Temple rep and he, of course, said it was not a result of anything on their end and theorized that someone may have visited the site by typing in https and that became part of the site cache. Absurd. He's saying that because the problem was resolved by clearing the MODX site cache, it was a MODX issue.

      It's all a little disconcerting since there's no glaring culprit.

      Thanks everyone for the suggestions and feedback.

      R