We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 1198
    • 6 Posts
    Hi, this is only my second post on this forum, so apologies if it’s in the wrong forum, feel free to move it etc...

    I’m working on a reasonably busy site that I recently converted to MODX. As they get a lot of traffic, and the server isn’t as amazing as it used to seem, I’ve opted to enable full caching - pages, snippits etc.

    The caching is working well, but the client updates their site regularly (they are a magazine), and obviously they are clearing the cache every time they update the site.

    Because they are clearing the cache and the site is so busy, it’s causing me a bit of a headache with high server loads, so I’ve been hacking the MODX core a bit to change the way the cache is cleared.

    So basically, my question is - what are the implications of the following change to the cache_sync.class.processor.php file?

    	
           //added this function
            function removeCachePage($doc_id) {		
    		$cacheFile= $this->cachePath . "docid_" . $doc_id . ".pageCache.php";
    		@unlink($cacheFile);
    	}
    


    Then, in the relevent processor files changing the call

    $sync->emptyCache();


    to

    $sync->removeCachePage($_REQUEST['id']);


    I’ve already implemented it, and it seems to work well, it stops a page save / delete from emptying the entire cache, as now we just remove the offending page rather than all the pages. But... will I regret this later down the line?

    Thanks in advance for your help.


    EDIT: Using Version 0.9.6.2
      • 22303 MODX Staff
      • 10,725 Posts
      Yes, you will regret it, because anytime a page alias changes, or a new on is published/added or an old one deleted/removed/unpublished, the siteCache file needs to be rebuilt. Things have been refactored to improve the modularity of the cache in the development of the next major release, but for now, I think you are potentially going to find problems with this approach. Better hacks would be to address this in the the save processor for documents, rather than in the common cachesync class.
        • 1198
        • 6 Posts
        Thanks for your reply, I’ll set it back.