Image file names in NopCommerce have historically been not very attractive, to either humans or google-like creatures. The image file format for Nop has historically been:
site.url/images/thumbs/00000123_70.jpg
which would be the image with id 123, and dimensions of 70 along the largest size.
slightly off topic – the “single size” parameter of Nop has been a problem, since some images may be very wide or very tall… so once both sides are smashed down to 70, it may be only 10 pixels in the other dimension… making for some ugly pics. An early mod I added to nop is to allow specifying a max size rectangle, so the image can be sized to fit a rectangle instead of a square. This then looked like:
site.url/images/thumbs/00000123_70_300.jpg
Also even more off-topic – Nop currently doesnt handle non-progressive jpeg’s correctly, as it is searching for a mime type of pjpeg. If you upload a jpeg image that is not progressive, the mime type will be jpeg instead of pjpeg, and nop will wind up setting the file name extension to .jpeg instead of jpg. Not a big problem, but just add the jpeg handler to the switch statements in pictureservice.cs and it will keep all your images named with a consistent .jpg extension.
This then let me have pictures in my product listings which filled the width out to 70, but if they are tall, they can grow to a max of 300 pix before it starts getting resized. Used correctly, this makes much nicer looking product images listings.
Fast forward to version 2.3 which now includes SEO image file name support. The format for these file names now looks like:
site.url/images/thumbs/00000123_my_products_name_70.jpg
Then adding my dual dimensions mods back to it:
site.url/images/thumbs/00000123_my_products_name_70_300.jpg
It’s a definite improvement in file name friendliness, but we can do better right?
The ID portion is padded out with zeros in order to allow easy deletion of all thumbs when the admin desires, as it does a delete of {id}*.{ext} pattern. Since the ID number might be repeated somewhere else in the URL, the zeros reduce this possibility quite a bit. However, if we assume the thumbs folder will always contain {id}_{seo name}_{size}.{ext}, we can just change the delete pattern to be {id}_*.{ext} and it should work without the zero padding. So now my url looks like:
site.url/images/thumbs/123_my_products_name_70_300.jpg
One more thing I decided to do for my thumb images is to chane the folder they are put in. Many of the images used from this folder are quite large anyway, so the name “thumbs” (for thumbnails) doesnt really apply anyway. Make this change in the PictureService.cs file. I made a global var with the path info so I could change all the paths to use this var and allow modifying it in the future more easily. I went with just /img for the thumbs folder, so now I’m down to:
site.url/img/123_my_products_name_70_300.jpg
Also, it is still considered to be better to use hyphens in urls than underscores (it’s controversial, but in general this is the case) so let’s also change this while we’re at it:
site.url/img/123-my-products-name-70-300.jpg
I left all the old already-generated images in the original thumbs folder, so links won’t break to them. I’m planning to create redirection rules for each file to point the old file name to the new one, so we can tell google and others to start using the new images. This will take a bit of effort so I’m leaving it for another day at the moment.
Ok, Let’s do even one better. Since we are using the seo name in the file name now, why do we need the ID portion at all? Well we do need it for the delete operation mentioned above, but we could add a delete operation which instead searches for the SEO file names and deletes them instead. So as far as I can tell, we no longer need the ID in the file name at all. (Note I havent implemented this thumbs deletion code yet, so my site is running a bit in manual admin mode for now…). Now our images are:
site.url/img/my-products-name-70-300.jpg
This creates a problem though – currently (version 2.3) we can’t change the SEO file name for each image, they are just set to the product name automatically. If we manually change the file names in the database, this works. These can be changed in the “Picture” table in your database, just edit the SEOFileName column data. Again, running in manual mode for now, but I’m hoping version 2.4 will include the ability to change the seo file name per image. Also, this might not work if you store your original files in the file system – Im using “store in database” mode on mine.
The remaining enhancements we could do is try to trim or even remove the size info on the end of the file name. a few options we could use for this would be:
-use pre-defined sizes in the database, and append the id for these defined sizes to the URL- so if we define a size of 70×300, we could get an ID number of 3 for this- so our image would be:
site.url/img/my-products-name-3.jpg
-a variation of this is to allow a friendly name for the file size to be included with the defined size – so 70×300 could be our “Small” or “SM” size, so the url becomes:
site.url/img/my-products-name-SM.jpg
Optimally this would still support the old size-in-the-url for backward compatibility, or for those occasional images you need a special size for as a one-off.
I’ll likely go ahead and implement this full feature before redeploying because I don’t want to go through another upgrade later that requires redirecting file names yet again- best to do this as infrequently as possible.
Future Enhancements
I assume Nop will get image edting capabilites does the road, allowing cropping/zooming and other filters per-image and perhaps per-size etc, so these features will likely require further mods to the URL’s used by the images. Oh and watermarks would be nice too.
Another possible mod would be to put images in virtual folders under their product names. This would require the picture service to manage a tree of subdirectories in the image folder, but would allow urls to look something like
site.url/my-product-name/productname-front-view.jpg
In theory this could be semantically superior to the earlier versions as it associates the product image more closely with the actual product… but we would also need some enhancements to the product url’s themselves before this would make sense- we would need to move product detail pages to use shorter urls like site.url/product-name, instead of the current site.url/p/123/product-name… Next project perhaps.
Another nice feature would be support for cdn’s. In the case of a simple subdomain cdn, the store could support hosting the image files under a different subdomain such as:
cdn.site.url/my-product-name-image.jpg
Or continue with the semantic subfolder as above-
cdn.site.url/my-product-name/productname-front-view.jpg
If the cdn is offsite (ie, not hosted on the same server), the implementation becomes a bit trickier.