Excess images

[marinestore]

We have a large housekeeping problem regarding image quantities. The site has been live since Miva 2, I think it was the last century when it first went up, and it now had an awful lot of jpegs in the graphics folders, heading on to 148,000 in total. The store has around 12,000 products and uses image machine which is showing around 9000 jpegs in use.

It's getting to the stage now where it needs condensing, FTP is a nightmare so a serious cull is required and I do not like the idea of doing it manually. Any one have any ideas?

Thanks...

[lesliekirk]

I'm thinking that the built-in Image Management should show you unreferenced images that you could delete. But I'm not sure if it only looks for images located in the "expected" locations that are usually uploaded to such as graphics/00000001

[marinestore]

It does but it only references those that it has added to the store, unfortunately it ignores all the others.

[jsdva]

I'm thinking that the built-in Image Management should show you unreferenced images that you could delete. But I'm not sure if it only looks for images located in the "expected" locations that are usually uploaded to such as graphics/00000001

Regardless of if only the graphics/00000001 folder, I would love to see this as a reality. Maybe even a search to allow for images that are inserted elsewhere.Big Dream.

[Brennan]

A few recommendations:

1. We will be addressing this in the core software where we automatically create sub directories inside the graphics/00000001 folder and limit them to 10k images per directory.
2. If you have legacy images which are no longer needed you can use the Image Management tool under utilities to delete any un-used images from the server to clean up some space.
3. If you wanted to, you can move the images to sub folders now, and re-import the paths via CSV. The downside to doing this is any auto-generated resized images will still go into the main graphics folder as well as images uploaded via the admin.

[marinestore]

Thanks Brennan
I like the sound of 1.
Re 2, the unused images are not showing on image management. If a product is deleted, the images with no references will show and these can be deleted. It ignores images that have not been previously referenced. Is this correct?
3 sounds like it could go horribly wrong, think I'll wait for 1!

[Miss Kate]

A few recommendations:

1. We will be addressing this in the core software where we automatically create sub directories inside the graphics/00000001 folder and limit them to 10k images per directory.
2. If you have legacy images which are no longer needed you can use the Image Management tool under utilities to delete any un-used images from the server to clean up some space.
3. If you wanted to, you can move the images to sub folders now, and re-import the paths via CSV. The downside to doing this is any auto-generated resized images will still go into the main graphics folder as well as images uploaded via the admin.

Okay, I ran into a big problem. With Ver10 a subdirectory created under graphics/00000001/1/ and it has caused all sorts of hell for me. All of the images I added relating to attributes and inventory variants went into that subdirectory. I have been banging my head against a brick wall trying to figure out why inventory count isn't working correctly when going from swatch to swatch. Finally realized my swatches are loaded into the original graphics directory graphics/00000001/ however the large version of the pictures that coordinate with the swatches are loading into graphics/00000001/1/. I have checked to make sure I didn't accidentally change anything on my domain settings for uploading graphics and I didn't. Does Partition Images automatically create those subdirectories? I've moved everything out of graphics/00000001/1/ back to the original directory and deleted everything that was in that subdirectory. When I upload a photo with Image Management, it goes into the new directory. Should I export all of these new products I've worked on since upgrading to Ver10 and import them back after changing the image links to graphics/00000001/ ? I have wasted hours and hours on this trying to figure out why the inventory count isn't correct when the images are in two different directories.

Has anyone else had this issue? I had asked Leslie Kirk to look at my original problem on some t-shirts which didn't have correct inventory counts. Tonight is when I discovered what is causing it. If the swatches are in the original graphics directory and the coordinating pics are in the subdirectory the count isn't correct. It wasn't until I was comparing field by field that I saw it.

Also, Image Management will not show any images uploaded on previous upgrades of Miva if the image was not uploaded through Image Management. I discovered that problem before upgrading to Ver9.0. The only way you can delete those legacy images is to FTP and manually delete them.

[William Davis]

We have a large housekeeping problem regarding image quantities. The site has been live since Miva 2, I think it was the last century when it first went up, and it now had an awful lot of jpegs in the graphics folders, heading on to 148,000 in total. The store has around 12,000 products and uses image machine which is showing around 9000 jpegs in use.

It's getting to the stage now where it needs condensing, FTP is a nightmare so a serious cull is required and I do not like the idea of doing it manually. Any one have any ideas?

Thanks...

We have this same issue and waiting for M10 to resolve this issue as well. Coincidentally, we had planned to work in this issue today and stopped when we came across your post -thanks for the heads up!

On a related matter, are you having problems with your google merchant feed rendering image_link path for either "legacy images" or images uploaded via image machine? If so, how did you resolve this issue?

Did you attempt Brennan's recommendation in post (on #5 04-02-18, 03:03 PM)? How did it go?

[William Davis]

A few recommendations:

1. We will be addressing this in the core software where we automatically create sub directories inside the graphics/00000001 folder and limit them to 10k images per directory.
2. If you have legacy images which are no longer needed you can use the Image Management tool under utilities to delete any un-used images from the server to clean up some space.
3. If you wanted to, you can move the images to sub folders now, and re-import the paths via CSV. The downside to doing this is any auto-generated resized images will still go into the main graphics folder as well as images uploaded via the admin.

Brennan, can you please elaborate on this process? I think this might also address another semi-related issue we are having below:

Why would the following conditional in TEMPLATEFEED always render "in stock" in:

<mvt:if expr="l.settings:product:inv_level EQ 'low'">in stock<mvt:elseif expr="l.settings:product:inv_level EQ 'out'">out of stock<mvt:else>in stock</mvt:if>

By reimporting legacy image path, I should theoretically be able to render image_link path value for both legacy images and image machine images, or am I missing something?

[marinestore]

On a related matter, are you having problems with your google merchant feed rendering image_link path for either "legacy images" or images uploaded via image machine? If so, how did you resolve this issue?

Did you attempt Brennan's recommendation in post (on #5 04-02-18, 03:03 PM)? How did it go?

We dumped all the legacy images shortly after and only used Image Machine for the feed, we have had no significant feed problems. I did attempt to implement Brennan's solution - luckily I backed up the image directory first as we use a heap of images that are (or where) embedded in the product desc, (diagrams and sizing charts mainly) Image machine has no way of recognising these which made for an interesting week with trying to sort through the fallout. Used a spreadsheet to filter the product desc data for anything containing /0000001. This made recovery a whole lot faster.

[William Davis]

We dumped all the legacy images shortly after and only used Image Machine for the feed, we have had no significant feed problems. I did attempt to implement Brennan's solution - luckily I backed up the image directory first as we use a heap of images that are (or where) embedded in the product desc, (diagrams and sizing charts mainly) Image machine has no way of recognising these which made for an interesting week with trying to sort through the fallout. Used a spreadsheet to filter the product desc data for anything containing /0000001. This made recovery a whole lot faster.

We stopped using legacy images also after our MM4.24c migration and started to using image machine as well -images are stored in the same location before and after migration.

The problem is that token used to rendering image path in Google Merchant feed. At the time store domain was hard coded as a prefix to render token to make it work, thus image machine images path were not being rendered.

Currently we have not found a solution to our problem, such as a conditional within the data feed template that would render one value when the other is not present (image machine image path when legacy image is not available. Or import all legacy images image path into image machine which seems ideal.

When you say you "We dumped all legacy images...", how did you tell image machine where to new image is located so the token used in your data feed renders image path correctly, via file import (e.g.: legacy image path to image machine type main)?

What did you do when you had more than one legacy image (e.g.: 1, 2, 3, etc.)?

[marinestore]

We're using the Miva built in feed, previously using the Weiland Template Data Feed but when we had a major site makeover a year or two back this ceased working so we had to get Miva to build a new feed using their version. This version used the legacy image and the thumbnail as backup, it could also double up as the main image machine graphic. This new solution wasn't as functional as the Weiland feed, features such as price and category filtering plus a load more were sacrificed but it kept Google happy. Regarding image substitution problem, there is no way around this as far as I am aware. The images are defined as Main and 1 to 8 giving us 9 options in all, the feed always selects the main, if it's missing there's no a lot to be done the image does not get added to the feed. This is not ideal. I reckon you should speak to a developer on here as they seem to have a better understanding of the problem. Regarding multiple images, they all were in the same directory, the Weiland feed allowed for the choice of any image regardless of the Image Machine allocation. It's all a bit of a mess to be honest.

[lesliekirk]

Okay, I ran into a big problem. With Ver10 a subdirectory created under graphics/00000001/1/ and it has caused all sorts of hell for me. All of the images I added relating to attributes and inventory variants went into that subdirectory. I have been banging my head against a brick wall trying to figure out why inventory count isn't working correctly when going from swatch to swatch. Finally realized my swatches are loaded into the original graphics directory graphics/00000001/ however the large version of the pictures that coordinate with the swatches are loading into graphics/00000001/1/. I have checked to make sure I didn't accidentally change anything on my domain settings for uploading graphics and I didn't. Does Partition Images automatically create those subdirectories? I've moved everything out of graphics/00000001/1/ back to the original directory and deleted everything that was in that subdirectory. When I upload a photo with Image Management, it goes into the new directory. Should I export all of these new products I've worked on since upgrading to Ver10 and import them back after changing the image links to graphics/00000001/ ? I have wasted hours and hours on this trying to figure out why the inventory count isn't correct when the images are in two different directories.

WOW - I had no idea that the Image Swatches impact inventory count. FYI, I did reply to your email this morning

[Miss Kate]

WOW - I had no idea that the Image Swatches impact inventory count. FYI, I did reply to your email this morning

I started another post under Miva 10 also with a screenshot. I need to get things fixed so everything is in the same graphics directory & if I'm still having the same issue I'll let you know. Yeah, the swatches you click through on the main product in the store are connected to the large pictures. If the swatch isn't in the same directory, then you can't bring that item up. If you change the inventory to something other than 0, it will still show as Sold Out.