We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 44375
    • 92 Posts
    Thanks hugely Mark.

    I considered turning MODx sessions off, but web users can log into specific parts of the site to access protected pages/resources, so I believe I need them. Anyway if the session records aren't causing the document list to disappear, and don't alarm a MODx expert, and don't grow indefinitely (currently 16,000 since Friday), then I'm perfectly happy to have them.

    I have tracked down and removed the getDocumentObject error. In the upgrade I missed an old resource calling an Evo snippet. Despite the fatal error the page displayed fine. (Big up to MODx for that!)

    I thought this had returned, but I'd jumped to the conclusion - turned out to be a browser caching something in ExtJS - different browser worked - very sorry.

    Any tips on debugging this? I will have maybe a couple hours before clients will want setup run, so I'd like to churn out as much logging as possible. Tried adding ini_set('display_errors', 1); error_reporting(E_ALL); to manager/index.php and connector/index.php but nothing was displayed in the browser or logged in cache/log/error.log.

    (Ignore the rest...)

    However example.com/custom-connector-dir/system/phpinfo.php returns JSON {"success":false,"message":"Access denied.","total":0,"data":[],"object":{"code":401}} - as does clicking it from within Manager/System Info.

    The problem has returned. This time it looks more obviously like a connector issue, in that the Resources/Elements list appears but is empty, as are "Whose online", "Recently edited resources" and "Recent resource changes" on the dashboard. Components menu is populated. config.inc.php contains exactly what it did last time, and is letting me log in so database, core, etc all ok. 3 x config.core.php are all correct. Changing $modx_cache_disabled= true; in config.inc.php doesn't help. Flushing sessions in manager doesn't appear to do anything - I'm still logged in and the session table is still 16,366 records big. Nothing in the
    MODx error logs:

    [2014-01-21 10:24:38] (ERROR @ /customized-connector-dir/resource/index.php) Could not cache context settings for web.
    [2014-01-21 10:29:30] (ERROR @ /home/sites/example.com/core/xpdo/cache/xpdocachemanager.class.php : 510) PHP warning: unlink(/home/sites/example.com/core/cache/resource/web/resources/302/77e3bfd424401886e0935617fa44a0b4.cache.php) [<a href='function.unlink'>function.unlink</a>]: No such file or directory
    [2014-01-21 10:29:30] (ERROR @ /home/sites/example.com/core/xpdo/cache/xpdocachemanager.class.php : 518) PHP warning: closedir(): 181 is not a valid Directory resource

    The connector directory is a random string of 9 alphanumerics, set correctly in config.inc.php both $modx_connectors_path and $modx_connectors_url with leading and trailing '/'. What could be overriding this setting after a couple days' usage?? Or is connector somehow losing its ability to connect to the database? Or to authenticate AJAX requests?

    When I view source then look at the output of some of the connector calls, they do contain JSON data:
    example.com/custom-connector-dir/layout/modx.config.js.php?action=&wctx=mgr it does include data from the session.
    example.com/custom-connector-dir/lang.js.php?ctx=mgr&topic=topmenu,file,resource,welcome,configcheck,gallery:default&action= contains what looks like lexicon data.
    [ed. note: technicaltitch last edited this post 10 years, 2 months ago.]
      • 44375
      • 92 Posts
      Just to confirm that it has been over a week now and the manager is still working perfectly.
        • 44375
        • 92 Posts
        Just to confirm that it has been over a week now and the manager is still working perfectly.

        Huge thanks for everyone's assistance and sorry for wasting your time on this one.

        The modx_session table has stabilized at around 17,000 records. The original issue happened on different computers so wasn't caching. Running setup fixed it for a couple days, it then reappeared and running setup fixed it again, for a couple days. I then fixed two other bugs - an Evo snippet in Revo causing a fatal PHP error, and an error in the Provisioner Evo-Revo upgrade of template variables (type was 'dropdown' which no longer exists in Revo) causing manager to return a 500 HTTP error - and the problem of this thread disappeared. I didn't trace the source of this error so can't confirm whether the other fixes are related or not. [ed. note: technicaltitch last edited this post 10 years, 2 months ago.]