If you see this error after migrating from the v2 to v3 sdk change:
$s3client->deleteObjects( array(
'Bucket' => $settings['bucket'],
'Objects' => $fileKeys
) );
to:
$s3client->deleteObjects( array(
'Bucket' => $settings['bucket'],
'Delete' => array(
'Objects' => $fileKeys
)
) );
Note the new Delete array wrapping Objects. I discovered this while updating BackupBuddy.
If you’re upgrading from the v2 to v3 SDK or following the low level API documentation for Multipart uploads such as http://docs.aws.amazon.com/AmazonS3/latest/dev/LLuploadFilePHP.html you will run into an impassable error. I ran into this problem while working on adding the new S3 SDK into BackupBuddy.
Error executing “CompleteMultipartUpload” on “https://s3.amazonaws.com/[…]”; AWS HTTP error: Client error: `POST https://s3.amazonaws.com/[…]` resulted in a `400 Bad Request` response:
InvalidRequest
The problem is that the CompleteMultipartUpload function parameters have changed but Amazon has not updated their documentation properly and it is missing from their migration guide.
The “Parts” parameter now needs to be placed in a new array named “MultipartUpload”.
Incorrect parameters (as per documentation or v2 SDK):
$result = $s3->completeMultipartUpload(array(
'Bucket' => $bucket,
'Key' => $key,
'UploadId' => $uploadId,
'Parts' => $parts,
));
Correct parameters for v3 SDK:
$result = $s3->completeMultipartUpload(array(
'Bucket' => $bucket,
'Key' => $key,
'UploadId' => $uploadId,
'MultipartUpload' => array(
'Parts' => $parts,
),
));
I’ve posted a post in the S3 forums ( https://forums.aws.amazon.com/thread.jspa?messageID=740339򴯳 ) requesting Amazon update their documentation so this may be fixed there at some point. Special thanks to this StackOverflow post: http://stackoverflow.com/questions/30383982/aws-s3-completemultipartupload-error
Catchable fatal error: Argument 2 passed to Guzzle\Service\Client::getCommand() must be of the type array, string given, called in ../_s3lib2/Guzzle/Service/Client.php on line 76 and defined in ../_s3lib2/Guzzle/Service/Client.php on line 79
If you’re getting this error when working with the version 2 PHP SDK for Amazon Web Services’ S3 service, fear not. It’s probably as simple as you passing the wrong parameters into the function. In this example I was calling listObjects() using the old SDK’s parameters rather than the new SDK’s. Simply fix!
Wrong (eg. old SDK v1 way):
$response = self::$_client->listObjects( $settings['bucket'] );
Right (eg. new SDK v2 way):
$response = self::$_client->listObjects( array( 'Bucket' => $settings['bucket'], 'Prefix' => $prefix ) );
All fixed!
Problem
Upon trying to run some migrations in FuelPHP via command line with Oil I ran into this error message containing the error
Uncaught exception Fuel\Core\Database_Exception: No MySQLi Connection
I discovered that when running from the command line my normal php.ini was not being run. PHP was using the defaults, including the default mysql socket which was in the wrong place.
Solution
In my case I created a symlink to redirect which seems to have done the trick. I am running Mamp on OS X in default locations so your directories may differ.
cd /var/mysql
sudo ln -s /Applications/MAMP/tmp/mysql/mysql.sock mysql.sock
There may be a better fix and this may be a symptom of something else being ‘off’. I initially created a /etc/php.ini with the proper socket location directive but this did not work out properly, possibly due to permissions or something.