Simply paste the following code on your functions.php file and save it. No other action is needed!
function replace_uploaded_image($image_data) {
// if there is no large image : return
if (!isset($image_data['sizes']['large'])) return $image_data;
// paths to the uploaded image and the large image
$upload_dir = wp_upload_dir();
$uploaded_image_location = $upload_dir['basedir'] . '/' .$image_data['file'];
$large_image_location = $upload_dir['path'] . '/'.$image_data['sizes']['large']['file'];
// delete the uploaded image
unlink($uploaded_image_location);
// rename the large image
rename($large_image_location,$uploaded_image_location);
// update image metadata and return them
$image_data['width'] = $image_data['sizes']['large']['width'];
$image_data['height'] = $image_data['sizes']['large']['height'];
unset($image_data['sizes']['large']);
return $image_data;
}
add_filter('wp_generate_attachment_metadata','replace_uploaded_image');
Thanks to Serge Rauberfor sharing his great tip with us!
2 Responses
Hi – this function worked wonderfully on my WP Multisite blog when placed in mu-folder and when using the WP media uploader …
but fyi – this function breaks when trying to use upload files outside the media uploader – e.g., when using other plugins like FormidablePro’s upload file function …
i had read this article that says there is WP bug with directory creation if no directory exists – meaning if WP media gallery upload had not yet created a directory for that month, then using an upload file function breaks ->
http://designoplasty.com/2011/05/05/wordpress-wp_upload_dir-function-bug-mkdir-no-such-file-or-directory/
not sure that is the case 100% but i did experience similar wierndess in that when uploading via plugin like Formidable Pro, this script broke and created a url for the “source file to be renamed” as non-existant …
you can read detail account about my initial experience here with breaking renaming file scenario ->
http://formidablepro.com/help-desk/warning-messages-when-updating-a-form-with-file-upload/
after much subsequent trial and error using other plugins and moving functions from mu folder to child theme function etc … i found this line of code to be the culprit ->
$large_image_location = $upload_dir['path'] . ‘/’.$image_data['sizes']['large']['file'];
in that this line generates a path to non-existent file – flakes out …
below is error message that was typical … essentially the first file path was correct but the second one was bogus – meaning a file uploaded on August 2011 never should have a 02 (february) month date as part of url path … ugh …
best i can determine is deep bug per the designoplasty.com author’s observations but ..??..
in the meantime, i did find that this plugin did the same trick (resizing large images on upload) but was more reliable on network sub sites and seemingly played nice with other plugins ->
http://wordpress.org/extend/plugins/imsanity/
to be continued … cordially, chuck scott
=============================
Example of Errors from bad
URL rename path
=============================
Warning: rename(
/home/saintjos/public_html/wp-content/blogs.dir/6/files/CIMG8950-1024×768.jpg,
/home/saintjos/public_html/wp-content/blogs.dir/6/files/2011/02/CIMG8950.jpg) [function.rename]: No such file or directory in /home/saintjos/public_html/wp-content/themes/prototype-cs-photos/functions.php on line 69
Warning: rename(/home/saintjos/public_html/wp-content/blogs.dir/6/files/2011/02/CIMG8950.jpg,/home/saintjos/public_html/wp-content/blogs.dir/6/files/formidable/2011/admin/CIMG8950.jpg) [function.rename]: No such file or directory in /home/saintjos/public_html/wp-content/plugins/formidable/pro/classes/helpers/FrmProAppHelper.php on line 637
- fin -
Hi, thank you for your wonderful snippet. I’m using it for my clients’ site, but unfortunately i was hitting the same problem which had been mentioned by Chuck Scott above. I spent some time tinkering the bug and realize that this was the problem: http://core.trac.wordpress.org/ticket/10752
IF you create a new post at current month and upload an image, there would be no problem. Suppose it’s august 2012 right now, so the image would be uploaded to:
/2012/08/ directory.
The problem arises when you edit your previous post that was published in let’s say january 2012
Instead of uploading the image to the 2012/08/ dir, WordPress will use post’s time as directory which is 2012/01/. I thought this was a bug, turned out that this was meant to be behaved this was as it has been mentioned at the trac above.
To solve this, this is what i’ve done. Replace this line:
$large_image_location = $upload_dir['path'] . ‘/’.$image_data['sizes']['large']['file'];
with this one
$large_image_location = $upload_dir['basedir'] . ‘/’ . substr($image_data['file'], 0, 8) . $image_data['sizes']['large']['file'];
So far i found that $image_data['file'] is the only data that carries the actual dir where the file is uploaded. If you guys found a better way to solve this, i’d be really glad to know it. Thanks.
Trackbacks: