@jeking,
Was working on the "gift-box" option (which really offers much more than that as envisioned) and came across something that I thought had been addressed. I have pushed a commit just to address this one "feature" and will look into adding an admin switch to turn it off/on.
The issue is that with regards to items defined in the SBA table, currently either just in-stock quantities in the combinations defined in the admin OR every "mutation" that could exist is presented and those items that are not defined show as out-of-stock. I thought that I had pushed this change before, and maybe I have some separate code set aside, but it irked me that I expected operation to occur as I described above and it doesn't.
So, in plain text:
in the file includes/classes/pad_base.php
Line 492 which is the first line of this code block:
Code:
if ($productAttrAreSBA !== false) {
$combinations[] = array('comb'=>$newcomb, 'id'=>substr($newid,1), 'text'=>$newtext);
if ($newisselected) {
$selected_combination = sizeof($combinations)-1;
}
}
Change from:
Code:
if ($productAttrAreSBA !== false) {
to:
Code:
if ($productAttrAreSBA !== false && (true /* <- true to only display product variants available as entered,
false to display every attribute combination possible from the attributes controller data for that product */
? !is_null($productAttrAreSBA)
: true)) {
$combinations[] = array('comb'=>$newcomb, 'id'=>substr($newid,1), 'text'=>$newtext);
if ($newisselected) {
$selected_combination = sizeof($combinations)-1;
}
}
This will allow showing defined items/variations that are out-of-stock and prevent display of undefined out-of-stock variations. This will mirror what I described above where I indicated regarding defining only a few size/color combinations, the ones that don't exist or are not present in the database will not be displayed in dynamic dropdowns.
I plan to add an additional dynamic dropdown switch to enable/disable that "reality" display which ultimately could end up being "moved" to a variant/product area such that each product could be independently controlled to show all possible based on the attributes controller entries or only those that are defined by sba... Different people have different reasons for each.
As to the "giftbox" option, I haven't pushed my initial effort to github yet, but I have a "basic" version working with consideration of a product's option name being considered as non-stock based that does not require modification of displayed sort order (ie doesn't require non-stock attributes to be last or first, but anywhere within the sort list) and have been able to incorporate it into Dynamic Dropdowns.
At the moment it still also enforces the need of and verification that the provided attributes are "permissable" in the sense that if too few/many attributes are provided as compared to the attributes defined then it considers the product as incorrect. There are a lot of variations that become possible with this which is something I am trying to address. The simplest form of use would be that of one or more checkboxes being considered as non-stock related. It seems that there are still a few issues/kinks regarding having more than one checkbox associated with a product to enforce the existence of the combination(s) when the attributes are stock controlling. Understand though that there is no data passed forward for an unchecked checkbox and having two or more checkboxes results in the "need" for multiple variants (if referring to combined variants).
So, perhaps you can see just at the onset how chaotic it can all get. In working this I've created a separate table to track the various options that are non-stock dependent where they can be defined by being a single product's option value being non-stock dependent, a product's option name being non-stock dependent, a specific option value regardless of product and a complete option name. Convenience of handling it this way is that upon addition of such a new "possibility" the table is also minimized based on the selections already present. A programming trade-off though is once say an option name becomes fully non-stock, the addition of that option name to a new product becomes a "trigger" point at which to discover if the option name should continue to be fully non-stock or if it should be split out to include all product but the new product... Could just collect a huge list of all option values and deal with things that way, but seems like a waste of database space when such "tipping" points can be used.
I plan to push the basic code to github soon and until a decent handler is generated, entry of records will likely have to be by SQL statement which is only going to make things that much more "fun" once the handlers are generated (have to "correct" issues that are intended to be addressed by proper database management). I have some ideas about how to present some of the information in the SBA management screen, but so far mentally the solution is based on one maybe two attributes or values being "optional/non-stock". Any more than that and start talking about the need for "spreadsheets" or "lists" of the possible variants, etc... As for the capacity that has been shown, one could identify a product's options value as being non-stock based (could be added/selected as an "add-on" but would not require a specific stock quantity to be identified), a product's option name as being non-stock based (any selection with the option name group would be non-stock based), an option value regardless of product assignment would be non-stock, and an option name (also regardless of product) would be non-stock based.
Biggest hurdle to overcome is all of the "display" of information/conditions in a useful manner and store owner interaction through the various arrangements. Ideally wouldn't have to modify other files, but in some cases to accomplish that means the display of some sort of intermediary screen adding "steps" to the process... Even attempting to insert javascript in some cases in the admin has not yet been made "easy" without editing a file.
Bookmarks