Make error msg more detailed - Could not retrieve data to cache for resource ##

[muzzwood]

Summary

Frequent errors in the log showing: [2018-03-01 11:37:28] (ERROR @ /home/site/core/model/modx/modcachemanager.class.php : 320) Could not retrieve data to cache for resource 654

Link to source here: https://github.com/modxcms/revolution/blob/2.x/core/model/modx/modcachemanager.class.php#L320

This error msg needs a reason included. Why could the data not be retrieved? Or if not important, perhaps the severity level should be lowered.

I've noticed this occurring in multiple sites. Originally I assumed an issue with multi-context multi-lingual sites however also noticed now in a single context site.

Step to reproduce

Unable to replicate. Seems to be random behaviour. I've tried clearing cache and reloading specified resource but doesn't reoccur on attempt.

Observed behavior

Each day about 50 of these error msgs appear from random resources.

Expected behavior

Either the error should say why the data could not be retrieved, or they shouldn't be shown at all in log_level 1

Environment

MODX 2.6.1 (however has been happening in past versions too), Apache 2.4.29, mysql 5.6.38,

[muzzwood]

Another one that isn't helpful and needs more information: [2018-03-02 14:46:52] (ERROR @ /home/site/core/model/modx/modx.class.php : 2324) No valid context specified:

[Mark-H]

Definitely not something that needs to have its severity lowered just like that - that seems like a rather important error related to resource caching.

My best guess from the code is that one of these conditions is false:

if (is_object($obj) && $obj instanceof modResource && $obj->getProcessed() && $obj->get('cacheable') && $obj->get('id')) {

Perhaps you can do some debugging on your site to figure out which one it is. That would then, hopefully, result in some useful steps to reproduce. Perhaps you have resources set to not be cacheable - I could imagine that condition needs to have a separate logging message, as it is expected for those to not get written to the cache.

The second error you posted suggests you're trying to initialize a non-existing context (source).

[muzzwood]

Sorry, yes, a bit hasty suggesting the severity be lowered. I'm working on debugging and might be on to something.. I'll put together a PR if so.

As for the context error, I didn't omit the context key so can only assume it's trying to initialise a context without a key somehow. The error msg would be helpful if it showed where it was originating but in it's current state doesn't convey anything.

[Mark-H]

The _initContext function is called by $modx->initialize()/switchContext/reloadContext, so somewhere where contexts are being handled something is incorrect.

[muzzwood]

I believe the cache error is coming from resources where they have a template assigned to them with nothing in it. They're not meant to be accessed but perhaps crawlers/bots are loading them.

The reason for using a specific template instead of setting the template to (empty) in the resource edit page is due to custom editing views in Collections.

I've added some redirect snippets to these blank templates and the errors have stopped.

Another workaround, could be to set all the resources with blank templates to unpublished although may be a bit confusing for editors.

Is anyone able to replicate this? and is it expected behaviour? @sottwell I know you mentioned seeing this error randomly before too. Did any of those sites have templates that were blank?

[smxi]

I found this warning to be connected to weblinks to PDFs that were set to be cacheable. Some were also set to use a non empty default html template, but another one was set to use (empty) template, so I'm assuming the problem may be with the cacheable switch on the settings tab, I'll test this and see if it fixes the issue for us.

[frogabog]

@smxi Did you sort this out? I'm seeing this on PDF resources as well. I switched to an empty template, turned caching back on and the error popped up again but the PDF won't load. Back to empty template, PDF works, caching off, no error.

[smxi]

I wouldn't call it sorted out, we're doing what I said above re cacheable switch. I checked our modx error logs and the error isn't there, but I assume the office staff are making those PDF weblinks non cacheable.