Forum Moderators: buckworks
In the beginning, during training, it was emphasized that the changing of SKUs causes a 404 error and it is not to be done unless absolutely necessary. And, if a change is required, we should plan it in advance and serve the proper server headers based on the changes.
The client has a "Senior Moment" and changes the SKUs in an entire category. I didn't catch it until the first indexing and the 404s started showing up. I'll be damned. And, to top it off, the SKU change was not needed as it was already taken care of.
When things like this happen, I like sending emails in 36pt bold red type with specific "DO NOT..." instructions, it gets the importance of the point across. In response to my recent sending of what I call "BIG RED", the client sent me this...
I put a post-it on my forehead - it reads 's'# UKS egnahC toN oD', I hope it does not fall off.
lol! He can take a few punches as I surely dished a few out.
We are making the SKU fields editable by "Super Admins" only, which there is only one, and it is not the client.
Got any similar horror stories to share?
I've asked for a spreadsheet or csv with old SKU, new SKU columns. No they can't generate that.. I dunno what the rest of their customers do with their price lists, maybe they just look at them and admire the pretty fonts or something? But we like to actually, you know, import them into our system.
A SKU should be fixed for the entire lifetime of a product but business users try do dumb things like embedding meaning into the character string. When this happens there is usually a second identifier somewhere around the system that is fixed, otherwise sales history would be total (expletive omitted). That is the one you should be using.
..when a supplier decides to change their SKUs on the price lists they send out..
We just had that happen, and to make things even worse, they reused some of the old numbers on new items. So I had to give the new/old items temporary SKU's to avoid duplicates and then go back.
And to make it worse, some of their new numbers were the same as a totally different item from another vendor.
I am working on a totally new system of SKU's for what we sell, but so far have not come up with a really good solution. Using vendor or manufacturer part numbers won't work very well because there are so many systems, and some don't even have SKU - just names.
[edited by: Wlauzon at 5:31 am (utc) on Aug. 28, 2007]
we have a SKU based URI structure
P1R - how is this managed by your programming? Or is it?
Ours is title-based but the issue is similar - if the title changes the URI must change also. I learned the Achilles heel of this early on - here is how I managed it:
Our mod_rewrite directs anything not a directory and not a file to a script. If there's no matching product, a 404 header is generated. Obviously incoming links still need to connect via the old URI.
/Green-Widgets changes to /Best-Green-Widgets, so /Green-Widgets would normally not be found. If not found in the database, a second lookup in an "old title" table connects /Green-Widgets with the record for /Best-Green-Widgets, generates a 301 header, and returns the page, everyone's happy. We haven't set the old titles to expire, but suppose it's just a matter of maintenance. An ever expanding table affords more rest at night than possible 404's.
Obviously it's automated - on item updates, if the edited title does not match the existing title, throw the record reference and old title in the old titles table, even if there are other permutations of "title" for that record.
It seems like the programming should manage changes in SKU's in a similar fashion, and the problem would cease to be a nightmare. You should probably always expect that if theres a rule set, someone at the controls is going to ignore it. :-)
I am working on a totally new system of SKU's for what we sell, but so far have not come up with a really good solution.
Our system was close to a year in the making. I changed both the URI structure and the breadcrumb trail a few times during development.
Using vendor or manufacturer part numbers won't work very well because there are so many systems, and some don't even have SKU - just names.
To address this, we created our own SKU system for those manufacturers that do not use SKUs. It involves the use of the first three letters of each word in the product title with a maxium of 12 characters/numbers that can be used.
I should have also expanded and said that we are /manufacturer/sku/ based. We appened/prefix the SKUs with a three letter code that is indicative of the mfg. This also allows us to use the SKUs as IDs throughout the site. We put the user exactly where they need to be on a page through the use of SKU IDs.
P1R - how is this managed by your programming? Or is it?
Its an ongoing process. We are learning as we see things happen and making adjustments where necessary. For the most part, we were able to map out most scenarios during development, we had plenty of time. :)
On the todo list now is the ability for the store administrator to specify the status of a product. We will be adding checkboxes for 301, 302 and 410 to start with. For both the 301 and 302 status, the user will enter the new/temp destination URI.
Ours is title-based but the issue is similar - if the title changes the URI must change also.
We thought about title based in the beginning and that was immediately nixed by me due to some issues I don't feel comfortable with, the main one being the number of hyphens generated in the URI strings. If I see more than a few, the hairs on my neck rise.
Since we did test the above, we have logic in place to address just what you describe. We have two title fields available, a primary and a secondary. The first one controls the URI (if active), the second one controls the actual <title> and <h> on the page. If the second one is left blank, the first one is the default.
It seems like the programming should manage changes in SKU's in a similar fashion, and the problem would cease to be a nightmare. You should probably always expect that if theres a rule set, someone at the controls is going to ignore it. :-)[
Yes, you would think so huh? But, when you are dealing with entrepreneurs who know very little about what they are doing in there, you sometimes overlook a few things that you never thought would happen. ;)
Yes, programming will take care of all this stuff. This is our Phase I launch so there is much to do before we've finished "cutting the diamond".
Back to the SKU issue. Yes, we could have used ID numbers for the products but that doesn't have any semantics from a user perspective. Also, using the SKU in the URI gives us the opportunity to light up during SKU searches.
