tachyon-plugin
tachyon-plugin copied to clipboard
humanmade
Stripping image dimensions from file name.
It seems tachyon is experiencing some odd behaviour when the file name include a dimension. If the origianl file had a dimension portion of the file name, the request 404s, but the stripping itself leaves a px" remnant.
This is happening due to https://github.com/humanmade/tachyon-plugin/blob/master/inc/class-tachyon.php#L770, which will strip 300x600 from the end of a file name, because it "thinks" that is just a part added by WP, and that the original filename is not called that. As it happens, that's a bad assumption when the uploaded file name is actually my-image-300x600.jpg.
This is somewhat mitigated in Photon by a file_exists check in https://github.com/Automattic/jetpack/blob/master/class.photon.php#L1084, which maybe we removed for performance reasons. Note, that this fix doesn't totally work, as it you uploaded my-image-300x600.jpg and my-image.jpg, you'll now get the wrong image.
Maybe if we could somehow use the image ID to work out what the original image is better, then that would work? Just an idea.
Maybe if we could somehow use the image ID to work out what the original image is better, then that would work? Just an idea.
How do you propose doing that @joehoyle I know not all media has wp-image-* attached to it - we saw this on a client recently, it was being caused by Gutenberg, I'm sure we also will find other instances of this happening as well. So we can't always rely on that being available.
I also know that attachment_url_to_postid has performance issues... Maybe we do need that hm_attachment_url_to_postid was suggested last time attachment_url_to_postid was discussed.
Just a few thoughts. Also monitoring this issue to see what the solution will be out of interest :)
I think we'd use wp-image-* where possible, and then maybe fallback to file_exists.
I think we should remove any file name suffixes like 1200x800 on upload. Obviously doesn't solve this for already uploaded files but the fix right now is to rename and reupload the file anyway, this at least would mitigate the issue for future uploads.
As of WP 5.3.1 any files uploaded with a suffix like -123x456.jpg will have a -1 appended per wp_unique_filename(). That solves the issue for newer imports and projects more or less.
I have a proposed solution that tries matching on the attachment GUID to see if the image URL is the original one or not in #62 - it works but there are some performance concerns. In theory the cases where the lookup is used / needed should be somewhat limited.
Ideally we should recommend / provide a migration script to update image files with dimension suffixes.
We should document the use of this CLI command for fixing the issue:
https://github.com/humanmade/rename-images-command