Stock by Attribute v4.0 addon for v1.3.5-1.3.9

[mc12345678]

What did you mean by this statement? Did you work this fix into the last update or are you still testing it?

Yes, the files have been updated to support an admin switch (placed in the attrbute settings section of the configuration menu) to disable display of the customid in the attribute dropdowns. Installation for those that have already gotten their SBA related settings would be to upload the files and run the sql provided above, or for those with a new setup/don't mind adjusting the SBA (dynamic dropdowns as well) setting can do the install/upgrade provided in the SBA configuration menu *after* the files are uploaded... If the files are not uploaded but the sql is performed, then the switch does nothng. If the files are uploaded but the sql (setup) is not performed then the customid will default to being on.

[jnabird333]

Besides the one question about where the quantity is checked by attributes php....where are the dynamic dropdowns controlled as I feel they are still not working as described?

alana

[mc12345678]

Where does the quantity get checked for the attributes in SBA to show "out of stock"? What .php file controls this?

While I am still setting up and testing, I have not gone through a test purchase to verify the correct product quantity goes down. (I buy 1 small blue t-shirt, then the small blue t-shirt product quantity in the SBA screen goes down.)

Two maybe three areas to address that question... The "display" of out-of-stock in the dropdowns is done in the includes/classes/observers/class.products_with_attributes_stock.php (if I remember the full filename correctly, there's only one such file added by the plugin) in the sections of code that start with updateAttributes as the includes/modules/YOUR_TEMPLATE/attributes.php file is processed... Those sections go out to the includes/functions/extra_functions/products_with_attributes.php (I think it's called) file to process the data passed to it.

Now, if dynamic dropdowns is "activated" and being used, then the stock verification is done throught the combination of includes/classes/pad_base.php and pad_sbadropdown (or whatever it got called) with the functions of the second file overriding the equivalent functions of the first. (I still think the creation of that plugin was rather ingenious). The "stock" check is then performed through some javascript calculations/comparisons.

Now the issue of decrement of stock... Well, before it gets purchased there is an extra_cart actions file that inspects the contents being passed to the cart... That code is what is run regardless of DD being used or not... The DD "interface" is just a bit of a nicety showing the customer up front the current status. The real meat though is in this extra cart file. It performs a check of the provided attributes that are expected to be formatted in a typical ZC fashion to
1) Verify that the provided attributes make a product that exists in the SBA table
2) Verify that there is a quantity currently available as determined by the SBA table stock quantities...
3) If the quantity in the cart is adjusted it again verifies the presence of quantity. It does not again check for the accuracy of the combinations of attributes of the product to be defined.

Failure of either of the first two prevents addition of the product to the cart/adjustment of the requested quantity to that on hand. Failure of the third adjusts quantity to the maximum available assuming that's how the store is setup... There's also caveats for those that allow selling on "backorder"..

Now the last part, that is done/addressed through the includes/classes/orders.php file and the same observers file from above... Btw, all of those files rely on the functions file above as well...

Best in all to be sure that all of the files of the plugin are up-to-date with the current distribution so that they can all interact properly together...

I do look forward to your test purchase results assuming the other issues up to that point are resolved.. Remember you don't have to use paypal or something that actually takes your money, you could use a "mail my payment" type purchase to get the same result (downloads are a little tricky for testing in that situation, but that comment is for others than your store).

[mc12345678]

Besides the one question about where the quantity is checked by attributes php....where are the dynamic dropdowns controlled as I feel they are still not working as described?

alana

So, in a "default" install the DD would be presented through includes/templates/YOUR_TEMPLATE/templates/tpl_modules_attributes.php as called through the process of generating the page from includes/templates/YOUR_TEMPLATE/templates/tpl_product_info_default.php and "gathering" the attributes... But seeing the way yours are setup in the template, it appears your template author has "bypassed" that file in place of something else... That is why I identified the variables I did because those variables are the ones generated by attributes.php to be used for display (though that too could have been bypassed by the template author).. In summary, I would say that issue is something you either need to ferret out or discuss with the template provider...

[mc12345678]

Fyi, ran through a few purchase tests... Currently, purchasng two or more "different" product (different text only) does not reduce the stock for all purchased quantity. Test was: had a total of 25 product, in cart had 10 quantity with one version of text. Added the same product but with different text in quantity of 7. Went through the purchase process and only 7 were removed from stock of that product... Not 17... So, need to look at the orders process regarding multiple copies of the same product but different associated data in regards to how SBA does that reduction...

To qualm any other concerns though, tried a purchase of a product that had 2 attributes assigned, one attribute had one and only one choice. The other had three choices. Different quantity (5, 7, and 10) were populated for each of the total three variants. Each variant was a combination of the two attributes. I then added 3 of the first from the above quantity and 7 of the last. The final result was as expected: 2, 7, and 3, respectively.

Now I did have to do something "special" on the add-to-cart in order to account for adding the appropriate quantity of such "non-stock affecting" attributes... Probably have to duplicate something about that in the orders processing part...

[mc12345678]

My guess (yet to be able to prove) is that the query of line 317 of includes/classes/observers/class.products_with_attributes_stock.php needs to be formatted like that of includes/classes/order.php line 734 (zc 1.5.3/1.5.4) such that the select query is "refreshed" for each occurrence, which isn't an issue when the attrbutes (sans text) are different...

So I would think that:

$attribute_stock_available = $db->Execute($get_quantity_query);

Should be:

$attribute_stock_available = $db->Execute($get_quantity_query, false, false, 0, true));

Inside of includes/classes/observers/class.products_with_attributes_stock.php line 317...

Reason behind this thought? Well, the sock quantity only reduced by the "last" product of the same product_id... This meant that the previous select/update combo was run a second time using the same initial data of the original available stock.... Thus, after the first product was removed from stock, when the query was asked again without clearing the cache, the result was the same on the second and final product (same products_id and sba table stock_id, but different text). Will test as soon as I get back to a computer where I can modify the code.


Sorry badarac. :)

[mc12345678]

Yup, that fixed it... Btw, the overall stock *did* decrement on the "problematic" listing earlier before the above fix, just not the individual stock (at the time). Applying the above "fix" allowed checkout stock tracking of product that were listed more than once in the cart, each with different text only,,,

[mc12345678]

Yup, that fixed it... Btw, the overall stock *did* decrement on the "problematic" listing earlier before the above fix, just not the individual stock (at the time). Applying the above "fix" allowed checkout stock tracking of product that were listed more than once in the cart, each with different text only,,,

The minor fix identified above that changed the $db->Execute command has been incorporated into the download. If the software was up-to-date to yesterday or so, then should only have to apply the above posted fixes, otherwise recommend installing the current/new fileset and doing the install. BTW, also added the remove sql to the fileset to support deleting the newly added option. :)

Two files affected: the storeside observers class and the admin's install file.

[badarac]

Sorry for the delay testing things. Been busy with my day job. What should I download to pick up all the changes to test?

[mc12345678]

Sorry for the delay testing things. Been busy with my day job. What should I download to pick up all the changes to test?

I thought your day job might be golfing.

Well, would say latest from http://www.github.com/mc12345678/Sto...butes_Combined. I hadn't done any special download this tag arrangement. It's been quiet there I think for 24 hours now.