Delicious Brains

That’s great to hear, thanks for letting us know.

-IJ

Signed private URLs expire within a few minutes, so would be useless to non-members.

The default expiry time for private WooCommerce and Easy Digital Downloads product files is 5 seconds via their Pro integrations, but otherwise the default is 15 minutes (900 seconds).

You can change the default expiry interval via the as3cf_expires filter: https://github.com/deliciousbrains/wp-amazon-s3-and-cloudfront-tweaks/blob/dc229fc8e381b0bec2a84ca92fa10f30d193ec00/amazon-s3-and-cloudfront-tweaks.php#L974

-IJ

While serving private media via CloudFront requires setting up a Private Path Prefix in WP Offload Media, how Media Library items are made private isn’t changed. You toggle each item as public/private separately, unless you choose to implement a filter and offload everything as private.

How to Serve Private Media via Signed Amazon CloudFront?URLs: https://deliciousbrains.com/wp-offload-media/doc/serve-private-media-signed-cloudfront-urls/

How to Restrict Access to Offloaded?Media (custom filters): https://deliciousbrains.com/wp-offload-media/doc/how-to-restrict-access-to-offloaded-media/#custom-filters

Please remember that serving private media via CloudFront is a Pro feature.

-IJ

WP Offload Media stores offloaded items in the external cache if available, how many offloaded items do you have?

If you run your Redis scan looking for “as3cf_items” instead of “s3” you’ll see the cached offloaded items count.

WP Offload Media also uses postmeta records associated with posts and pages to cache URL to offloaded item ID & type mappings, which are also likely to be cached externally by WordPress. How many posts and pages do you have?

If you run your Redis scan looking for “amazonS3_cache” instead of “s3” you’ll see the cached postmeta records.

-IJ

The version of the AWS PHP SDK (v3.279.0) that is embedded in WP Offload Media v3.2.5 should work fine with IMDSv2, and from what I can tell uses that by default.

You should not need to set up any cURL calls etc, when using server roles the SDK’s credentials provider should internally set up the IMDSv2 session token and retrieve the metadata as required.

However, when we use instance metadata version 2, the plugin seems unable to retrieve the information.

1. Please supply details of the errors you see, ideally debug.log entries.
2. Please confirm what version of WP Offload Media you’re using.
3. Please post Diagnostic Info from WP Offload Media’s Support tab. (if you’re not comfortable with this, and have a license, please submit a support request via the plugin’s Support tab linking to this support request and mentioning Ian Jones asked for Diagnostic Info)

-IJ

Hey @rgg909090,

I’m a little confused, you linked to a Gist that uses Access Key ID and Secret Access Key, but as you’re running on EC2 and can attach an IAM Role to the instance, you should be using the Use Server Roles setting:

define( 'AS3CF_SETTINGS', serialize( array(
    'provider' => 'aws',
    'use-server-roles' => true,
) ) );

https://deliciousbrains.com/wp-offload-media/doc/iam-roles/#ec2

Have I got things wrong, and you are using server roles via the above use-server-roles setting?

If so, what are you storing in the instance metadata that relates to WP Offload Media?

-IJ

@masonspeed please can you post more details as to how you found the memory leak?

What tools did you use, and do you have a report that shows WP Offload Media being the source of the leak?

When you disable WP Offload Media does the memory leak issue stop?

Can you post Diagnostic Info or Site Health Info, and is anything posted to debug.log while the memory leak is happening?

-IJ

@ericcumbee are you using a multisite or single site install?

Is the user you’re logged into WordPress with an admin?

Please can you post your Site Health Info?

-IJ

Hey @asheroto,

Looks like our custom IAM policy doc was not up to date, sorry.

I’ve updated the Custom IAM Policy for Amazon SES doc: https://deliciousbrains.com/wp-offload-ses/doc/custom-iam-policy-for-amazon-ses/

You’ll see from the doc that you need to have separate sections when using a specific resource, something like follows:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "IdentityManagement",
      "Effect": "Allow",
      "Action": [
        "ses:CreateEmailIdentity",
        "ses:DeleteEmailIdentity"
      ],
      "Resource": "arn:aws:ses:eu-west-2:123456789012:identity/example.com"
    },
    {
      "Sid": "SendEmail",
      "Effect": "Allow",
      "Action": "ses:SendRawEmail",
      "Resource": "arn:aws:ses:eu-west-2:123456789012:identity/example.com"
    },
    {
      "Sid": "AccountLevel",
      "Effect": "Allow",
      "Action": [
        "ses:GetAccount",
        "ses:ListEmailIdentities"
      ],
      "Resource": "*"
    }
  ]
}

-IJ

Hey @mista-flo,

WP Offload Media is compatible with PHP 7.2 through 8.2.

We routinely run both PHPStan and PHP Code Sniffer against the code base, and have never hit that error.

Looking at the code, I don’t think that error applies either, as in each case there’s no call of a variable on a variable, they’re all simple variable substitutions.

What version of phpcompatibility/php-compatibility are you using?

-IJ

Hey @waseem_senjer,

With WP Offload SES and WP Offload SES Lite 1.6.6, if you return an empty array from the wp_mail filter, the plugin will no longer try and queue and send the email.

This means you can now cleanly stop an email from being sent based on some condition, such as the $to variable’s contents.

-IJ

This has been fixed in WP Offload SES & WP Offload SES Lite 1.6.6 ??

-IJ

Hey @gif1,

There’s a couple of things that users of Cloudflare often trip up on.

The bucket name must be the same as the domain that it’s media is going to be served from. E.g. for site “example.com” where the media is to be served from the domain “cdn.example.com”, the bucket must be named “cdn.example.com”.

The second thing people trip up on is setting up Cloudflare’s DNS entry for the CNAME, it must include the bucket’s region in the amazonaws.com domain, unless the bucket’s region is us-east-1.

So for the London bucket region, eu-west-2, the CNAME target might be:

cdn.example.com.s3.eu-west-2.amazonaws.com

But if you’re using the default us-east-1 region for the bucket, then it should not include the region:

cdn.example.com.s3.amazonaws.com

The above, and some details on setting up HTTPS etc are in our Cloudflare Setup for Amazon S3 doc: https://deliciousbrains.com/wp-offload-media/doc/cloudflare-setup/

If that doesn’t help, please post your site’s Diagnostic Info from the Help tab in WP Offload Media, and I’ll take a look to see if I can spot a problem.

-IJ

Hey @wmnf,

Please can you double-check that the site’s access key defines are above the following comment in the wp-config.php file?

/* That's all, stop editing! Happy publishing. */

-IJ

Please can we see Diagnostic Info from WP Offload Media’s “Support” tab, and debug.log output captured during a failed “Check again”?

https://deliciousbrains.com/why-use-wp-debug-log-wordpress-development/

-IJ