Me too ...
Off to do a bunch of testing ... :cool:
Printable View
Me too ...
Off to do a bunch of testing ... :cool:
Check one other thing ...
On the products_attributes_download where the filenames removed from the field products_attributes_filename? The records themselves removed? Or were the filenames missing from the /download directory?
The entire record was missing. The files were still in place. The download attribute was set but the download field was not....ah, when you look at the Attribute Controller you would see a "Download" attribute but no file path/name. So, the attribute is not being dropped per se, but the file information is lost, like it gets deleted from the product_attribute_download table.
Clear?
Thanks for your help,
Bill
Makes no sense ...
I also have not been able to reproduce this in any manner when using the M for Move or when using the Multiple Categories Links Manager where I add the Product as a Linked Product to a new Category then change the Master Category and remove it from the old category ...
Nothing about the move that I am finding touches the Attributes ... only the copy touches the attributes and that does NOT copy the download ...
I will keep hunting ... let us know if you learn anything else ... and if you could, perhaps setup a copy to move to another category and see if you can reproduce the issue with the move ...
I am not sure I understand what you are asking for. Let me give it a try. You would like me to try a Copy command to move product around and see if that causes the delete of the download link?
I will see if I can get it to do it again...on a smaller scale and on my test server. :)
Oh, another thing. Should disabling (setting the Out of Stock) a virtual product also delete the attributes? This is not related but we had a vendor drop out of the initial launch and now he is ready to go. Unfortunately, he has around 400 products all without download attributes...meh.
Thanks,
Bill
No, I'd like you to repeat the Move with the M command and try to recreate the error ...
I know the C for Copy does this ... but I cannot get the M for Move to do this ...
Out of stock does not delete the attribute either ...
So, update. We will be moving some products around this weekend and will give it a thorough test then. The admins who moved the products in the first place tried to replicate the error but could not. Again, I hate ebugs that do not behave.
Here is their detailed response on what they did last time. You may need to visit the yourgamesnow.com site to understand the categories and context.
Quote:
Bill, we tried to reproduce the problem yesterday evening by going into the admin tools, and using the "move" tool. That did not recreate the problem. However the actual process of the big move was more complex and perhaps this information will help.
In brief, we moved Roleplaying>System>d20 to Roleplaying>d20. We moved Roleplaying>System>D20 Modern to Roleplaying>d20>d20 Modern (and the same for d20 future). Then we created new categories (D20 items, d20 monsters, etc.) and moved them inside of Roleplaying>d20. That means that there was both products and categories in the same folder and we did get the warning on the screen in admin tools. We then used the "move" tool. For example, we would move "A Dozen shields" from Roleplaying>d20 into Roleplaying>d20>d20 items.
Hopefully, that information helps.
I wonder if it could be something with d20 becoming a root category instead of a leaf.
Well, I will keep you updated on the move that should be coming this weekend. And, yes, I will be backing up this time. :yes:
Bill
Nope still cannot make it happen ...
Unless I use Copy the C as Duplicate Products ... I cannot manage to lose the downloads ...
Let me know if you trip over anything ... I will keep hunting too ...
Well, just an update. All went well with the big category reorg and subsequent move. I am inclined to chalk this one up to user error at this point...
Thanks for all the help and I will let you know if it happens again.
Bill
Not a problem ... do let us know if you are ever able to replicate it ...
NOTE: should it happen again, and I forgot about this before ... the admin_activity_log does paint a picture of what was done in the Admin ... might help solve the mystery ... :cool: