We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 36551
    • 416 Posts
    Just setup a new instance of Modx 2.4.0, php 5.4.43 on Hostmonster. While troubleshooting another problem with context router, which I'll post next, I found the error, above, in the Modx error log. My dashboard has no configuration warnings. Curl is enabled on the server and the Extra Installer is working fine.

    Anyone know what this means?
      • 3749
      • 24,544 Posts
      It's part of that same check on whether the core is web-accessible. It's really meant to make sure that the core is outside the web root. If cURL doesn't throw an error and there's a 200 return, you get the warning you had before. Since your core is still under the web root but protected, cURL throws an error, which for some reason leads to that cryptic error message.

      I think the only way to stop it is to really put the core outside the web root.
        Did I help you? Buy me a beer
        Get my Book: MODX:The Official Guide
        MODX info for everyone: http://bobsguides.com/modx.html
        My MODX Extras
        Bob's Guides is now hosted at A2 MODX Hosting
        • 36551
        • 416 Posts
        Got it.

        Thanks Bob!
          • 36448
          • 58 Posts
          I think the only way to stop it is to really put the core outside the web root.

          Hi, unfortunately the error still exists.

          I have updated a instance with one context from MODX 2.3.6 to 2.4.0, my core is outside the web root and I have no errors.

          My second instance with 3 contexts, MODX 2.4.0 on the same server and core outside I get the error:

          [configcheck] check core lockdown curl err: 28


          I use an easy ContextSwitch plugin, like this:
          <?php
          #System Events: OnHandleRequest
          
              if ($modx->context->get('key') == 'mgr') {return;}
          
                  switch($modx->getOption('http_host')) { 
          
                      case 'www.homepage1.tld:80':
                      case 'www.homepage1.tld':
                          $modx->switchContext('web2');
                          break;
          
                      case 'www.homepage2.tld:80':
                      case 'www.homepage2.tld.de':
                          $modx->switchContext('web3');
                          break;
          
                      default:
                          $modx->switchContext('web1');
                          break;
                  }


          btw: At the moment I use PHP 5.5.28 and my dashboard has no configuration warnings. Curl is enabled on the server and the extra installer is working. [ed. note: krischel last edited this post 11 years, 1 month ago.]
            • 3749
            • 24,544 Posts
            That sounds like a bug with multi-context sites.
              Did I help you? Buy me a beer
              Get my Book: MODX:The Official Guide
              MODX info for everyone: http://bobsguides.com/modx.html
              My MODX Extras
              Bob's Guides is now hosted at A2 MODX Hosting
              • 36448
              • 58 Posts
              Thanks Bob, I was on the wrong track.
              It seems like a small problem with the cache (not with multi-context) and I reported it to:
              github.com/modxcms/revolution/issues/12626
                • 52634
                • 60 Posts
                Hm. If the core is inside the root, but protected, curl should not throw an error there. Instead it returns the http return code (e.g. 403 if you protected by "deny for all") which is evaluated by the configcheck.
                Anyway, a timeout here means: everything ok, obviously no web access to the core (it does not matter if you run into a timeout, get redirected, or denied).
                The timeout itself _can_ be related to multiple contexts I think. But it is a complex problem to figure out the steps running at the server then.
                What should be fixed, indeed, is _not_ to log an error if a timeout occurs. I will fix that.

                Btw: a timeout can occur also if you e.g. work on localhost with an embedded webserver like the one used by phpstorm.

                  • 36448
                  • 58 Posts
                  Quote from: inreti at Sep 02, 2015, 04:34 PM
                  What should be fixed, indeed, is _not_ to log an error if a timeout occurs. I will fix that.

                  That's great smiley
                    • 36448
                    • 58 Posts
                    Hi inreti, i try your fixed config_check.inc.php and can say it works without errors on 3 instances. Thanks!

                    Is that included in the next release of MODX REVO (maybe 3.4.1) ?