Printable View
Quote:
Originally Posted by jimmie
Does that cover all of the areas in ZC 1.5.1 where you expected to see the customid, but didn't see it? It is difficult these days to test for such old software where the program works in the newer versions taking advantage of the capability of the newer versions that didn't exist back then.Quote:
Originally Posted by jimmie
yes, but customer doesnt see it in their order or checkout shipping and no popup when out of stock, also what about sending custom id to payment module like paypal.
Attachment 18384
I have a product with two attribute options and each option has two values. I have a different custom id for each of the four option-value pairs. I expect one of these four custom id's will be displayed in the various places that custom id is displayed, but I'm seeing two custom ids separated by a comma. Should there be only one custom id displayed? Examining $order->products[$i][attributes][0][customid] in admin/packingslip.php shows two custom ids for the selected option, separated by a comma. $order->products[$i][attributes][1][customid] is the same. $order->products[$i][customid] shows [type] is "single", and [value] is the same two custom ids as before. Seems to me that [type] should be "multi". Should it be "multi" and is it set during attribute entry? If so, where and how? Should [attributes][0][customid] be the single customid corresponding to first option-value pair? Same for [attributes][1][customid] except for the second option-value pair? Finally, what should be entered in the Unique Combo box on the Admin Products with Attributes Stock page? It is currently blank. I have recently upgraded SBA from v1.5.3 to SBA-Combined master from GitHub, downloaded Feb 1, 2019. Products with a single option and multiple values displays custom id's as expected.
Thanks for a great add-on and your support in the past.
ZCv1.5.6a, PHP 7.1
@Dave224,
Good questions and thank you for much of the information provided. The key to the single vs. multiple customid aspect is how are the variants setup? From what has been provided both in the "configuration" and the results appears to indicate that every option value is listed on its own. Meaning that there is not a grouping such as option name 1's option value 1 with option name 2's option value 3 (really the first option value of option name 2, but calling it 3 for clarity).
I say this, because, 1) the same customid is not duplicated (x, x) and that there are two customid's provided (one for each option value selected which is two based on two option names with the product.)
Now why are there two array values? Well, each attribute of the product is stored in its own record. There are two attributes to the product, so two records. Further, the customid associated with the purchase, if I remember correctly, is stored with each attribute. Now I thought I stored each uniquely but then based on the previous determination output the customid as combined and did it this way so that the display could be modified if so desired (combine into one long customid if desired, separate out into individual, etc...), but unfortunately at the moment I'd have to review the code again more to accurately report that aspect. That review also depends on the answer to my previous posed question about the variant arrangement.
mc12345678,
On the Admin Products with Attributes Stock page, each row in the variant column consists of two lines.
Variant 1:
line 1: "option name 1: option 1 - value 1"
line 2: "option name 2: option 2 - value 1"
Variant 2:
line 1: "option name 1: option 1 - value 1"
line 2: "option name 2: option 2 - value 2"
Variant 3:
line 1: "option name 1: option 1 - value 2"
line 2: "option name 2: option 2 - value 1"
Variant 4:
line 1: "option name 1: option 1 - value 2"
line 2: "option name 2: option 2 - value 2"
So I think they are grouped. Does that answer your question on how the variants are set up?
Also, please note that the customid data reported in the last post in the three locations are identical, consisting of the custom ids for variant 1 and variant 2 separated by a comma. The purchased product was variant 1.
Dave
Ok, yeah, that gives me enough to narrow it down. I do see that there is a minor difference in the function code between the admin and catalog sides that might account for this result. I also want to take a look at the added database table related to the transaction to see if the code should be using that instead of the current process.
I also understand much clearer now about the setup, the expectations, and the results. (I have/had the same expectation but apparently didn't get the result(s)).
Your note about differences in function code between catalog and admin prompted me to look at customid on the catalog side. I've been working primarily on the admin side. First let me explain that the product attribute option 1 has three values, not two. I used only two in my posts to make it simpler to explain. With that in mind, there are now four customids displayed on the catalog side and admin side. One corresponds to the purchased item (both option-value pairs match what is purchased). For the other three, only one of the two option-value pairs match what was purchased.
To explain a little better, I introduce the following notation involving two characters, say "ax". The first character represents the value of the first option which can have one of three values. So the first letter can be a, b, or c. The second character represents the value of the second option which can have one of two values. So the second character can be x or y. What was purchased was ax. The customids displayed are ax, bx, cx, and ay. Note that the first customid corresponds to what was purchased, and other three have one letter that is present in the purchased item.
This behavior was for a new purchase made today. Four customids were displayed on the catalog and admin side. An order made several days ago only shows two customids. I'm not sure why the difference, but must be related to final code changes I made during the upgrade to zc156a.
I assume that only the customid of the purchased item should be displayed; at least that is what I want.
Hope this post provides more clues.
Dave
mc12345678,
It seems to me that the code is designed to display multiple custom ids for some reason, and at least in the admin, display them next to the attributes. I need the customid on only the packing slip to assist the packer find the correct item to pack. It's really not for the customer, so I normally have the customid display turned off. I also want the single customid displayed next to the product name, not down with the attributes. So I think I'll go with direct queries of the database. I don't want to change what works for other people. I'll let you know how I make out with this approach.
Thanks again for a great add-on and your terrific support.
Dave
Looking at the differences in the code, how/where the code is used, and the report that the catalog side works correctly but the admin side does not, the admin/includes/classes/observers/class.products_with_attributes_stock.php needs a little modification:
Lines 410-411 need to be modified from:
to:Code:if (/*$value['option'] == $orders_products_sba_customid->fields['products_options_id'] &&*/ $value['value_id'] == $orders_products_sba_customid->fields['products_options_values_id']) {
(hopefully there are not a bunch of hashtags in the above pasted content. Apologies if there is.)Code:if ($value['option_id'] == $orders_products_sba_customid->fields['products_options_id']
&& $value['value_id'] == $orders_products_sba_customid->fields['products_options_values_id']) {
To explain a little about the various placement of the customid and possibilities, each attribute could have its own customid if listed independently like if a specific product was an option from a dropdown, or like used as described, the combination of attributes identifies a specific product where that has its own customid. The code supports creating variations of this.
As to the "final" placement, well that's up to where you want it. I went with placing it near the model_number if it is its own content, or I believe also included the ability to replace the model_number if that is so desired. (If that feature isn't present, it was a design consideration at least.)
Move the "echo" to where you want it, doesn't hurt anything. Remove it from the other "modified" files, it doesn't hurt anything there either. :) May add a feature to enable/disable from known files, but at the same time, absence of the template related code doesn't hurt operation...
Oh, and yes, the change described above was based on looking at the code and the reported issue of "crossing" over to a different variant.
Ugh...
Here's a screen shot of the shopping cart page where I ordered some items, most with the product that has multiple options and one with a single option, and one with no options. Of the three items with multiple options, one customid was correct, one item had 4 customids, and one had 2 customids. So the catalog side is not always correct.