uprid. attributes values/arrays are needed?

I'm trying to generate a uprid to compare against that stored in the orders_products table using zen_get_uprid(product number, attributes array). I understand that it is based on the attributes that are stored. $_POST['id'][$_POST['products_id'][$i]] where I think i is the nth-1 product, but I am not sure which parts of the attributes are needed to generate the uprid. And for some reason I haven't found a "convenient" way or place to show that variable. Superglobals almost always identifies that the POST is empty.

Anybody know?

mc12345678:

I'm trying to generate a uprid to compare against that stored in the orders_products table using zen_get_uprid(product number, attributes array). I understand that it is based on the attributes that are stored. $_POST['id'][$_POST['products_id'][$i]] where I think i is the nth-1 product, but I am not sure which parts of the attributes are needed to generate the uprid. And for some reason I haven't found a "convenient" way or place to show that variable. Superglobals almost always identifies that the POST is empty.

Anybody know?

Still haven't exactly found what is fed to populate the attributes variable that gets encoded, I'm wondering if it's like: $attributes[] = array('option-id'=>'21','option_values_id'=>'11'); so that the unique id of the attribute is therefore provided, and then that is what is encrypted, if it is every possible non-file attribute aspect, or if it is every possible attribute field filled in as applicable (nulls and everything) that is then encrypted. :/

I still haven't fully connected the dots from the product info page to the cart encrypting it, but it seems like the design idea would be to make the vriables to be encrypted as easy to fill in as possible and that they would be based on what is presented on screen (html) when managing a product. Further, because an attribute can be defined either by it's unique number which is different between the products attributes and products attributes downloads tables that, the more "universal" option number and option value number would be the route to go as these two values wuld easily lead to other data that is easily retrievable.

I'm going to give that a shot and see if this random code that is generated is the same as one that has already been generated or if I have to expand my array population to get the same unique number that I'm trying to get.

mc12345678:

I'm trying to generate a uprid to compare against that stored in the orders_products table using zen_get_uprid(product number, attributes array). I understand that it is based on the attributes that are stored. $_POST['id'][$_POST['products_id'][$i]] where I think i is the nth-1 product, but I am not sure which parts of the attributes are needed to generate the uprid. And for some reason I haven't found a "convenient" way or place to show that variable. Superglobals almost always identifies that the POST is empty.

Anybody know?
The $_POST variable is empty after an add-to-cart action because the shopping_cart class, after a cart-related action, redirects back to either the shopping_cart or the come-from page. You can view the format of the attributes' information using Superglobals by looking at _SESSION['cart']->products['attributes'].

mc12345678:

Still haven't exactly found what is fed to populate the attributes variable that gets encoded, I'm wondering if it's like: $attributes[] = array('option-id'=>'21','option_values_id'=>'11'); so that the unique id of the attribute is therefore provided, and then that is what is encrypted, if it is every possible non-file attribute aspect, or if it is every possible attribute field filled in as applicable (nulls and everything) that is then encrypted. :/

I still haven't fully connected the dots from the product info page to the cart encrypting it, but it seems like the design idea would be to make the vriables to be encrypted as easy to fill in as possible and that they would be based on what is presented on screen (html) when managing a product. Further, because an attribute can be defined either by it's unique number which is different between the products attributes and products attributes downloads tables that, the more "universal" option number and option value number would be the route to go as these two values wuld easily lead to other data that is easily retrievable.

I'm going to give that a shot and see if this random code that is generated is the same as one that has already been generated or if I have to expand my array population to get the same unique number that I'm trying to get.

Wow, finally did it, through some brute force/testing and correcting typing mistakes, I figured out what it takes to calculate the uprid for a product.

The array to feed the function zen_get_uprid is created like such: $variable[$option_id] = $options_values_id
Do this for all attributes then what I originally did was recreate the store side of the function zen_get_uprid because it offers some more cleanup of the information (text box related) than the admin side and it performed the encryption; however, after some contemplation, I reverted back to simply calling the zen_get_uprid function.

Ultimately it was through the review of the cart session value that I landed on the above testing method as lat9 has suggested.

Also, while this method of comparison seems to function for it's purposes, I do believe that the code being tested falls short in actually having to do this comparison. While I've tetsed the above code with dropdowns, I need to see what happens with text boxes and may be a reason this plugin has never been fully completed.

Thanks for the information lat9, I did get around to figuring it out, had started to close the loop and wanted to verify some things before posting, well then sleep came. :)

Remember, too, that the option_id entries in the array are sorted according to their products_options_sort_order; since the prid is an md5-hash, the order in which the options exist in the attributes' array is pertinent.

lat9:

Remember, too, that the option_id entries in the array are sorted according to their products_options_sort_order; since the prid is an md5-hash, the order in which the options exist in the attributes' array is pertinent.

Yeah, I had considered that, but hadn't implemented it yet, needing to identify the various ways that ZC offers sorting of the option names and when multiple values can be valid those as well. In my original testing I had arranged my data in a specific sequence to try to avoid that concern and to narrow down the functionality needing to be implemented, but to properly implement requires this consideration.

So close, but still so far away. :)

Theoretically the uprid is unique or at least sufficiently unique. I am wondering if the sample size is sufficiently small, what the likelihood of a false equivalent uprid would be if both sort methods typically offered in the includes/modules/YOUR_TEMPLATE/attributes.php file were used to generate the uprids for comparison.

I guess part of the process could be to compare with one and then compare with the other and the one that has the higher frequency of matching would be the one to go with...

Thoughts? (Besides that doubling the generation and comparison increases processing power and time for these infrequent operations?)