On a number of occasions recently I have seen errors which seem to suggest that some of my cache/manifest files on my live websites are being deleted (or corrupted?) and the site is falling back to using an older/outdated version of the classmanifest file for a given class. This is causing fatal PHP errors to be thrown on my live websites.

For example, some time ago (something like 3 months ago) I moved a class called 'SureAPI' (stored in SureAPI.php) from /mysite/code/model/ to /mysite/code/api/, I published this change to my live website, did a /dev/build and a flush=all in order to regenerate the cache/manifest files and all was well, the site worked perfectly.

Then over the weekend (about 3 months after this change was made) the server started throwing the following error:

PHP Warning:  require_once(/var/www/sites/sure-consumer/mysite/code/model/SureAPI.php): failed to open stream: No such file or directory in /var/www/sites/sure-consumer/framework/core/manifest/ClassLoader.php on line 77

Note: It is trying to include the file using its old location/path of /model. Performing a flush=all on the live website rectified this issue, so I have started investigating why out of no where (no code changes have been released recently and the server has not been rebooted) the server would start looking for the file in the wrong/outdated location. I understand that the classmanifest files supposedly store, amongst other things, the class name and path of classes. I cannot see any reference to the path in my classmanifest files, an example is below:

a:3:{s:7:"classes";a:1:{i:0;a:1:{s:9:"className";s:7:"SureAPI";}}s:10:"interfaces";a:0:{}s:9:"namespace";s:0:"";}

I can also see that there are multiple cachemanifest files for this particular class, which have last modified dates between today (10th August 2015) and 25th July 2014. I am therefore assuming that SilverStripe does not delete the stale classmanifest files once a new one is generated, though I am not sure why?

My assumption is that somehow the up to date classmanifest file for SureAPI has been deleted and the site has started using the most recent one it can find (which is 3 months old), somewhere (which I can't locate) it is storing the path to the class in an old manifest file and therefore referencing the old file location. How could this possible occur?

I had a similar issue on another server after it was rebooted, but I had put this down to the fact that the cache was being stored in /tmp which would have been wiped on a reboot, so I thought there must be some weirdness to do with that, but this other server which is exhibiting the same issue stores it's cache files in the site root.

I know that SS creates a new directory in the silverstripe-cache folder for each 'user' on the server who is making the request from the cache or regenerating a new cache file (my server has 3 sub-directories of silverstripe-cache 'root', 'rubble' (the main user on the machine) and 'unknown'. I have also considered that the requests might have started coming from a different 'user' and therefore a different set of cache files were being used, but there have been no changes to users or user groups on the server which would make that a logical conclusion to reach.

Does anyone have any ideas as to if my assumptions are correct, or any other reasoning for this to keep occurring? I have read all the 'Execution Pipeline' articles including the 'Manifests' section but it is far from clear cut. I have also spent a good couple of hours interogating the core code itself which deals with manifests and caching but again thats about as clear as mud to me :-(

Any ideas gratefully received!

Kind regards,

HARVS1789UK

Changing in configuration can cause such a user type change - eg wwwdata to <siteowner> if changing from mod_php to phpfpm or similar (fcgi etc.).
Other possibilities could include a rollback or restore from backup due to someone else making an undesired change (and restoring the wrong version), or having the manifest in the git repo (so a checkout <live tag> could mess it up), etc. which would leave it looking like no code has changed (no updates you say) but the manifest effectively being backdated.

SS should clear the cache on re-build, as per: https://github.com/silverstripe/silverstripe-framework/blob/3/core/manifest/ManifestCache.php#L35 (and the clear() function below it) - so I think it's more likely something like the above has happened.