Message of the day:
Security release 4.4.4 is out. Changelog: https://github.com/silverstripe/silverstripe-framework/blob/4/docs/en/04_Changelogs/4.4.4.md
SilverStripe 4 related information and questions.
this isn't common, but has been known to happen.
sometimes this might happen if the
tmp folder (or where ever the cache is stored) is not writable or suchwhat - so the site effectively does a full flush and build every request
ah right - its being run in ClassInfo.php line 94
are you saying that is run on a dev/build, and should be cached in the
so if a problem with that folder on production those queries would not be cached
@Barry if the
silverstripe-cache folder exists (and is writable by the web user) then it should be used, yes.
But there are a range of other folders that can be used if not, e.g. (and most commonly)
If for some reason the cache can't be written, then a flush will be attempted on each run. This was a rare issue with SS3, but I'll say I've not heard of it in SS4.
the reality of this issue lies in the code path to reach
ClassInfo - if this happens every request regardless then I think it should not, for performance reasons, in the least.
If this happens because some conditional is failing, then it's best to look at why that is :)
a easy way to look at this would be to throw an exception after line 94 on classinfo dot php.
then you'll see a stack trace :D (or, arguably better, use a breakpoint).
I reckon it shouldn't - this is the whole point of
dev/build (once named
db/build) - unless running that process I don't see a reason to hit performance that badly each and every request.
I've not used that module before, so unsure.
but you reckon if set to live, its not run on every request?
yup, seems likely :)
ah I see - I was using debug bar, so probably set the
SS_ENVIRONMENT_TYPE to dev
If you can't find a logical explanation (or otherwise find evidence that it is "intended" to run every request), please open an issue for framework :)
that shouldn't run every request IMO - I'd say you should check the environment in the production server (i.e.
it may change when you run a dev/build, which should be run on every deployment, so…