Jason

Imsanity doesn’t check directories for files – it looks in the wp-meta table for entries. So it only works with files uploaded through the WordPress core API.

I doubt hungryfeed is responsible, however if you want to be sure – simply delete the wp-content/plugins/hungryfeed folder temporarily (make a backup copy first)

deleting the folder will disable the plugin (same goes for any other plugins as well)

Imsanity will use its own quality setting for the full size image, but WordPress itself will use the WordPress media settings for quality of the additional generated images. So they don’t have to be the same.

Haven’t heard about image size limits in core WordPress. I’d be happy to see it even if it made imsanity obsolete. There really should be an automatic scaling option.

Yes unfortunately with Imsanity there is a double-compression of the WordPress optimized sizes because Imsanity takes over before any of the other WordPress operations have happened.

Hmm, usually that is due to the uploader (like woocommerce) maintaining it’s own file uploader that doesn’t’ not use the WordPress API system to handle uploads. In which case, Imsanity is never notified or fired off when uploading. In which case Imsanity doesn’t harm anything but unfortunately will not be able to resize those images.

Yea unfortunately it doesn’t work due to the way Gravity Forms manages it’s own file uploads. There’s a little more info here: https://www.ads-software.com/support/topic/will-this-work-for-photo-uploads-via-a-gravity-form?replies=4

Hmm, phone images sometimes have incorrect metadata as far as the rotation of the phone and it will trick the image processor.

You can test if the plugin is doing it by disabling the plugin, then upload. If it still does it then you know for sure it is the plugin.

Imsanity attempts to correct invalid rotation and usually does a pretty good job. If you have an image that is messing it up, if you can post it somewhere I can try to see if there’s a way to fix it in Imsanity.

Thanks

Thanks!

Imsanity actually helped to reveal and reproduce an error in WordPress core believe it or not. It looks like it’s now fixed and awaiting review so finally this annoying issue will be fixed for us all!

Here’s the issue on the WP bug tracker in case you want to follow it: https://core.trac.www.ads-software.com/ticket/34165

Insanity doesnt search in folders to find images. It searches the wp_attachments table in MySQL.

If there’s images outside of the standard location then that would tell me they’re uploaded using a custom plugin or API and doesn’t inform WordPress about them. In that case Imsanity bulk processor won’t be able to find them.

You might be able to resize them with a shell script or something though. I’d check with the plugin author that is creating those images for suggestions.

One reason Imsanity won’t resize an image is if the resized version is actually larger in size (disk size, not pixel size). This can happen due to your JPG quality settings.

For example if you upload a 2000px image that is ultra-compressed, when imsanity creates a 1000px image with JPG default quality of 90 – the disk size may actually be larger. In this case, Imsanity keeps the original and doesn’t resize.

If you’re talking about mobile, there is a bug that’s been reported to WordPress where it’s not working on all installs. Hopefully they’ll address that in the API. See https://core.trac.www.ads-software.com/ticket/34165

Yes, nice find! Hopefully they will notice the issue and get that fixed.

If you disable Imsanity and upload an image exactly 1048 – again the bug happens.

I didn’t look into the code of WordPress, but what seems to be the case is when the “original” and the “large” size image are very close in size to each other – then the bug is triggered. Hopefully the WP devs will take a look into this.

I created a WordPress ticket at https://core.trac.www.ads-software.com/ticket/35085

oh, haha – i think you actually found a bug with WordPress.

If you disable Imsanity – but upload an image that is already resized to 1024 px – then your bug appears.

So it seems this is a bug with wordpress when the size of the image is exactly the same as the “max” in the media setting.