Product Code Character Limit - Ideas/Solutions?
There's been a few posts regarding this particular situation but since some of them are rather old or pertain to previous versions of Miva I thought I'd seek some more current information before I start tinkering.
I'm running into a problem with the 50 character limit for product codes. Since I have a rather large SKU count in front of me I just rely on some functions in Excel to generate the code for product import. It's simply the product name with the SKU appended and then filtered to remove the useless terms. This works great as most everything falls in the 40-60 character range and keeps the URLs clean yet informative. Unfortunately, those that top 50 characters fail on import.
My first thought was to just start dumping characters from the product code but this isn't exactly ideal. The catalog contains numerous items that are similar, maybe with a different brand or part of a different model line, and having those terms in the URL is important. This is especially important for those performing very specific searches.
I then thought about altering the database to allow for longer character limits which seems like the best solution. I read in another post that an earlier version of Miva supported 100 characters which would be perfect and I think anything more than that is overkill or keyword stuffing anyway.
My concern is mainly the impact on the product database with future upgrades. If an update resets that to 50, what then happens to all of those products which might account for 50% of the catalog. I also read about other side effects in the store or with modules but I'm not sure how relevant those are now. Currently the only two modules in use are Toolkit and Purchase Order Plus from Emporium Plus, with Quickbooks integration to likely come later.
Any thoughts you can throw my way regarding this would be greatly appreciated. I'm especially interested in the database modification and depth of changes required as the alternative really sacrifices the unique product differences that the URLs contain. While it may only be 10 or 15 characters in most cases, the terms removed will prove to be quite important to the product.
Thanks,
Tim
I'm running into a problem with the 50 character limit for product codes. Since I have a rather large SKU count in front of me I just rely on some functions in Excel to generate the code for product import. It's simply the product name with the SKU appended and then filtered to remove the useless terms. This works great as most everything falls in the 40-60 character range and keeps the URLs clean yet informative. Unfortunately, those that top 50 characters fail on import.
My first thought was to just start dumping characters from the product code but this isn't exactly ideal. The catalog contains numerous items that are similar, maybe with a different brand or part of a different model line, and having those terms in the URL is important. This is especially important for those performing very specific searches.
I then thought about altering the database to allow for longer character limits which seems like the best solution. I read in another post that an earlier version of Miva supported 100 characters which would be perfect and I think anything more than that is overkill or keyword stuffing anyway.
My concern is mainly the impact on the product database with future upgrades. If an update resets that to 50, what then happens to all of those products which might account for 50% of the catalog. I also read about other side effects in the store or with modules but I'm not sure how relevant those are now. Currently the only two modules in use are Toolkit and Purchase Order Plus from Emporium Plus, with Quickbooks integration to likely come later.
Any thoughts you can throw my way regarding this would be greatly appreciated. I'm especially interested in the database modification and depth of changes required as the alternative really sacrifices the unique product differences that the URLs contain. While it may only be 10 or 15 characters in most cases, the terms removed will prove to be quite important to the product.
Thanks,
Tim
Comment