Right, you need to intercept the file after it’s placed on the server but before WP extracts EXIF data and generates multiple sized images. I’m not sure of how the entire sequence works, but as a guess, try hooking into the ‘wp_handle_upload’ filter, where you are passed an array containing file path info. Apply your referenced script to this file and hopefully that’ll be all that’s needed.
@bcworkz thanks for your reply it was pretty helpful. I did some digging about wp_handle_upload/ It looks like it is not something you can add a filter to (technically?) but there is a way to hook into it: http://codex.wordpress.org/Plugin_API/Filter_Reference/wp_handle_upload_prefilter
add_filter('wp_handle_upload_prefilter', 'custom_upload_filter' );
So I cracked open functions.php and added this:
add_filter('wp_handle_upload_prefilter', 'exifRotate' );
function exifRotate( $file ){
$file = wp_handle_upload($file);
$file = exif($file);
}
function exif($file) {
//This line reads the EXIF data and passes it into an array
$exif = read_exif_data($file['file']);
//We're only interested in the orientation
$exif_orient = isset($exif['Orientation'])?$exif['Orientation']:0;
$rotateImage = 0;
//We convert the exif rotation to degrees for further use
if (6 == $exif_orient) {
$rotateImage = 90;
$imageOrientation = 1;
} elseif (3 == $exif_orient) {
$rotateImage = 180;
$imageOrientation = 1;
} elseif (8 == $exif_orient) {
$rotateImage = 270;
$imageOrientation = 1;
}
//if the image is rotated
if ($rotateImage) {
//WordPress 3.5+ have started using Imagick, if it is available since there is a noticeable difference in quality
//Why spoil beautiful images by rotating them with GD, if the user has Imagick
if (class_exists('Imagick')) {
$imagick = new Imagick();
$imagick->readImage($file['file']);
$imagick->rotateImage(new ImagickPixel(), $rotateImage);
$imagick->setImageOrientation($imageOrientation);
$imagick->writeImage($file['file']);
$imagick->clear();
$imagick->destroy();
} else {
//if no Imagick, fallback to GD
//GD needs negative degrees
$rotateImage = -$rotateImage;
switch ($file['type']) {
case 'image/jpeg':
$source = imagecreatefromjpeg($file['file']);
$rotate = imagerotate($source, $rotateImage, 0);
imagejpeg($rotate, $file['file']);
break;
case 'image/png':
$source = imagecreatefrompng($file['file']);
$rotate = imagerotate($source, $rotateImage, 0);
imagepng($rotate, $file['file']);
break;
case 'image/gif':
$source = imagecreatefromgif($file['file']);
$rotate = imagerotate($source, $rotateImage, 0);
imagegif($rotate, $file['file']);
break;
default:
break;
}
}
}
// The image orientation is fixed, pass it back for further processing
return $file;
}
The code above really just borrwed from rtmedia’s post that I mentioned in the first post above.
I hope it works, I dont have an iphone to test but the website has decent traffic so should know by the end of this weekend.
Talk about trial by fire!
It should be more efficient using ‘wp_handle_upload’ filter than the prefilter version. The filter call occurs at the very end of the wp_handle_upload() function definition just before the return, line 351 in v3.6 wp-admin/includes/file.php. You should not have to call wp_handle_upload() this way.
But if your version is working without unreasonable delay, why try to “fix” it?
