It’s not often that removing something from a product is a cause for great cheer, but with the removal of the dependency on the Amazon Web Services plugin in the latest release of WP Offload S3, we think everybody is going to be very happy! ‎🎉

As well as a bunch of bug fixes, this release also includes improved support for sites with an identity crisis and a certain plugin that changed the way it regenerates thumbnails.

What We’ve Done

WP Offload S3 no longer requires the Amazon Web Services plugin because we’ve stripped down the AWS PHP SDK to the parts we need, namespaced it, and included it in the WP Offload S3 plugin itself.

Why Remove The Dependency?

There are a few reasons why WP Offload S3 needed to stop depending on the Amazon Web Services plugin.

By far the biggest reason is to eliminate conflicts with other plugins that also include a version of the AWS PHP SDK. It seems to be quite common for backup or sharing plugins to bundle v3 of the AWS PHP SDK for example. This can cause failures in WP Offload S3 or failures in the other plugin that is loading the SDK. WP Offload S3 now includes a uniquely namespaced AWS PHP SDK v2 that eliminates this problem.

Another reason for removing the dependency on the Amazon Web Services plugin was unfortunately highlighted by our most recent release of WP Offload S3 and the AWS plugin. When we released Amazon Web Services 1.0.4 and WP Offload S3 1.5.1 as part of the new Assets pull addon’s release, we included some changes that meant they both needed to be updated at the same time as some functionality was moved from one to the other. Even through both our extensive automated and manual testing we never noticed that if the AWS plugin was updated first it broke the update checking in version 1.5 and earlier of the WP Offload S3 plugin. This left many customers frustrated by a notice that said v1.5.1 of WP Offload S3 was required, but WP Offload S3 1.5 kept saying that it was the latest version. Suffice to say, having a plugin that depends on another plugin for core functionality adds complexity and is not ideal.

We’ve decided to leave the Amazon Web Services plugin alone so as to not break other people’s code that hooks into it, and will only update the version of the SDK we’ve now embedded in WP Offload S3. There are some features we have planned for WP Offload S3 that will require using v3 of the AWS PHP SDK instead of v2 as currently provided by the Amazon Web Services plugin. The problem is we can’t just update the version of the AWS PHP SDK in the AWS plugin to v3 as it is not backwards compatible with v2, meaning any other plugins that currently depend on the AWS plugin would likely break with such a change. We also know of some sites that depend on the current AWS plugin for custom functionality.

And lastly, weight. There’s a noticeable delay when installing the Amazon Web Services plugin through the WordPress admin dashboard while it downloads all 2.3Mb of the plugin, of which only a small subset of its functionality is actually used by WP Offload S3. We have stripped down the AWS PHP SDK that is bundled with WP Offload S3 1.6 to just the S3 functionality and its supporting libraries. Unfortunately those supporting libraries are still reasonably weighty, but we’ve still managed to slim down that 2.3Mb to just under 1Mb.

How Did We Embed the AWS PHP SDK?

We expect there’s a few of you wondering how we managed to bundle the AWS PHP SDK into WP Offload S3 while still claiming that it’s not going to interfere with other plugins that also bundle a version of the SDK? And how on Earth did we strip out everything bar the S3 functionality and its dependencies from the SDK?

Magic!

Don’t believe me? Well, alright then, I’ll spill the beans. We now have a single script that pulls down the AWS PHP SDK, removes everything from it except the S3 and common library files, and then applies our own namespace to all the remaining PHP files.

Composer plays a big part in this script, it’s used to download the latest version of the AWS PHP SDK in the v2.8 branch, to install the php-scoper tool that namespaces all the files, and to generate a new autoloader for the updated files.

If you take a look at the script you’ll see that the SDK files now have a namespace prefixed with DeliciousBrainsWP_Offload_S3Aws2. By including both our company and product name in the namespace we pretty much guarantee no clashes with other plugins! By including Aws2 in the namespace it gives us not only the ability to potentially include different major versions of the AWS SDK should we need to, but also sets a precedent should we end up bundling SDKs for other storage providers.

Any Other Changes?

As well as a bunch of bug fixes, there are a couple items in the changelog that deserve highlighting.

Settings tab

After bundling the SDK into WP Offload S3, we needed to move some of the functionality that was provided by the Amazon Web Services plugin into it. In particular the page for setting or viewing the AWS Keys and its underlying functionality needed to be absorbed into WP Offload S3, so now we have a shiny new “Settings” tab that’s also where you can enter your license key.

The old AWS Keys page in the Amazon Web Services plugin didn’t let you confirm which key you’d defined in your wp-config.php file, it just said you’d done so without showing any details. This new one shows the AWS Access Key ID, which is handy when juggling staging and production sites and you want to be sure that the correct keys are being used in each.

We’ve moved the menu item for the WP Offload S3 settings page under the “Settings” menu in the WordPress admin dashboard seeing as the AWS menu might not be available. Never fear, if you’re still using the AWS plugin for some reason you can still use it for quick access to WP Offload S3’s settings.

Multiple Domains Support

If your WordPress site has multiple domains and content authors access it from any one of them, you might end up with URLs in your database content that do not have the same domain as saved in the “Site URL” setting. This means WP Offload S3 will not be able to recognize some URLs as belonging to the local site and will not filter them to their S3 equivalent.

If you’re using something like the following code in your wp-config.php file then you might be seeing this problem.

define( 'WP_SITEURL', 'http://' . $_SERVER['HTTP_HOST'] );
define( 'WP_HOME', 'http://' . $_SERVER['HTTP_HOST'] );

Some methods of domain mapping might also produce this problem.

WP Offload S3 now has an ‘as3cf_local_domains’ filter that you can use to supply alternative domains that your site uses.

function as3cf_local_domains( $domains ) {
    $domains[] = 'wibble.example.com';
    $domains[] = 'wobble.example.com';

    return $domains;
}
add_filter( 'as3cf_local_domains', 'as3cf_local_domains', 10, 1 );

The first entry in the $domains array will be the primary domain that is configured for the site as accessed, you can check $domains[0] should you need to supply different alternate domains for any reason, such as for a subsite in a multisite network.

Regenerate Thumbnails v3 Support

WP Offload S3 has long integrated with the Regenerate Thumbnails plugin, but recently it was rewritten to use the REST API and broke our compatibility for when customers use the “Remove Files From Server” option.

WP Offload S3 now works with the Regenerate Thumbnails plugin again, and also introduces a neat new filter to support other plugins that use the REST API to do work on local files and therefore might need the remote S3 files temporarily copied back to the server.

You can use the as3cf_rest_api_enable_get_attached_file_copy_back_to_local filter to append REST API routes that need a local file to perform their work. By default the filter is called with an array containing just the route required for Regenerate Thumbnails, that being “/regenerate-thumbnails/vd+/regenerate/”. You’ll notice that it’s a regex compliant string, that “vd+” bit in the middle helps match Regenerate Thumbnails’ current “/regenerate-thumbnails/v1/regenerate/” route but will also match “v2” should that happen.

Looking Forward

With the bundling of the AWS PHP SDK into WP Offload S3 1.6 now done and dusted, we can push on with potentially supporting more than just Amazon S3 as the bucket provider. We’ll likely need to integrate AWS PHP SDK v3 for that to happen, and could potentially bundle other SDKs too. We are now in a good place to start that work.

If we were to make it super simple to support other remote storage providers other than Amazon S3, which provider would be top of your list? Let us know in the comments.