Open IanSimpson opened 9 months ago
The problem might be though that the local system is read only, so where would you store them locally? In the temp folder?
This would be related to #40
You would need to configure the Generated Asset Handler to write to the local file system instead of S3. Example would be -
SilverStripe\Core\Injector\Injector:
SilverStripe\Assets\Storage\GeneratedAssetHandler:
class: SilverStripe\Assets\Flysystem\GeneratedAssets
properties:
Filesystem: '%$League\Flysystem\Filesystem.localpublic'
Note then any random generated asset will write locally then. Not sure what all else this would affect, like whether generating alternate images within your templateswith the helper functions would then write locally instead of s3 or not. Right now we do this specifically for TinyMCE but TinyMCE has its own AssetHandler Config - https://github.com/silverstripe/silverstripe-s3/blob/ec39ebaa1d8b9370e667ae6d777081447cb8258b/_config/tinymce.yml#L17
Ideally would be great if the silverstripe/errorpage module would provide that functionality as well but right now it just uses the default configured GeneratedAssetHandler for SS. You could extend ErrorPage and overwrite the get_asset_handler function to return a custom configured handler like TinyMCE is using.
The problem might be though that the local system is read only, so where would you store them locally? In the temp folder?
Absolutely - if there's a way to bake it into this addon then it should be configurable. Off by default makes sense. It's probably not a major issue, for example, if you're hosting the site on EC2 in the same region as the S3 instance. In my case the site is in New Zealand and the files are in Australia, so that's quite a bit of added latency (compared to local disk access, at least). In my instance I do have write access - purely using S3 because the site has many GB of attachments and disk space in NZ is expensive.
You would need to configure the Generated Asset Handler to write to the local file system instead of S3.
OK, this makes sense. I guess I'll test this out. For my purposes it's probably not a big deal if there's local images etc. - it's mainly uploaded PDFs I'm trying to offload
You could extend ErrorPage and overwrite the get_asset_handler function to return a custom configured handler like TinyMCE is using.
This might be the way, certainly in terms of making it configurable so it works in every use case rather than just my one. I'll explore this option too.
I've stumbled on a bit of a quirk.
When 404/503 pages are generated they, of course, save to S3. This creates two problems when we encounter badly behaved bots.
Firstly, the 404 becomes relatively slow to load as it requires a round trip to AWS to pull the content. Not a big problem for the odd hit, but starts impacting availability when you have hundreds of hits per minute from a bad bot.
I've worked around this issue by blocking the problem URL in .htaccess, but then it automatically fetches the local error-404.html, which isn't updated.
I suspect 503s will do the same - returning an outdated error-503.html.
Ideally, these two files would bypass S3 and just be stored locally. Given it's only a few bytes I'm happy to store them locally, and there's substantial benefits to doing so.
Is there any way to do this now? Does it make sense to build this in?