The present scenario
We use the AWS SDK for PHP to retailer media recordsdata on S3 as an alternative of the server’s native storage, and use the wp_handle_upload filter to level the inserted attachment to the S3 file URL as an alternative of the native file path and delete the native file as nicely.
perform upload_to_s3( $add ) {
// MyS3Client, is a customized class that creates an S3Client object.
$s3client = new MyS3Client();
// myUploadMethod, is a customized technique that shops the file on S3 and return its path.
$s3_path = $s3client->myUploadMethod( $add );
// Delete the native file.
unlink( $add['file'] );
// Alter the file URL to level to S3.
$add['url'] = $s3_path;
$add['file'] = $s3_path;
return $add;
}
add_filter( 'wp_handle_upload', 'upload_to_s3' );
One thing else, we do not generate any resized thumbnails from the unique uploaded photos; as a result of we make the most of the AWS Serverless Picture Handler library to generate the wanted sizes on the fly and serve them through CDN.
// Disable producing any resized thumbnails for the uploaded picture.
add_action( 'intermediate_image_sizes_advanced', '__return_empty_array' );
So we insert these thumbnail sizes into DB manually; as a result of WordPress makes use of a few of them within the backend, like the photographs’ thumbnails within the Media Library web page, or the Media uploader type. At this level, we use the on-the-fly URL that may generate the thumbnails and retailer them on CDN.
perform generate_cdn_thumbnails( $metadata, $attachment_id, $context ) {
if ( $context === 'create') {
$attachment_path = parse_url( wp_get_attachment_url( $attachment_id ) )['path'];
$metadata['sizes'] = [
'thumbnail' => [
'file' => 'https://cdn.example.com/fit-in/150x150' . $attachment_path,
'width' => 150,
'height' => 150,
'mime-type' => 'image/jpeg',
],
'medium' => [
'file' => 'https://cdn.example.com/fit-in/300x300' . $attachment_path,
'width' => 300,
'height' => 300,
'mime-type' => 'image/jpeg',
],
'massive' => [
'file' => 'https://cdn.example.com/fit-in/1024x1024' . $attachment_path,
'width' => 1024,
'height' => 1024,
'mime-type' => 'image/jpeg',
],
];
}
return $metadata;
}
add_filter( 'wp_generate_attachment_metadata', 'generate_cdn_thumbnails', 10, 3 );
The issues
1. Generate the metadata of the picture earlier than unlink it.
We all know that WordPress can generate the metadata (width, peak, filesize, image_meta, …) of the native photos solely. So, both to generate them earlier than unlink the native file, or obtain the uploaded picture from S3 to the server to generate these knowledge.
At the moment we unlink the native file within the wp_handle_upload hook, so the file might be deleted earlier than producing the metadata within the wp_generate_attachment_metadata hook.
Is there any higher hook to make use of so we are able to unlink the file after producing its metadata? And methods to cross the total native path of the file to that hook to make use of it within the unlink perform?
2. Filter the resized CDN thumbnails URLs
Within the generate_cdn_thumbnails perform above, we retailer the total CDN URL of the thumbnails that might be generated on the fly. However when displaying these thumbnails within the backend (Media Library web page, for instance), WordPress prepends the folder path of the unique picture to that full URL.
Suppose we now have this URL of the thumbnail dimension picture:
https://cdn.instance.com/fit-in/150x150/2022/07/18/my_image.jpg
The unique (unlinked) picture folder path https://www.instance.com/wp-content/uploads/2022/07/18/ might be prepended to the thumbnail’s full CDN URL, so the thumbnail could have this closing URL (which is a damaged URL) when displaying it on the Media web page:
https://www.instance.com/wp-content/uploads/2022/07/18/https://cdn.instance.com/fit-in/150x150/2022/07/18/my_image.jpg
What’s the correct hook to make use of to filter and repair the thumbnail URL earlier than displaying it on the Media web page?
