We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 31902
    • 342 Posts
    A few months ago, I upgraded a site to 2.6.5 due to the hack attacks. I don't think this was one of my hacked sites but I thought the site was running okay until I visited it to make some changes this morning.

    Although the site had been working okay before the upgrade, I now experience the left column tree failing to load the resources after I click on a resource (sometimes it does work...this is intermittent but very often). Please see the left column image attached here with the red arrow pointing to the ever present loading animation. Note that the Elements tab works okay and I can access chunks, etc.

    Even more weird, I've noticed that when I hover my mouse over the Manage menu item at top, the cursor turns into a move tool and, of course the dropdown menu under it does not show. When I drag that move tool, for instance, to the right, I get a ghosted empty error box that I can drag around. Please refer to the other attached image of the box in the process of being dragged. As soon as I let it go, it disappears but it is still there, covering the stuff underneath. That's the reason the hover didn't work on the Manage menu item; it was layered over the Manage menu item. Yes, I can X it out but it comes back and the left column still hangs.

    The front of the site works normally.

    The error log shows this but I have already taken care of the uncache situation and the problem still remains. I've included it here just to be complete:

    [2018-10-16 15:12:21] (ERROR @ /home/sample/public_html/core/model/modx/modparser.class.php : 452) You should not call uncached elements inside cached!
    Outer tag: [[If? &subject=`[[*extra-function-content]]` &operator=`is` &operator=`empty` &then=`` &else=`
    <br /><br />[[*extra-function-content]]`]]
    Inner tag If? &subject=`<h2>Results</h2>
    [[!SimpleSearch? &exclude=`13`]]` &operator=`is` &operator=`empty` &then=`` &else=`
    <br /><br /><h2>Results</h2>
    [[!SimpleSearch? &exclude=`13`]]`
    [2018-10-16 15:12:21] (ERROR @ /home/sample/public_html/core/model/modx/modparser.class.php : 452) You should not call uncached elements inside cached!
    Outer tag: [[If? &subject=`<h2>Results</h2>
    [[!SimpleSearch? &exclude=`13`]]` &operator=`is` &operator=`empty` &then=`` &else=`
    <br /><br /><h2>Results</h2>
    [[!SimpleSearch? &exclude=`13`]]`]]
    Inner tag If? &subject=`<h2>Results</h2>
    [[!SimpleSearch? &exclude=`13`]]` &operator=`is` &operator=`empty` &then=`` &else=`
    <br /><br /><h2>Results</h2>
    [[!SimpleSearch? &exclude=`13`]]`


    I have:

    1. Cleared my browser cache.
    2. Cleared site cache through the control panel.
    3. Cleared my core>cache.
    4. Tried using multiple browsers, including in incognito mode.
    5. Verified changes as per this link having to do with PHP 7; changes had already been implemented: https://forums.modx.com/thread/98914/having-trouble-running-modx-on-php-7-0-0-rc7
    6. If I go directly to the manager landing page, the left column loads okay.
    7. If I go to the Elements tab, the left column loads okay.
    8. Verified directory permissions are good.

    Thank you in advance for any help.

    MODx 2.6.5
    PHP 7.0 (ea-php70) [ed. note: waizen last edited this post 5 years, 5 months ago.]
      • 31902
      • 342 Posts
      Actually, I'm now seeing various bugginess from several of my MODx 2.65 upgrades that weren't there before. All the problems are intermittent and in most cases, clear up when I refresh the browser.

      Some intermittently have the top section of the manager page "tuck" under the top of the browser window. Reloading the page brings it back.
      Many exhibit a sort of intermittent partial white screen of death where the page loads white except the top right set of buttons. Again, the page comes back after I refresh the browser.

      Various browsers with cleared caches.

      The common thing is that each problem happens on page reload. Usually when I select a resource, making the page reload. Not sure if that helps.

      Server has not changed since before the upgrades and the MODx system requirements page hasn't been updated since Aug 10, 2017, so I have no idea if the server needs to have any upgrades done to support MODx 2.6.5. [ed. note: waizen last edited this post 5 years, 5 months ago.]
        • 31902
        • 342 Posts
        The symptoms have now changed on the originally mentioned site above. I no longer see the ghosted box but the loading animation icon on the Resources tab keeps spinning endlessly and much of the time the page loads without the top section of the manager, as if it's tucked in under the top part of the browser. I've seen this before on other sites. Sometimes, the page crashes, displaying a "page not found" page. I then back up the browser until it comes up again. Please note this site worked okay before the upgrade.

        I just tried going back to php 5.6 but that didn't help. Put it back to PHP 7.0 (ea-php70).
        I just tried re-running setup but that didn't help.
        Core/cache has been cleared umpteen times.

        Really frustrated here.
          • 3749
          • 24,544 Posts
          Try turning on Dev. tools in Chrome or Firefox (Ctrl-shift-i). You can watch the console tab to see any JavaScript errors, and you can watch the Network tab to see what's going on with the processors. If you click on a call to connectors/index.php, you can see what's returned from the processor on the Response tab. It should always be a JSON string, but if there's an error in the processor, it will be a chunk of confusing HTML containing a PHP error message.

          Is there anything in the MODX error log (Manage -> Reports -> Error Log)?

          You cleared the cache manually by deleting all files in the core/cache directory, right?
            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
            • 31902
            • 342 Posts
            Quote from: BobRay at Oct 17, 2018, 07:15 PM
            Try turning on Dev. tools in Chrome or Firefox (Ctrl-shift-i). You can watch the console tab to see any JavaScript errors, and you can watch the Network tab to see what's going on with the processors. If you click on a call to connectors/index.php, you can see what's returned from the processor on the Response tab. It should always be a JSON string, but if there's an error in the processor, it will be a chunk of confusing HTML containing a PHP error message.

            Is there anything in the MODX error log (Manage -> Reports -> Error Log)?

            You cleared the cache manually by deleting all files in the core/cache directory, right?

            Thanks for responding, Bob.

            Yes, I did look at the console earlier today but honestly, I couldn't make sense of what I'd seen and doing searches online on what I saw didn't help. I'll look at it again with what you've just suggested.

            Since there are similar buggy issues going on like that with multiple sites (although that site in question at the top of my thread is the most chronic problem one), we're currently having the server folks look at the possibility that there might be a configuration issue that MODx 2.6.5 just doesn't agree with. These are all sites that were working prior to the upgrading during the hacking circus a couple of months ago.

            In answer to your questions:

            1. Yes, I did clear the core/cache manually, multiple times. I tried clearing it by:
            a. Clearing everything inside.
            b. Changing the name of the cache directory to preserve it and then allowing the system to rebuild a new one.
            2. I also ran setup again...no luck.
            3. The only thing in my error log was what I outlined in my original post above, which I took care of. Turned out to be unrelated to my main issue. After I cleared my cache (and therefore the error log), there was nothing there after throughout my so-far day-long troubleshooting session.
            4. Tried setting the server to php 5.6 with no change. Changed it back to PHP 7.0 (ea-php70).
            5. Making sure directories have correct permissions.
              • 3749
              • 24,544 Posts
              Since we're grasping at straws, consider that even if the permissions are correct (normally 755 for directories and 644 for files), the file ownership might have changed.

              Also, another thing to try is disabling all your plugins, (and deleting the cache files again). If you can't do it in the Manager, you can do it in the modx_site_plugins table in the DB (change the 'disabled' field value to 1). If that fixes things, you can re-enable them one by one by right-clicking on them in the Elements tree to see which one is causing trouble.

              Here's something else to try: Change your settings_version System Setting back one version and use UpgradeMODX to "upgrade" to 2.6.5. That will give you all new MODX files.

              [ed. note: BobRay last edited this post 5 years, 5 months ago.]
                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
                • 31902
                • 342 Posts
                Another piece of the puzzle.

                We had the server people take a look at the possibility that the server that this and the other MODx problem sites are on may be incorrectly configured to run MODx 2.6.5. Based on the server requirements located on the page located here:

                https://docs.modx.com/revolution/2.x/getting-started/server-requirements 


                It turns out it is configured properly. Notice the last edited date on that page is August 10, 2017, so hopefully it's up-to-date enough for MODx 2.6.5.

                But, looking deeper, the server people sent us the following message, which I've copy/pasted here:

                Hello,

                It appears mod_evasive is blocking requests in your backend causing your pages to break.

                We'd recommend leaving mod_evasive enabled. The solution would be to whitelist your IP in the mod_evasive config. You can do so by adding your IP in '/etc/apache2/conf.d/300-mod_evasive.conf' like so:
                ==
                DOSWhitelist <Your IP>
                ==

                If you're still encountering issues after whitelisting your IP, you can disable mod_evasive, however it is not advised.

                You may also be able to lower the strictness of mod_evasive, however this is beyond the scope of our support. Here are some general configuration options:

                ==
                DOSHashTableSize: Specifies the number of top-level nodes for each child’s hash table. Increasing the number improves performance, but also consumes more memory.
                DOSPageCount: Specifies the number of requests for the same page per page interval before an IP address is blocked.
                DOSSiteCount: Specifies the number of requests for any object by the same client per site interval before the IP address is blocked.
                DOSPageInterval: The interval used in the page count threshold (measured in seconds).
                DOSSiteInterval: The interval used in the site count threshold (measured in seconds).
                DOSBlockingPeriod: Specifies the period of time (in seconds) that an IP is blocked. During this time, all requests originating from the affected IP are given a 403 redirect.
                ==


                If you need us to whitelist your IP for you, please provide us with the IP(s) in which you work in the backend from.

                We provided our local IP and he whitelisted it. Now, this problem site works perfectly, as well as all the other ones...at least from our location. I'm planning on taking the (formerly) problem site for a test run from home tonight.

                So, what is it that is making mod_evasive on the server black list us enough to cause all this mischief? Remember, all these sites were running perfectly before the 2.6.5 upgrade.

                Is there something about this newest release that patched the hack attacks that may be triggering safety measures? Overly-aggressive safety measures within MODx?

                Am I understanding all this correctly?
                  • 3749
                  • 24,544 Posts
                  I'm guessing here, but one of the things mod_evasive does is protect against DDOS attacks. The MODX Manager makes a lot of http requests in a very short time. Turn on Chrome or Firefox dev. tools (Ctrl-shift-i) and watch the network tab as you reload a Manager page and you'll see what I mean. Having the browser log the requests on the Network tab actually slows them down quite a bit, so without it, they are even faster.

                  I suspect that mod_evasive thinks that looks like a DDOS attack.
                    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
                    • 31902
                    • 342 Posts
                    Bob, I do see what you mean about the number of requests. Have they always been that many? Have they increased with 2.6.5? It's never been an issue for us prior to 2.6.5. I'm not blaming MODx itself, in fact, I can't find other online examples of this problem happening to others, although I may just be searching with the wrong key phrases.

                    The question is, what do we do about this now?

                    The whitelisting by our server people cleared the problem for us locally. From our office, all the sites are working great. However, what about those clients who want to work within the manager from their locations? I accessed the main problem site from home last night and experienced those issues from there. So, our clients will, too.
                      • 3749
                      • 24,544 Posts
                      I don't think the Manager has gotten any more request-intensive. More likely, it's the introduction of mod_evasive.

                      In addition to whitelisting (which won't help clients without a static IP address), there are some suggestions here about making mod_invasive less aggressive: https://parkroad.co.za/identifying-and-fixing-modevasive-client-denied-server-configuration-errors.

                      The only other alternative is to turn off mod_evasive. There's really not much motive to launch a DDOS attack against most sites, unless you have political reasons for doing so, or bringing the site down will get you in the news (e.g., messing with the site of apolitical party or a major Airline). MODX does its own blocking of brute-force login attempts. I'm pretty sure mod_evasive is not running at A2 and probably not at the other modx-friendly hosts I know of.
                        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