WP Offload Media 2.4 Released: Private Media with a Custom Domain and Amazon CloudFront

#
By Brad Touesnard, Founder & CEO

This is a big release, six months in the making…well, really 5 years in the making! Check out the date on this GitHub issue 😱…

CloudFront support for private files GitHub issue showing an open date of August 27, 2015

We’re so excited to finally support the ability to serve private media through Amazon CloudFront and with a custom domain to boot! 🎉

Your private media can now be served lightning fast and have professional looking URLs like this:

https://cdn.sandwichcity.com/wp-content/uploads/2020/06/11191916/course.zip

Instead of this:

https://cdn-sandwichcity-com.s3.ca‑central‑1.amazonaws.com/wp-content/uploads/2020/06/12125257/course.zip

This release consists of 8 new features, 5 improvements, and 17 bug fixes.

Delivery Provider Settings

WP Offload Media has long had the option to configure Amazon CloudFront with a custom domain…

Version 2.3 of WP Offload Media showing the URL rewriting options

The problem was that only public media would be served via CloudFront. Any private media would be served directly from Amazon S3, which is slow. In today’s release, that changes.

When you upgrade to 2.4, you’ll see that the URL Rewriting section has been renamed to Delivery and there’s a new Provider setting. If you’ve configured Amazon CloudFront or another Content Delivery Network (CDN) as we recommend, this setting will be set to Other because we don’t know what CDN you have configured:

Version 2.4 of WP Offload Media showing the Provider and ability to change it

Clicking the Change link will allow you to define your actual Delivery Provider:

options screen to define your delivery provider

As you can see, we highly recommend Amazon CloudFront, but other CDNs are also fine if you’re not serving private content. If you’re still using Amazon S3 for delivery, you really should adopt Amazon CloudFront or another CDN.

Block All Public Access to Your Amazon S3 Bucket

If you choose Amazon CloudFront as your delivery provider, you’ll be asked to confirm your bucket settings (clicking the Save Bucket Setting button is usually sufficient here), and then asked if you’d like to enable Block All Public Access on your bucket:

WP Offload Media settings screen showing a notice if Block All Public Access is disabled

Block All Public Access is a relatively new setting that Amazon has been strongly encouraging its customers to enable to prevent direct public access to a bucket and promote better security. It can be enabled on a per-bucket basis or at the account-level to apply to all buckets.

Previously, WP Offload Media didn’t support Block All Public Access at all and you were instructed to disable it to get your bucket working with the plugin. We now recommend using Amazon CloudFront and enabling it, but only after you’ve set up the required Origin Access Identity and bucket policy. If you’re not using Amazon CloudFront, you shouldn’t enable it. We’re very happy to now be in alignment with Amazon’s recommendations.

If you choose to skip enabling Block All Public Access for now, you can always get back to the screen above to enable it later by clicking the Change link next to your bucket settings:

WP Offload Media settings screen showing a change link next to the Bucket settings

As before, you’ll be asked to confirm your bucket settings before being able to change the Block All Public Access setting.

Also, notice that you can see the current state of your bucket’s Block All Public Access setting under the Storage settings:

settings screen shows the status of Block All Public Access under the Bucket settings

Private Media Served via Custom Domain and Amazon CloudFront

If you choose Amazon CloudFront as your delivery provider and configure a Custom Domain, you’ll notice there’s a new Private Media toggle switch among the Delivery settings. Toggling that on will reveal more settings:

more Private Media settings revealed within Delivery Settings

The first two fields are for the keys that you get when you set up URL signing in Amazon CloudFront. See our documentation on this for more details.

The Private Path field defines a custom bucket path to prepend to your private media. An Amazon CloudFront behaviour is then set up to restrict access to files at this path to signed URLs only. The Private Path is required for private media to work.

Move Private Media to Private Path

If you turn on Private Media and configure those settings, you’ll get the following prompt asking if you want to move your existing private media to the new private path:

prompt displayed within the Media Library settings

We recommend choosing “Yes” here to keep the paths of all your private media consistent. Choosing “Yes” will kick off a background process to move your media:

settings will display as greyed out along with a notification when the move is executing

You won’t be able to edit settings or run any other WP Offload Media tools while the move is executing. However, because the move is processing in the background, you can navigate away from this screen and it will continue.

Move Existing Media to New Path

We also extended this functionality to any updates to the storage path. Previously, if you updated the storage path it would only affect newly uploaded media. Any existing media would remain on the old path. In version 2.4, if you change the Path, Year/Month, or Object Versioning storage settings, you will now be presented with the following prompt:

prompt displaying option to move existing media to new path and warning

As you can read in the screenshot above, we don’t recommend moving existing media because it can result in broken links on third-party sites and a negative impact to SEO. But if you do choose to move existing media, you’ll see a screen like this:

settings screen displaying all options as greyed out with notification during the move

Bulk Actions Tidied Up

The bulk actions UI has been looking pretty messy as we’ve added more and more buttons:

media library screen in WP Offload Media 2.3 showing multiple on demand buttons

In 2.4, we’ve condensed all the WP Offload Media actions into a combo button:

media library screen in WP Offload Media 2.4 showing all options in a drop down button

Improved Performance

Some of our customers have had performance issues with their site (mostly very busy sites and large multisite installs) and narrowed it down to WP Offload Media being the cause. We spent a lot of time and effort investigating and managed to hunt down a few bugs that are likely to be the cause of these problems. We’re confident the performance issues have been resolved for most customers.

And Much More

We’ve also updated SDKs, added new regions for S3 and GCS, fixed 17 bugs, and lots more. Check out the changelog for all the details.

Next Up

We’ll soon be shipping a 2.4.1 release with some integrations with third-party plugins that we punted to get 2.4 out, but after that we’ll be moving on to another ancient GitHub issue:

GitHub issue for Linking up files already uploaded to S3

Over the years, we’ve had quite a few customers who could have really used a tool to link up media that is already in a bucket. It’s high time we have this tool.

We also plan to add a setup wizard to make it far easier and convenient to set up WP Offload Media on a new site. For example, if you’re using Amazon CloudFront, currently you need to create the distribution and do all the configuration in the AWS Console. WP Offload Media is going to take care of that for you in the future. You should barely need to leave your WordPress dashboard at all.

So, stay tuned for all that. If you’re not already on our email list, be sure to subscribe.

Are you excited about the features we just launched or the ones we plan to launch next? What else would you like to see in WP Offload Media? Let us know on Twitter or in the comments below.

About the Author

Brad Touesnard Founder & CEO

As founder of Delicious Brains Inc, Brad has worn many hats. He now spends most of his time managing the product teams and growing the business. Before starting this company, Brad was a freelance web developer, specializing in front-end development.