Opened 6 years ago
Closed 6 years ago
#44706 closed defect (bug) (duplicate)
Latest 4.9.7 wp_delete_attachment() security patch breaks deletion on 3rd party storage
Reported by: | l3rady | Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 4.9.7 |
Component: | Filesystem API | Keywords: | |
Focuses: | Cc: |
Description
We use AWS S3 to offload and store uploads on.
Previously we would hook into the wp_delete_file
filter see what files need deleting and then delete the files from the S3 bucket.
The new security patch checks if the files exist on the local filesystem first and are in the right directory before even attempting to delete the files and subsequently firing the wp_delete_file
filter. As our files are on a remote filesystem and not local, WordPress cannot see them locally and then doesn't attempt to delete the files. WordPress happily removes the record from the database but then leaves the files on S3.
The way it has been patched means that now we have to hook delete_attachment
instead and reimplement a lot of code WordPress already has due to a lack of filters and actions around this patch.
would it be possible to put in a filter around the check for file existence so we can override the result by checking S3 if the file is there and then feeding that back to WordPress to allow the delete to happen?
Change History (6)
#4
@
6 years ago
DigitalOcean Spaces Sync also suffering from the same issue when "only keep in DOS" is used.
https://wordpress.org/support/topic/not-deleting-from-spaces-when-deleted-from-media-libray/
See also #39476.