We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 46802
    • 7 Posts
    We've been having trouble with a Modx Revolution site on a Windows Server running on Zend Server WAMP stack.

    We've updated to the latest version thinking the issue below (and a few other reported cases) were solved in later versions but it's still happening.

    http://bugs.modx.com/issues/8423

    Its the same problem, where the cache file ends up being wrote twice. The unexpected '<' in the file is the start of the same code starting for the second time in the same file. < being the start of <?php

    We have over 100 Modx sites, starting back pre-evolution up to the latest version of revolution and this only occurs on this specific revolution site on this specific server. The same site running on a Linux / Cpanel setup, it doesn't happen. Can anyone shed any light on what the issue might be? [ed. note: mor-mark last edited this post 12 years, 6 months ago.]
      • 46802
      • 7 Posts
      Digging further...

      The xPDO Cache Manager class always appears to default to "append"

      /core/xpdo/xpdocachemanager.class.php
      $fmode = (strlen($mode) > 1 && in_array($mode[1], array('b', 't'))) ? "a{$mode[1]}" : 'a';
      


      Changing this simply to set fmode to w appears to fix the issue entirely.
      - The only down side we've found so far is that we lose the Modx error log file. W obviously rewrites the cache file clearing out any old contents.

      Similar to he suggestion in the bug report below but use_flock does not do anything to stop the issue from happening...
      http://bugs.modx.com/issues/9386

        • 24865
        • 289 Posts
        Nice find mor-mark. I'm amazed at the level of support this issue is getting. In my opinion, using MODX on cloud based servers, or racks, takes precedence over working on a new skin and so forth. I continuously keep bumping into this issue where cache files are appended before writing is finished, and due to the NFS mount, locking doesn't work right. This has been the case for at least the last 1,5 years since I started working with the pre-release and beta versions of Revolution.

        Your solution, again, in my opinion, seems almost water tight, but loosing the MODX log file is a big and obvious downside- some logic should be written to avoid that. I couldn't care less if my error log seems messed up - as long as I have partial error logging.

        If you turn up any more fixes, please let OpenGeek know too, as he supports the layer beneath MODX, xPDO.
          @MarkGHErnst

          Developer at Adwise Internetmarketing, the Netherlands.