ianmjones
Forum Replies Created
-
We’re working on it.
https://deliciousbrains.com/wp-offload-s3-1-6-released/#looking-forward
You could maybe make the objects private so that WP Offload S3 Lite generates expiring signed URLs.
Please turn on debug logging and see if anything turns up when viewing pages that have the problem.
TL;DR: Not an issue, but we’ll hopefully quieten these validators in the next release of WP Offload S3 Lite.
We have tested the version you have on PHP 5.3 all the way through to PHP 7.2 (yes, it takes a while).
These are false positives, indeed related to an older version of Guzzle bundled with the AWS PHP SDK v2.
We’re in the process of switching to AWS PHP SDK v3, hopefully tools like the one you use won’t raise issues with it as there’s a much newer (and quite different) Guzzle library bundled.
It might be down to how your site’s server connects to S3, have you asked your hosting provider to check the connection to S3 is OK?
If you turn off the copy to S3 and upload a new image, is much much quicker?
If you remove a Media Library item then WP Offload S3 Lite will remove the S3 object too as your site can no longer use it.
There’s currently no way to stop WP Offload S3 Lite from doing that as far as I can tell.
Why would you want to do that?
Hi @anke16,
Ah, OK. Divi has code to integrate with WP Offload S3, but we’ve recently found an issue with its Visual Builder, it works fine when editing and saving a post but when you return to edit a post with Visual Builder it doesn’t properly load the S3 URLs.
We’re hoping to add an integration to WP Offload S3 (not Lite as it’s a paid for theme that we have to spend time testing and supporting) to a forthcoming release that fixes Divi’s Visual Builder.
Cheers,
Ian
Hi @anke16,
Wanted to check what versions you’ve used in case it was an issue with the migration from S3 URLs embedded in database content to being local with filtering. Given your version history, that shouldn’t be the problem as you’ve never had S3 URLs embedded in the database. (this is good)
So here’s the million dollar question, what theme (or parent theme) are you using, or are you using a “page builder” plugin of some sort?
Oops, that message should switch depending on whether you’re using WP Offload S3 or WP Offload S3 Lite, looks like we forgot to do that!
So yeah, from WP Offload S3 Lite 1.3 onwards you can remove the AWS plugin if its not being used by anything else (which is unlikely unless you’ve done some custom work).
Can you confirm your use-case?
If you delete a Media Library item from WordPress you don’t want the corresponding S3 files to also be removed?
We’re working towards supporting DigitalOcean Spaces, but do not as yet have any further information to share.
What version of WP Offload S3 Lite were you using prior to 1.3.2?
I take it https://spreadmind.de/folder/uploads/2018/05/photo.jpg is a “local” URL format for your site that would work if the image had not been removed from the server?
Just to clarify what was happening here, there are two totally different postmeta records highlighted above.
amazonS3_info
is used as a record of where on S3 a Media Library item has been uploaded to by WP Offload S3.amazonS3_cache
is used to quickly lookup what Media Library item relates to a URL found in the content of a post so that the Media Library does not need to be searched.Media Library items missing
amazonS3_info
records just means they hadn’t been uploaded to S3 yet, if they were existing Media Library items created before installing WP Offload S3 Lite this is to be expected, it only uploads new Media Library items to S3.To safely upload existing Media Library items to S3 the WP Offload S3 plugin has a tool for uploading all existing items, as well as working with them individually.
You’ll need to contact your hosting provider to get them to whitelist the file so that their antivirus doesn’t keep quarantining it.
There’s nothing in WP Offload S3 that relates directly to featured image dimensions.
Do you by chance have “Remove Files From Server” turned on?
If so, it might be that the theme isn’t picking up on the dimensions held in the postmeta record and is otherwise trying to get the dimensions from a missing file.
I would look at your debug log to see whether the cropping is failing.