MarkdownEditor will save to local disk but not S3
So this is probably a stupid question, but I'm banging my head against the wall here and I'm not really sure where else to look.
I have a MarkdownEditor component that I want to accept images within. If I don't set a disk with
->fileAttachmentsDisk(), it effectively saves the file as soon as I drag the image onto the editor pane. Once it's been saved, it shows up immediately in the editor pane, exactly as you'd expect, on the local disk storage, etc.
My problem is that if I try to set the component to store to the disk called "s3" by doing ->fileAttachmentsDisk('s3') on the MarkdownEditor component - which works perfectly fine throughout the rest of the Admin Panel in the form of various SpatieMediaLibraryFileUpload::disk('s3')->... elements - dragging an image on the pane does "nothing". I say "nothing" in quotes because I can see traffic in DevTools and it's doing something but no file ever actually ends up in S3, and no file shows up in the editor panel, confirming that something probably went wrong but no exceptions are being thrown.
What I've tried:
- Digging into the internals of the MarkdownEditor component to see if I could isolate where it's failing, but moving my way up the dependency/inheritance tree, I can't actually figure out where the actual upload is taking place
- Confirmed that the AWS API key is valid and has active rights to store in the target bucket
- Confirmed that the file never ends up in S3
- Confirmed that the aws/aws-sdk-php package is installed and is up to date
- Confirmed that by removing the disk setting, things go back to normal and the file is saved to the local disk configured on my machine
- Confirmed that DevTools shows no actual errors; all the requests succeed
If anyone has any suggestions of things to dig into, I would really appreciate them, even if they seem far-fetched. I think I've tried most of the low-hanging fruit so I'm ready to get creative.
Thanks!Solution:Jump to solution
Ok I was able to solve the problem by doing a couple things:
1. In my
config/filesystems.php file, I set 'throw' => true on the S3 disk so I could see the actual upload exception
2. The exception being thrown was (unsurprisingly) League \ Flysystem \ UnableToWriteFile but the error message went into more detail about the problem which helped:
```...3 Replies
Also, one weird thing I noticed (that may or may not be related): I have Laravel Herd Pro installed and if I try to add the same image twice, Herd pops up a window indicating that there was initially a "CACHE MISS" and then a "CACHE HIT" so I'm wondering if somewhere deep in this component, it's trying to cache the contents locally and then failing immediately afterward? Anyways, this could totally be a red herring, but it does at least seem to confirm that it's seeing the file being uploaded from the browser, even if it's not pushing to S3 correctly.
Solution
Ok I was able to solve the problem by doing a couple things:
1. In my
config/filesystems.php file, I set 'throw' => true on the S3 disk so I could see the actual upload exception
2. The exception being thrown was (unsurprisingly) League \ Flysystem \ UnableToWriteFile but the error message went into more detail about the problem which helped:
3. Ok, so now we know it's trying to set an ACL but the bucket is configured not to use them. This is intentional as the bucket is specifically meant to host public assets.
4. Initially I tried adding 'options' => ['ACL' => null] to my S3 disk in filesystems.php but it seemed like it was being ignored because the value was null. Then I tried 'options' => ['ACL' => ''] and everything started working. Files could be dropped into the MarkdownEditor and were immediately being displayed!