WP Offload Media plugin review and common issues

Existing media is not migrated automatically by the Lite version. In the Pro version, use the Assets > Bulk Actions > Offload to offload the existing media library to S3 and update all database references. For the Lite version, you need to manually upload existing files to S3 and update image attachment metadata. After the bulk offload completes, verify a sample of images load from the S3 or CDN URL in the browser. If some images still show local URLs, the URL rewriting may not have reached all custom field or plugin-specific storage locations — check with Delicious Brains support for those edge cases.

A 403 error on S3 files indicates bucket or IAM permission misconfiguration. Check: (1) the S3 bucket’s Block Public Access settings — if you want files publicly accessible, disable Block All Public Access and add a bucket policy allowing s3:GetObject for all principals (unless using CloudFront with Origin Access Identity); (2) the IAM user credentials used by WP Offload Media have the correct permissions: s3:GetObject, s3:PutObject, s3:DeleteObject, s3:ListBucket on the specific bucket ARN; (3) if using CloudFront, ensure the Origin Access Identity has permission to read from the S3 bucket.

WooCommerce stores additional image references in custom meta fields beyond the standard WordPress attachment metadata. After bulk offloading, run WooCommerce → Products → Re-generate Thumbnails (or use the Regenerate Thumbnails plugin) to ensure WooCommerce thumbnail sizes are uploaded to S3. Also verify that WP Offload Media’s URL rewriting covers woocommerce_thumbnail and product gallery meta fields. If the Pro version is active, use the Media Library view to confirm all WooCommerce-associated attachments show as offloaded.

In WP Offload Media Pro → Settings → Delivery Provider, select Amazon CloudFront as the delivery provider. Enter your CloudFront Distribution Domain (e.g., d1234abcd.cloudfront.net). Create a CloudFront distribution in AWS console with your S3 bucket as the origin. If the S3 bucket has public access blocked, create an Origin Access Control (OAC) in CloudFront and attach it to the distribution, then update the S3 bucket policy to allow CloudFront read access. Once configured, all media URLs will use the CloudFront domain, serving files from the nearest edge location to each visitor.

Yes — WP Offload Media has a “Remove Local File” option that controls whether the local copy is deleted after successful offloading. In Settings → General, enable or disable “Remove Local File” based on your preference. Keeping local copies increases disk usage but provides a fallback if S3 access is unavailable. Removing local copies reduces server disk usage (the primary reason for offloading) but means media is only accessible via S3 if the cloud connection is unavailable.

Amazon S3 charges approximately $0.023 per GB per month for standard storage in US regions. A typical WordPress media library of 10GB costs roughly $0.23/month in storage. Bandwidth costs apply when files are served directly from S3 ($0.09 per GB after the first 100GB free tier) — using CloudFront CDN reduces bandwidth costs and improves global delivery. For most WordPress sites, combined S3 storage and CloudFront costs are well under $5/month.

Yes — WP Offload Media Pro supports custom CDN domain configuration, which works with Cloudflare. Set up Cloudflare as a CDN proxy in front of your S3 bucket (by pointing a subdomain to S3 through Cloudflare’s DNS), then enter the custom Cloudflare subdomain in WP Offload Media’s delivery provider settings. Alternatively, use Cloudflare R2 (S3-compatible storage) as your offload destination, which eliminates S3 egress fees.

Yes, that can happen, especially on older sites with many plugins. This usually happens when the plugin, theme, and add-ons are updated out of sequence. In most cases, testing on staging catches the issue before it reaches the live site. From experience, backups and changelog reviews save a lot of cleanup time.

Start by checking whether another plugin already does the same job. In most cases, overlap is what creates avoidable conflicts and performance issues. A common issue is installing a plugin because it looks convenient without checking the stack first. From experience, a short compatibility review avoids most of the pain later.