ianmjones

From what I understood, the file “photo.jpg” in the bucket should be smaller than the original photo on my PC, correct?

Hmm, that’s a good question.

@nosilver4u, does EWWW Image Optimizer optimize the original image uploaded to WP? Or does it leave that file alone and only optimize the -scaled.jpg and other thumbnails?

-IJ

Currently WP Offload Media only works with S3 objects it has offloaded.

You’d probably have to use the as3cf_object_meta filter to set a custom Key after querying whatever data that third-party plugin provides.

https://github.com/deliciousbrains/wp-amazon-s3-and-cloudfront-tweaks/blob/96d9fc03ffcfdc1d2e77b0a1a53891e6e1a76e30/amazon-s3-and-cloudfront-tweaks.php#L578

What does the postmeta table record with meta_key = “_wp_attachment_metadata” and post_id = 87326 look like?

Fixed in 2.4.4.

This is often solved by simply rebooting the instance as it’s usually a network/DNS issue.

If that doesn’t help, please upgrade to the just released v2.4.4, that might possibly help as it has an update to the AWS PHP SDK.

WP Offload Media (not Lite) has built in integration for Divi Builder.

As long as you haven’t removed the files from the server, then you can just turn off WP Offload Media Lite’s “Rewrite media URLs” setting or deactivate the plugin to start using the local files again.

If you have turned on the “Remove Files From Server” setting then you’ll need to either manually copy the files back from the bucket and put them where WordPress expects them, or use the “Download all files from bucket to server” tool in WP Offload Media.

What’s the error you get when trying an upgrade that fails?

Yes, sorry about that, please revert to WP Offload Media 2.4.1, deactivate AMP, or enable the intl PHP extension.

The problem is a little deeper than thought: https://github.com/aws/aws-sdk-php/issues/2092

We’re looking into working around the problem in an upcoming bug fix release if we can’t get a fix pushed up to the AWS PHP SDK.??????

Fixed in 2.4.3.

We’re aware of the problem and looking into it.

https://github.com/deliciousbrains/wp-amazon-s3-and-cloudfront/issues/564

This was fixed in 2.4.2.

Are those records amazonS3_cache records, as used by WP Offload Media to speed up its URL rewriting for content?

If so, what’s the problem you have with them? What issues are they causing for the site?

The _wp_attached_file value and paths in _wp_attachment_metadata should not have a leading /.

Other than that, you’ll need to find out which other plugin in the original site is editing the attachment data and incorrectly adding the remote URL. Might be a case reproducing and then deactivating plugins one by one until you can’t reproduce it.