humanmade
Added s3_uploads_s3_client filter to be able to change the S3Client
We added the ability to filter the S3Client returned by the s3() function. This allows us to switch the S3Client and provide it with different credentials, region and endpoint. We have a site where not all files are stored on the same S3 provider, and using the sample function below then gives us the ability to load another set of credentials. It would be great if you could merge this functionality in the main repo.
Sample function:
add_filter('s3_uploads_s3_client', function ($client)
{
//Create new S3Client with other params
$params = [ 'version' => 'latest' ];
$params['credentials']['key'] = self::$s3_key;
$params['credentials']['secret'] = self::$s3_secret;
$params['signature'] = 'v4';
$params['region'] = self::$s3_region;
$params['endpoint'] = self::$s3_endpoint;
$params['use_path_style_endpoint'] = true;
$params['debug'] = false;
$client = null;
$sdk = new Aws\Sdk( $params );
$client = $sdk->createS3();
return $client;
});
Sorry, I didn't see your message before @joehoyle . We can't do this with s3_uploads_s3_client_params as that only allows overriding the credentials, signature version, region and proxy settings. We need to be able to switch the endpoint/bucket.
@SeBsZ those should also be part of params, we do this for example in Altis Local Server: https://github.com/humanmade/altis-local-server/blob/bc5916aa6c04f329933d12f415f7ea574166d68b/inc/namespace.php#L30-L35
@joehoyle I finally had time to dive back into my code and figured out why we couldn't use s3_uploads_s3_client_params. That filter only gets called once at the start of a page-load or at the start of a script. Located in get_aws_sdk(), that filter only gives one opportunity to set/override the s3 client params.
What we needed was the ability to override and switch client params at potentially every S3 call. We have a script that goes through all the files we have stored on S3 servers (which may be different servers across the world, in different buckets). When the script loops through the files, it needs to be able to switch client params on the fly. We did this by adding our own filter in s3().
Hopefully this makes more sense now. Let me know if you can think of another way we could do this.
Ahh ok, yes that makes sense, yes I think we do this for performance -- however I can see the argument for having a filter you can change on an ongoing basis. I think you should also achieve this by provider your own S3Client subclass which does whatever logic you would want on a dynamic basis.
@joehoyle So do you think there is a chance this PR will get merged upstream in its current form?
