finding erratic performance

[wiztechinc]

some things get added to the cart with no issue - somethings will create the message that the numbers have been adjusted but then the product is not added to the cart. If that same product is added with correct numbers, it gives no message and doesn't add to cart.

I checked to make sure that all things were equal with stock quantities added and it all looks fine.

[mc12345678]

This type of issue had not been seen in testing. Yes, cases of the notification were observed; however, upon either correcting the quantity in the shopping cart or returning to the product, to then add it again, without issue.

So, it would help to have the various conditions identified in which this is occurring: Goto cart after product added to cart: Allow adding to cart with out of stock (there is the setting in the standard cart as well as dynamic dropdowns) The setup of the product variant(s): are there multiple attributes, if so were they added as a single variant or was each attribute added in it's own quantity? Is there any other extra_cart_action files that might interfere with the process? At the time of discovery, was the quantity in the admin modified before moving back/forth to modify the quantity? Is the product where this is occurring virtual or mixed? What are the settings for the product being mixed product in relation to min/max. Are there min/max setting requirements appliedand what are they?

I'm sure there are a few other settings to ask about, but at the moment without looking at the possible configuration settings I can not think of others.

[wiztechinc]

check stock true subtract stock true allow checkout when out of stock product status when out is 0

not using dynamic dropdowns and code is in not in tpl_modules_attributes.php cause using flexible attributes instead

all are multiple attributes with attributes installed for google and are hidden from view. When I had the dynamic dropdowns installed that was part of the issue because it showed all the attributes in the dropdown. (flexible attributes add id number so you can hide with css) So none of those attributes then have stock added to them but that's for all products. where some are working and some aren't. Those attributes are normal but with only one option and are read only

defaults products otherwise, no mins or max, not mixed. No other extra cart actions

[mc12345678]

Back on the variant aspect: are all attributes added as a single combination for a single product or are they added as single variants to the product?

Ie. Three attributes: 1) size, 2) gender, 3) "age"

Such that attributes 2 and 3 are perhaps read only based on the product, and option 1 is the only user viewable/selectable option (highly simplified I know).

Is the variant added as: say: 7, female, adult qty 20? Or as individual attributes such as: 7 qty 20 9 qty 15 11 qty 17 Female qty 99999 Adult qty 99999

As for the css and hiding aspect, that is possible on a default ZC install as well as with Dynamic Dropdowns installed or not, just differently than with the plugin/modification added to the cart. If the hiding is the only thing that the plugin affects, then it has no impact on the processing of the cart provided that it only affects the css and does not interfere with the information being posted to the page (ie, view source shows that all attributes are present.) Depending on how it modifies the tags around the attributes, it may though also interfere with recognizing what attributes have been selected, though would have to look at the code to see how that portion is processed upon submission. Also need to look again at the how the attributes are so designated for display, but thought that the powerhouse comes from the standard method of attribute designation and just using the selected values to determine the presence of stock and permit the addition to the cart.

Any of the problem product being out of stock already? (If so are they the only ones affected? Are they all so affected?)

[wiztechinc]

products added separately and as black 2 white 2 total 4 and no quantities for gender, brand, age group etc. Then only black and white show because of only css display none - the only change for flexible attributes is the adding of an id number. I checked the products that aren't being added to the cart and everything is the same as other products with quantity in stock. I synchronized the quantities across the board and for the individual product in question. I simply see no difference between the ones that do add to the cart and the ones that don't.

[wiztechinc]

I was wrong. The variants are not separate it looks like. I'm pasting the image:

But the products are alike in that way.

oh and here's the source code for the flexible attributes - it adds the id to the wrapper

Brand

Cathayana Inc

and

Color

Blue Green Purple

wiztechinc commented 9 years ago

whoops source code pasting didn't work.

mc12345678 commented 9 years ago

Use single backquote around the source code for it to appear here as expected/desired.

mc12345678 commented 9 years ago

Still trying to recreate the issue...

The data that is being used for this store, in particular for SBA, was everything entered using this version of SBA or is it some sort of upgrade from a previous version? Product that is not behaving correctly, can the variants be deleted for that product, repopulated and the issue go away?

This request is easier asked than answered, but is a possible reason/issue.

@Jeking noticed something earlier in testing which required changes in order to properly handle information upfront. It relates to the value of products_attributes_id from table products_attributes and the sequencing (sort order) of the applicable option names. These values are to be sorted and stored in the SBA table, but then there is the question of what is going on during cart processing and whether any additional sorting is necessary.

It may also be of benefit, if able/allowed, to have the product related table data made available to review. This would include the tables associated with options, attributes, and product information. The ZC wiki includes information on the tables applicable.

wiztechinc commented 9 years ago

Well, this is the upgrade that in the end costs money instead of producing money. Just dang.

So, this was an upgrade from a previous version and no, I wasn't handling the site when they started using the SBA. I'm not sure if I even had anything to do with the dynamic dropdowns because I don't see that they ever needed it to begin with.

I will try redoing one of the offenders and see if that makes any difference and then send table data at that point.

mc12345678 commented 9 years ago

If the offender is fixed, then I think I can provide a quick bit of code to rectify the issue.

The goal as developed in this version of SBA is for the stock_attributes to be sorted from low to high separated by a comma. Some previous versions of SBA didn't enforce this and relied on the data being entered in the "correct" sequence. Way too involved to get it to work right or always had to touch the database tables to make it work.

Anyways, hopefully that resolves the issue. The next thing would be for such upgrades to ensure that this version of SBA corrects the issue in the future.

mc12345678 commented 9 years ago

The other thing that I did not comment on in response is that read only attributes in Dynamic Dropdowns (part of why modification to the tpl_modules_attributes.php file was necessary) is an issue identified in item #30.

wiztechinc commented 9 years ago

And now I know what's happening. If the product variants are added in combination as my previous image displays, they only work when there is only one product variant total. So it's the combining all together that is creating the issue - a major issue in this cart. Nearly all are added that way.

I took the one product that was definitely an issue and deleted the variants and then added them back in without the readonlys in SBA.

This cannot be corrected in this cart with any efficiency at all. No, none of these should have been created like this but this leaves the cart owner with only a partly working mod.

mc12345678 commented 9 years ago

There is a script in the configuration section addressing read only attributes. I haven't personally worked with it or investigated it's functionality, but it may resolve this issue...

mc12345678 commented 9 years ago

Alternatively if the product_attributes_id can be identified for the read-only attributes they could be removed from the products.

Also, EP4 could be used to basically repopulate the quantities if model numbers have been used on the base product. Or of course the read only aspect of SBA could be fixed as well... That is on the table for addressing as issue #31 and associated with issue #30 as well.

mc12345678 commented 9 years ago

Updated the code to include the ability to remove, from SBA variants, readonly attributes from the tracked quantity. Also found some things related that were identified as addressing readonly attributes; however, really were referring to display only attributes (as controlled in the attributes_controller). Updated the on screen instructions in the configuration window and sql query descriptions to reflect that they apply only to display_only not read_only. Looks like there is some additional coding that could go into the addition of display_only attributes to combine the new attribute with existing or add it as a separate line item depending on previous conditions. Anyways, full removal of readonly attributes is now possible, but also not sure that is the desired/intended final condition for this issue. Perhaps marking as display only will resolve the issue for you? There are a number of ways to copy that attribute setting to other products that already have that attribute if that works for you.

Stated, because supposedly from the above, all of the non-functioning and functioning versions look the same within SBA, so there must be something elsewhere that is incorporated that is preventing the "problem" with the existing data.

wiztechinc commented 9 years ago

And by the way, running the scripts was only a partial fix. if the combined variant had stock of two and another variant had 2, the new variants had 4 each. Now going through many products to fix quantities.

mc12345678 commented 9 years ago

Not sure how the remove readonly attribute script caused the change in quantities unless a variant existed that did not include the readonly attribute. I guess I wrote the script wrong as the way the remove readonly attribute script was written was to keep the variant that previously existed without the readonly attribute, rather than deleting it and keeping the modified variant without the readonly attribute.

I've added some notes into some of the files to further address readonly attributes. In the default ZC code, readonly attributes appear to be auto-selected so that should not be an overall stock tracking issue, but I know Dynamic Dropdowns did not account for Readonly attributes in any particular fashion.

mc12345678 commented 8 years ago

Haven't tested this, but welcome input if is proven acceptable. With the change of not displaying dynamic dropdowns if the product's attributes included a type outside of it's ability to properly display and with the additional checks incorporated for text entry fields upon adding to the cart, Read-Only attributes (even if hidden by CSS) should now be handled while SBA is installed. There is a "loss" of data display (will not see the quantity available as a part of a SBA dropdown or any specific data associated with the on-screen selections), but at least the appropriate tests should be performed from product display to adding the product to the cart.

mc12345678 commented 8 years ago

Read only attributes have now been removed from selection in the admin when generating variants. Further code review identified that although there is a commented out line of code for Read Only attributes to be "shown" as an attribute, generally speaking Read Only attributes do not get pushed to the cart at least not at ZC 1.5.1 up to ZC 1.5.5. So, variants that are created using the current code will not include the Read Only attribute as a part of the stock quantities.

Closing this for now, the sql query to remove readonly attributes does look like it could use some work, so that will be opened as a separate issue.

• © Githubissues.
• Githubissues is a development platform for aggregating issues.

[wiztechinc]

whoops source code pasting didn't work.

[mc12345678]

Use single backquote around the source code for it to appear here as expected/desired.

[mc12345678]

Still trying to recreate the issue...

The data that is being used for this store, in particular for SBA, was everything entered using this version of SBA or is it some sort of upgrade from a previous version? Product that is not behaving correctly, can the variants be deleted for that product, repopulated and the issue go away?

This request is easier asked than answered, but is a possible reason/issue.

@Jeking noticed something earlier in testing which required changes in order to properly handle information upfront. It relates to the value of products_attributes_id from table products_attributes and the sequencing (sort order) of the applicable option names. These values are to be sorted and stored in the SBA table, but then there is the question of what is going on during cart processing and whether any additional sorting is necessary.

It may also be of benefit, if able/allowed, to have the product related table data made available to review. This would include the tables associated with options, attributes, and product information. The ZC wiki includes information on the tables applicable.

[wiztechinc]

Well, this is the upgrade that in the end costs money instead of producing money. Just dang.

So, this was an upgrade from a previous version and no, I wasn't handling the site when they started using the SBA. I'm not sure if I even had anything to do with the dynamic dropdowns because I don't see that they ever needed it to begin with.

I will try redoing one of the offenders and see if that makes any difference and then send table data at that point.

[mc12345678]

If the offender is fixed, then I think I can provide a quick bit of code to rectify the issue.

The goal as developed in this version of SBA is for the stock_attributes to be sorted from low to high separated by a comma. Some previous versions of SBA didn't enforce this and relied on the data being entered in the "correct" sequence. Way too involved to get it to work right or always had to touch the database tables to make it work.

Anyways, hopefully that resolves the issue. The next thing would be for such upgrades to ensure that this version of SBA corrects the issue in the future.

[mc12345678]

The other thing that I did not comment on in response is that read only attributes in Dynamic Dropdowns (part of why modification to the tpl_modules_attributes.php file was necessary) is an issue identified in item #30.

[wiztechinc]

And now I know what's happening. If the product variants are added in combination as my previous image displays, they only work when there is only one product variant total. So it's the combining all together that is creating the issue - a major issue in this cart. Nearly all are added that way.

I took the one product that was definitely an issue and deleted the variants and then added them back in without the readonlys in SBA.

This cannot be corrected in this cart with any efficiency at all. No, none of these should have been created like this but this leaves the cart owner with only a partly working mod.

[mc12345678]

There is a script in the configuration section addressing read only attributes. I haven't personally worked with it or investigated it's functionality, but it may resolve this issue...

[mc12345678]

Alternatively if the product_attributes_id can be identified for the read-only attributes they could be removed from the products.

Also, EP4 could be used to basically repopulate the quantities if model numbers have been used on the base product. Or of course the read only aspect of SBA could be fixed as well... That is on the table for addressing as issue #31 and associated with issue #30 as well.

[mc12345678]

Updated the code to include the ability to remove, from SBA variants, readonly attributes from the tracked quantity. Also found some things related that were identified as addressing readonly attributes; however, really were referring to display only attributes (as controlled in the attributes_controller). Updated the on screen instructions in the configuration window and sql query descriptions to reflect that they apply only to display_only not read_only. Looks like there is some additional coding that could go into the addition of display_only attributes to combine the new attribute with existing or add it as a separate line item depending on previous conditions. Anyways, full removal of readonly attributes is now possible, but also not sure that is the desired/intended final condition for this issue. Perhaps marking as display only will resolve the issue for you? There are a number of ways to copy that attribute setting to other products that already have that attribute if that works for you.

Stated, because supposedly from the above, all of the non-functioning and functioning versions look the same within SBA, so there must be something elsewhere that is incorporated that is preventing the "problem" with the existing data.

[wiztechinc]

And by the way, running the scripts was only a partial fix. if the combined variant had stock of two and another variant had 2, the new variants had 4 each. Now going through many products to fix quantities.

[mc12345678]

Not sure how the remove readonly attribute script caused the change in quantities unless a variant existed that did not include the readonly attribute. I guess I wrote the script wrong as the way the remove readonly attribute script was written was to keep the variant that previously existed without the readonly attribute, rather than deleting it and keeping the modified variant without the readonly attribute.

I've added some notes into some of the files to further address readonly attributes. In the default ZC code, readonly attributes appear to be auto-selected so that should not be an overall stock tracking issue, but I know Dynamic Dropdowns did not account for Readonly attributes in any particular fashion.

[mc12345678]

Haven't tested this, but welcome input if is proven acceptable. With the change of not displaying dynamic dropdowns if the product's attributes included a type outside of it's ability to properly display and with the additional checks incorporated for text entry fields upon adding to the cart, Read-Only attributes (even if hidden by CSS) should now be handled while SBA is installed. There is a "loss" of data display (will not see the quantity available as a part of a SBA dropdown or any specific data associated with the on-screen selections), but at least the appropriate tests should be performed from product display to adding the product to the cart.

[mc12345678]

Read only attributes have now been removed from selection in the admin when generating variants. Further code review identified that although there is a commented out line of code for Read Only attributes to be "shown" as an attribute, generally speaking Read Only attributes do not get pushed to the cart at least not at ZC 1.5.1 up to ZC 1.5.5. So, variants that are created using the current code will not include the Read Only attribute as a part of the stock quantities.

Closing this for now, the sql query to remove readonly attributes does look like it could use some work, so that will be opened as a separate issue.