SSM Caching
Closed this issue · 7 comments
This new feature is causing no end of trouble for us on a big project.
As we add our manifest folders to the VCS, every time we deploy the site, it breaks. This is down to the SSM caching, whether it's included or not.
Is there any way to switch this off? Why was it introduced over using caching in Symphony?
You can turn in off by switching back to version 1.x.
SSM needs to parse the Data Source to fetch the included elements – these values are stored in manifest. Furthermore the extensions caches entries internally (not in the file system) when generating the XML to reduce database queries.
What exactly isn't working in your setup? SSM should refresh the included fields cache when:
- Data Sources have been modified or
- if
subsectionmanager-storagedoes not exist.
How does it break your site?
So the SSM has a cache file in the manifest, but because we deploy to two servers (stage, dev) they are different cache files and when the DSs have changed, the file doesn't reflect this and outputs incorrect content into the SSM xml within entries. It breaks because the site expects certain content which isn't there.
I would prefer not to roll back, I like the updates, it's just this caching that is a problem.
I have partially fixed it by not including the cache in the VCS, but even when DSs are modified it isn't reflecting this correctly, at least I assume. Deleting the cache file works every time.
I would prefer not to have to delete the cache file every time, as this negates the point of caching.
Is the cache checking itself for changes? It seems not, which to me is unreliable in this use case.
It checks the last modified date of the Data Source files.
I will keep my eye on this then to see what causes our issues.
This is where the extension checks the field cache: https://github.com/hananils/subsectionmanager/blob/master/extension.driver.php#L48-60
For your information: