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.
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.
In my case I was trying to get PHP playing nicely with my FuelPHP app running on Apache under FCGId configured via Virtualmin. My .htaccess looked like:
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php/$1 [L]
</IfModule>
The fix was annoyingly simple and took me hours of digging to discover. Insert a question mark before the slash after index.php like this:
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php?/$1 [L]
</IfModule>
Alternatively you can also get it to work WITHOUT adding in the question mark by changing from FCGid to CGI (if configuring via Virtualmin: Server Configuration: Website Options: PHP script execution mode from “FCGId” to “CGI wrapper”) but if you want it to work in FCGid mode you will need the question mark. I do not know why this is the case though.
I had never noticed before that submitting a form with unchecked checkboxes in it results in those checkboxes not being sent to the server at all. I had always assumed that a zero ( 0 ) would be sent for unchecked since a one ( 1 ) is sent when checked. Rather than add code to specifically handle these individual checkboxes, you can just add hidden inputs above the checkboxes in the HTML with a value of zero like this:
<input type="hidden" name="box1" value="0" /> <input type="checkbox" name="box1" value="1" />
This is a much simpler solution that doesn’t require writing any additional code or sending an array of checkboxes. I chose this method since I was using an automated Settings saver in PHP so it would be a pain to modify it and it could make the code more dirty.
Thanks to iamcam for writing about this.