Unfortunately, I can’t reproduce this behavior. Could you please link to an image where I can see this? If this is still an issue, could you please also add your ResizeFly settings to this issue via the following MySQL query:
SELECT option_name, option_value FROM wp_options WHERE option_name LIKE "resizefly%";
Please see https://www.nambaheins.de/uploads/resizefly/2018/06/nh-start-100×0@1.jpg for an image that works this way.
-
This reply was modified 3 years, 4 months ago by
alpipego.
Is the 100×0@1.jpg written to the resized folder? The 0 is replaced here with the resized value (which happens in Handler->parseRequestedImageSize()). The next time i call this image, it’s going through php again, creating an unnecessary added delay.
I fixed this for myself in resizefly by using REQUEST_URI in Handler->setImageName().
option_name option_value
resizefly_options a:2:{s:5:"cache";a:3:{s:6:"suffix";s:7:"resized";s:4:"path";s:68:"/www/****/public_html/wp-content/uploads/resized";s:3:"url";s:58:"http://****/wp-content/uploads/resized";}s:10:"duplicates";a:2:{s:6:"suffix";s:19:"resizefly-duplicate";s:4:"path";s:80:"/www/****/public_html/wp-content/uploads/resizefly-duplicate";}}
resizefly_purge_cache
resizefly_remove_resized
resizefly_resized_path resized
resizefly_restrict_sizes
resizefly_sizes a:4:{s:9:"thumbnail";a:4:{s:6:"active";b:1;s:5:"width";i:150;s:6:"height";i:150;s:4:"crop";b:1;}s:6:"medium";a:4:{s:6:"active";b:1;s:5:"width";i:300;s:6:"height";i:300;s:4:"crop";b:0;}s:12:"medium_large";a:4:{s:6:"active";b:1;s:5:"width";i:768;s:6:"height";i:0;s:4:"crop";b:0;}s:5:"large";a:4:{s:6:"active";b:1;s:5:"width";i:1024;s:6:"height";i:1024;s:4:"crop";b:0;}}
resizefly_sizes_outofsync a:3:{s:3:"new";a:0:{}s:7:"updated";a:0:{}s:7:"missing";a:0:{}}
resizefly_user_sizes a:0:{}
resizefly_version 3.0.0
resizefly_version_initial 2.1.4
resizefly_version seems to be 3.0.0 in database but resizefly.php tells me it’s 3.1.0.
I now understand what you’re getting at:
It’s true that the image is written as e.g. 100×67@1.jpg to the uploads folder because that is the image size being created.
You want the image to actually be written as imagename-100x0@1.jpg
to the filesystem… In my design so far, the request to 0
image sizes always implied a PHP-roundtrip.
I’ll have to think about if it’s reasonable to create two image sizes whenever a 0
-size is requested.
Can you share how you changed the code in Handler->setImageName()
?
(Thanks for catching the bug in the 3.0.0/3.1.0 version number).
-
This reply was modified 3 years, 4 months ago by
alpipego.
-
This reply was modified 3 years, 4 months ago by
alpipego.