You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To date Dynamic Dropdown modification has been to generate a sequenced dropdown method for multiple attributes (might also be applied for single attributes) to support display of additional information such as out-of-stock items, the additional customID, and any additional information associated with a Variant that would be beneficial to a customer.
The original version of this program loosely supported sequenced listing, though some improvement has been identified for the general plugin. The program uses a base class that is then used to generate variants of displaying the desired information with functions in the new class overriding any previously defined function.
The first function encountered uses the products_with_stock_attributes table to generate the first sequential dropdown and therefore only identifies the first option name (sorted by option name sort value) items that are captured in the SBA table (identified variants). The second and subsequent sequential dropdown is generated using the available attributes for the product from the ZC database without any tie to the SBA table (yes also in the ZC database, but a "new" table specifically for SBA).
An example product: 2 attributes, but, selection of option value 1 of attribute 1 is available in option values a and b only of the second attribute where selection of option value 2 of attribute 1 is only available in value b of the second attribute. By availability I do not mean out-of-stock, but that the product is not offered by anyone. Attribute 1, option value 2, attribute 2, option value a just simply doesn't exist. Under the current programming model, Dynamic Dropdowns would provide either the value identified for 1:2,2:a as entered in the SBA table, or if not entered in the table the quantity result would be the sum of all attribute types available (Ie. the product quantity identified when synchronizing all of the variants but not zero...)
The ideal situation (to program) would be for all possible variants to be identified in the SBA table automatically; however, when displaying "out-of-stock" those variants that do not exist would lead one to think that it may come back "into stock" (never happen). Alternatively, (and the route considered), first is to build the subsequent available attribute option values based on the variants identified in the SBA table rather than all potentially feasible variants. This way, if a variant exists where the stock decreases to zero, then the store owner can either keep that variant in the database (potentially signifying that it will return to stock) or delete the variant and that variant will no longer appear as an available variant on the store side and the issue of returning the total stock against a non-listed variant.
Another way to go would be for SBA to always populate with all variants and provide the store owner a way to mark a variant that does not/can not exist... This may also be an acceptable practice; however, an evaluation of which alternative should be performed to identify the future benefit(s) of one or the other for further code development. Just a thought... :)
The text was updated successfully, but these errors were encountered:
I think most important for a cart owner and the buyer is to have the stock amount displayed in the dropdown so that the buyer can see there usually are some. Right now, they add the option to the cart and it gives them the adjusted quantity option and does not say it's out of stock. This cart has it set to not display the products if out of stock completely so it's definitely not displaying along the lines of what the website owner intends.
To date Dynamic Dropdown modification has been to generate a sequenced dropdown method for multiple attributes (might also be applied for single attributes) to support display of additional information such as out-of-stock items, the additional customID, and any additional information associated with a Variant that would be beneficial to a customer.
The original version of this program loosely supported sequenced listing, though some improvement has been identified for the general plugin. The program uses a base class that is then used to generate variants of displaying the desired information with functions in the new class overriding any previously defined function.
The first function encountered uses the products_with_stock_attributes table to generate the first sequential dropdown and therefore only identifies the first option name (sorted by option name sort value) items that are captured in the SBA table (identified variants). The second and subsequent sequential dropdown is generated using the available attributes for the product from the ZC database without any tie to the SBA table (yes also in the ZC database, but a "new" table specifically for SBA).
An example product: 2 attributes, but, selection of option value 1 of attribute 1 is available in option values a and b only of the second attribute where selection of option value 2 of attribute 1 is only available in value b of the second attribute. By availability I do not mean out-of-stock, but that the product is not offered by anyone. Attribute 1, option value 2, attribute 2, option value a just simply doesn't exist. Under the current programming model, Dynamic Dropdowns would provide either the value identified for 1:2,2:a as entered in the SBA table, or if not entered in the table the quantity result would be the sum of all attribute types available (Ie. the product quantity identified when synchronizing all of the variants but not zero...)
The ideal situation (to program) would be for all possible variants to be identified in the SBA table automatically; however, when displaying "out-of-stock" those variants that do not exist would lead one to think that it may come back "into stock" (never happen). Alternatively, (and the route considered), first is to build the subsequent available attribute option values based on the variants identified in the SBA table rather than all potentially feasible variants. This way, if a variant exists where the stock decreases to zero, then the store owner can either keep that variant in the database (potentially signifying that it will return to stock) or delete the variant and that variant will no longer appear as an available variant on the store side and the issue of returning the total stock against a non-listed variant.
Another way to go would be for SBA to always populate with all variants and provide the store owner a way to mark a variant that does not/can not exist... This may also be an acceptable practice; however, an evaluation of which alternative should be performed to identify the future benefit(s) of one or the other for further code development. Just a thought... :)
The text was updated successfully, but these errors were encountered: