Context Settings Cache File Gets Corrupted

Support
1

Summary

Every now and again, the context cache settings file fails to generated fully. This results in the website failing to load due PHP errors. One thing I have noticed is that the context cache file is continually being generated, regardless of there being any activity in the manager. This website has several contexts, with the context file that crashes the ‘main’ website one (which is not the default ‘web’ context). Where the cache file stops being generated is not the same, however a corrupted file is usually about 8KB.

While there are maybe many reasons why the cache file gets corrupted (disk error during write, out of memory etc), I guess my question is: Should the context cache file be continually generated. None of the other contexts have their cache file updated unless something changes with a resource. Also, there are no PHP errors at the time of when the cache file gets corrupted, nor a specific URL that happens consistently.

Step to reproduce

Unknown. We cannot replicate the cache file being corrupted based on any pattern of user behaviour. When it occurs is not consistent with any known system process, website module, or user.

Environment

Apache
MySQL
PHP 7.2

1 Like
2

I’m pretty sure that the cache is generated on first load of the context if it doesn’t already exist.
Have you got any plugins that manipulate the cache, custom caching, registry snippets or anything like that?
Anything outside the default?

1 Like
3

I don’t have anything directly effecting the cache, and it seems to be the only site I’ve built that does it. What does set this apart is the mulitple contexts and that the default context isn’t ‘web’. I had to create a plugin that force a context switch since the the default context system setting doesn’t seem to do anything, but not sure why a context switch would make the cache settings file be rebuilt.

If the cache file isn’t meant to be continually updated, this helps me look in other areas. Cheers.

4

I’ve got quite a few sites where the web context is not used at all. Default one is en for example, so that shouldn’t be affecting it.

The default context system setting is really just used to designate which context new resources are created in when not specified I think.
In order to load/initialize a different context a plugin/snippet is needed like you’ve done. (unless you wanted to edit the context key in the root index.php file, but upgrades would overwrite that)

1 Like
5

What version of MODX are you running? Some of the older versions suffered from occasional cache corruption.

1 Like
6

Sorry, forgot to say. MODX 2.7.1.

I’ve worked it out to be the context switching that’s causing the cache rebuild for every request. For the moment I’ve disabled it and forced the context via the index.php. Not ideal, but will do for the moment until I can dig deeper.

This was the code that forced the rebuild. Doesn’t explain why the cache file was corrupted, but removing it should hopefully lessen the chance.

case 'OnHandleRequest':
if($modx->context->get('key') != "mgr") {
        if(!$modx->context || $modx->context->get('key') != "au"){
            $modx->switchContext( 'au', TRUE );
        }
}