Image Handler 5 (for v1.5.5 - v1.5.8) Support Thread

[lat9]

That repeated message in the debug information, similar to:


calculate_size, file does not exist. ... returning images/categories/astinlautaaudiq3.jpg


Indicates that IH is not finding that file in your store's file-system. Do you have any .htaccess modifications in the root of your store's file-system?

[OopsIbrickedIT]

Hi,

yes we did had to add .htaccess because we were pestered with hundreds of hits from nonbehaving robots:

ExpiresActive On
# Format: A where n is a number of seconds. Expires cache n seconds after access
# A2629740
ExpiresByType application/javascript A2629740
ExpiresByType application/x-javascript A2629740
ExpiresByType text/javascript A604800
ExpiresByType text/css A604800
ExpiresByType image/gif A900
ExpiresByType image/x-icon A900
ExpiresByType image/icon A900
ExpiresByType image/jpg A900
ExpiresByType image/jpeg A900
ExpiresByType image/png A900

SetEnvIfNoCase User-Agent .*rogerbot.* bad_bot
SetEnvIfNoCase User-Agent .*exabot.* bad_bot
SetEnvIfNoCase User-Agent .*mj12bot.* bad_bot
SetEnvIfNoCase User-Agent .*dotbot.* bad_bot
SetEnvIfNoCase User-Agent .*gigabot.* bad_bot
SetEnvIfNoCase User-Agent .*ahrefsbot.* bad_bot
SetEnvIfNoCase User-Agent .*sitebot.* bad_bot

<Limit GET POST HEAD>
Order Allow,Deny
Allow from all
Deny from env=bad_bot
Deny from 110.0.0.0/8
Deny from 111.0.0.0/8
Deny from 112.0.0.0/5
Deny from 120.0.0.0/6
Deny from 124.0.0.0/8
Deny from 125.0.0.0/8
Deny from 147.0.0.0/8
Deny from 46.4.62.121
Deny from 46.229.168.139
Deny from 88.99.250.124
Deny from 46.229.168.163
Deny from 46.229.168.149
Deny from 144.76.68.88
Deny from 88.99.250.124
Deny from 46.229.168.0/8
Deny from 46.4.62.0/8
Deny from 46.4.62.0/8
Deny from 144.76.68.0/8
Deny from 46.229.168.0/8
Deny from 144.76.68.0/8
Deny from 46.229.168.0/8
Deny from 46.229.168.154
Deny from 46.229.168.0/8
Deny from 46.4.62.0/8
Deny from 46.4.62.121
Deny from 46.229.168.144
Deny from 46.229.168.145
Deny from 144.76.68.88
</Limit>

[lat9]

Can you verify that the image identified above does exist?

[OopsIbrickedIT]

Hi,

problem is that the old image handler also removed folders from /images like images/categories if I interpret log files right. There is only images folder left.

[lat9]

Hi,

problem is that the old image handler also removed folders from /images like images/categories if I interpret log files right. There is only images folder left.

Well, that s-cks! I wish I could help more, but my experience with IH-4 is very limited.

That at least explains why IH-5 can't display those images.

[OopsIbrickedIT]

Well, that s-cks! I wish I could help more, but my experience with IH-4 is very limited.

That at least explains why IH-5 can't display those images.

Yes it really does now I tried to recreate the folder structure from backup before image handler 4 installation and same folder disappearing happens also with IH5. Only thing I can think of which originates from old is the database and something is clearly wrong with some setting in it. This is just my hunch but perhaps only logical explanation.

I am in deep Rabbit Hole with this right now.

[OopsIbrickedIT]

I got an idea. How if I copy all of the images from old IH-4 bmz_cache to new shop images folder and turn before that the hashing off? Because seems that images from /images folder are also partly missing. Would that possibly work? the db references would be same.

[lat9]

Unfortunately, IH-4 has hashed those image-names upon creation in the /bmz_cache directory and it's not an easy/possible task to un-hash those names.

[OopsIbrickedIT]

Shouldn't the IH-5 be backward compatible with IH-4 regarding the bmz_cache? So we have all the image info in bmz_cache only and db should have the linking info. Problem persists but perhaps there is a solution. Should we possibly remove IH-5 and install older IH4_3_2 instead with same settings so we could use the old bmz_cache?

[barco57]

IH4 and IH5 use completely different naming for the bmz cached images. additionally, the bmz cached filenames are not stored in the database, only the original image filename is store in the database. I have been using image handler since it was first introduced and have never seen what you describe

"problem is that the old image handler also removed folders from /images like images/categories"

I don't even think there is a mechanism in code for image handler that would do that. When I do an upgrade I don't concern myself with the bmz cache folder, I leave it behind and start over fresh, because of things like new naming conventions. When changing image sizes on the site when tweaking the look of the site, I purge the bmz cache many times until I have everything the way I want it. I would love to know all of the steps to reproduce the issue of sub-folders in the iomages folder being deleted by image handler (any version). I know if one of my clients came to me and told me that I would tear the server logs apart to determine who nuked them by accident and is blaming it on image handler...