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

mc12345678:

Ok. So hope you haven't run off and tried to "restore" the modified shopping_cart header file. The problem will persist even so.

I found the issue and was able to reproduce it.

Line 948 of includes/classes/observers/class.products_with_attributes_stock.php

Change:

      if ($SBAqtyAvailable - $products[$i]['quantity'] < 0 || $totalQtyAvailable - $_SESSION['cart']->in_cart_mixed($productArray[$i]['id']) < 0) {

> To:
> ```
          if ($SBAqtyAvailable - $products[$i]['quantity'] < 0 || ($totalQtyAvailable - $_SESSION['cart']->in_cart_mixed($productArray[$i]['id']) < 0) && STOCK_ALLOW_CHECKOUT! !== 'true') {

That will resolve the marking of all product in the cart associated with the one products_id where the total quantity of the item's variants has exceeded the total available quantity of the item.

So, understand also that the concept of variant quantity and product quantity relates to some individuals conditions. Ie. Assume the shirts you sell are hand made/decorated. If you have 4 shirts, but enough product of one type to make 3 and enough product of another to make 2, well you only have 4 shirts. Which do you decide to not be able to make? Or do you let the purchase power of the customer figure it out for you by them buying what they want of what you have?

As to the other notification? Well, at one point around the same location in that file, the "feature" was basically disabled... seeing that someone wants it/likes it? I'll gladly put it back. I haven't looked for it recently and can't recall where I saw it, but at one point there was a lot of discussion that the maximum available quantity of a product shouldn't be made known... the store has been designed/redesigned to quite the contrary, so guess it was a false alarm...

The changes will be in that one file, so you don't have to do any sort of total reinstall. I have to figure out how to reinstate the remaining quantity and do so on something other than my cell phone. :)

OK, thanks so much, I will try that! I did test with the Allow Checkout setting set to False, and it does work perfectly that way. It is only when allow checkout is set to true, because then customers can have as many as they want in the cart with no indication as to which will be shipped right away and which will be put on backorder.

In this store, they have single attributes only, so it's not an issue. I see your point though when multiple attributes are involved.

mc12345678:

Ok. So hope you haven't run off and tried to "restore" the modified shopping_cart header file. The problem will persist even so.

I found the issue and was able to reproduce it.

Line 948 of includes/classes/observers/class.products_with_attributes_stock.php

Change:

      if ($SBAqtyAvailable - $products[$i]['quantity'] < 0 || $totalQtyAvailable - $_SESSION['cart']->in_cart_mixed($productArray[$i]['id']) < 0) {

> To:
> ```
          if ($SBAqtyAvailable - $products[$i]['quantity'] < 0 || ($totalQtyAvailable - $_SESSION['cart']->in_cart_mixed($productArray[$i]['id']) < 0) && STOCK_ALLOW_CHECKOUT! !== 'true') {

That will resolve the marking of all product in the cart associated with the one products_id where the total quantity of the item's variants has exceeded the total available quantity of the item.

So, understand also that the concept of variant quantity and product quantity relates to some individuals conditions. Ie. Assume the shirts you sell are hand made/decorated. If you have 4 shirts, but enough product of one type to make 3 and enough product of another to make 2, well you only have 4 shirts. Which do you decide to not be able to make? Or do you let the purchase power of the customer figure it out for you by them buying what they want of what you have?

As to the other notification? Well, at one point around the same location in that file, the "feature" was basically disabled... seeing that someone wants it/likes it? I'll gladly put it back. I haven't looked for it recently and can't recall where I saw it, but at one point there was a lot of discussion that the maximum available quantity of a product shouldn't be made known... the store has been designed/redesigned to quite the contrary, so guess it was a false alarm...

The changes will be in that one file, so you don't have to do any sort of total reinstall. I have to figure out how to reinstate the remaining quantity and do so on something other than my cell phone. :)

I tried changing that line, but the cart behavior remains the same, it shows all variants as out of stock.

Danielle:

I tried changing that line, but the cart behavior remains the same, it shows all variants as out of stock.

Umm do my eyes deceive me or in the new line did I type: STOCK_ALLOW_CHECKOUT followed by 2 exclamation points? (effectively negating the whole reason the content was added? Dang "grammar" checker... I knew I typed it, but didn't see the first one so I typed it again...

Please correct that first and retest before applying the below potential fix...

I really hope that removing the first exclamation point fixes it, because I can perceive how there are some other issues that could crop up if that doesn't do it and the below has to be applied...

Ok, then in the same file, and I'm thinking that the main header_php.php file may have caused the marker to be present, going to add a check to clear the condition for the unaffected product. Btw, you did navigate away from the shopping cart and/or login/out to clear the session right? I could test before posting the fix I am proposing but it's not fun to program and test together via mobile.

So same area:

          if ($SBAqtyAvailable - $products[$i]['quantity'] < 0 || (($totalQtyAvailable - $_SESSION['cart']->in_cart_mixed($productArray[$i]['id']) < 0) && STOCK_ALLOW_CHECKOUT !== 'true') ) {
            $productArray[$i]['flagStockCheck'] = '<span class="markProductOutOfStock">' . STOCK_MARK_PRODUCT_OUT_OF_STOCK . '</span>';
            $flagAnyOutOfStock = true;
          }

To:

          if ($SBAqtyAvailable - $products[$i]['quantity'] < 0 || (($totalQtyAvailable - $_SESSION['cart']->in_cart_mixed($productArray[$i]['id']) < 0) && STOCK_ALLOW_CHECKOUT !== 'true') ) {
            $productArray[$i]['flagStockCheck'] = '<span class="markProductOutOfStock">' . STOCK_MARK_PRODUCT_OUT_OF_STOCK . '</span>';
            $flagAnyOutOfStock = true;
          } else if (zen_not_null($productArray[$i]['flagStockCheck']) && (($totalQtyAvailable - $_SESSION['cart']->in_cart_mixed($productArray[$i]['id']) < 0) && STOCK_ALLOW_CHECKOUT === 'true') {
    $productArray[$i]['flagStockCheck'] = '';
}

Danielle:

OK, thanks so much, I will try that! I did test with the Allow Checkout setting set to False, and it does work perfectly that way. It is only when allow checkout is set to true, because then customers can have as many as they want in the cart with no indication as to which will be shipped right away and which will be put on backorder.

In this store, they have single attributes only, so it's not an issue. I see your point though when multiple attributes are involved.

Realize it doesn't apply to how this store is setup. A store with a single attribute could still need/want the arrangement I described. If the product were all entered such that a shirt was one size and the options were say the color of beads to be embroidered into it, then the one attribute could be color for example having red or blue as options... yes, all a matter of perspective and operation.

Danielle, for the product in question, what is the setting for Product qty Min/Unit Mix?

I have confirmed that if the code beginning at line 948 of includes/classes/observers/class.products_with_attributes_stock.php is changed from:

          if ($SBAqtyAvailable - $products[$i]['quantity'] < 0 || $totalQtyAvailable - $_SESSION['cart']->in_cart_mixed($productArray[$i]['id']) < 0) {
            $productArray[$i]['flagStockCheck'] = '<span class="markProductOutOfStock">' . STOCK_MARK_PRODUCT_OUT_OF_STOCK . '</span>';
            $flagAnyOutOfStock = true;
          }

To:

          if ($SBAqtyAvailable - $products[$i]['quantity'] < 0 || [B](([/B]$totalQtyAvailable - $_SESSION['cart']->in_cart_mixed($productArray[$i]['id']) < 0[B]) && STOCK_ALLOW_CHECKOUT !== 'true')[/B] ) {
            $productArray[$i]['flagStockCheck'] = '<span class="markProductOutOfStock">' . STOCK_MARK_PRODUCT_OUT_OF_STOCK . '</span>';
            $flagAnyOutOfStock = true;
          }[B] else if (zen_not_null($productArray[$i]['flagStockCheck']) && (($totalQtyAvailable - $_SESSION['cart']->in_cart_mixed($productArray[$i]['id']) < 0) && STOCK_ALLOW_CHECKOUT === 'true') {
            $productArray[$i]['flagStockCheck'] = '';
          }[/B]

Then for the store setup condition of:
-the product is set to have Product Qty Min/Unit Mix set to true,
-the stock is allowed to sell beyond the available quantity (STOCK_ALLOW_CHECKOUT === 'true',
-the variant quantity in the cart exceeds total stock quantity of the product.

That only the individual variant that has a quantity greater than the identified variant will show as out-of-stock (or the soon to be provided message associated such as the total number of that variant available). Mind you that information is available for display on the product page. Of course by the time they get to the shopping cart that quantity may have also changed (first one to checkout wins).

I am looking at adding a switch to control how this area of the code operates in the condition of STOCK_ALLOW_CHECKOUT === 'true' so that the other behavior could be used if desired. (which in turn means that could lead to each individual product being able to be controlled independently by substitution of the defined value with a database look up.)

Of course my other concern still holds. Ie. One variant in the cart. The available quantity of that variant is more than the total quantity of the product. As soon as the quantity selected exceeds the available quantity, a message appears at the top of the cart indicating out-of-stock (this is because of the check in the base header_php.php file identifying that the in cart mix quantity exceeds the total quantity of product. Then using the above code, the individual variant is dismissed from being out-of-stock because the individual variant quantity has not been exceeded. So the result is a message saying those identified as out-of-stock are marked below (assuming one uses a marker), but none of the product is marked...

Easy solution in a one item/variant cart, becomes a little more convoluted for the rest, though going to make it work without forcing ZC not to be able to be setup this way and not to limit its capabilities.

Sorry for all the posts, I've conceptualized how to make it work without additional database query.

Both issues addressed to my "current" satisfaction. :) There is room for expansion and other application, some of which will eventually get incorporated, but for now, the product marking has been modified for stores that allow checkout with product that are out-of-stock (either by variant or by total product) to just mark the individual variant and not as observed where all variants for a product would be marked out-of-stock. There has been a switch point incorporated to allow such identification for those that have determined such a need (STOCK_MARK_ALLOW_MIX_TOTAL_ALL set to true will change the operation to show all variants of a product as out-of-stock when the total quantity of variant in the cart exceeds the allowable total positive quantity of product. ie. quantity of variant - total product quantity < 0).

On the shopping cart page, if a variant is marked out of stock (less than 0 or purchasing will result in such) then based on the actual quantity that remain one of three types of message (which were already in the overridden shopping_cart template) will be displayed. If the total quantity of the available variant is <=0 then out-of-stock will be displayed, then if the quantity of variant is less than the STOCK_REORDER_LEVEL (level at which notification is made to re-order stock), then a low-level with remaining quantity message will appear. then, if however the remaining quantity of the variant is above that number a message indicating the available quantity only will be displayed. Of course these messages can be modified, but thought those interested might like to understand under the hood a little.

This is all captured in the latest download of the master branch: https://www.github.com/mc12345678/Stock_By_Attributes_Combined.

Additional comment welcome.

Thank you! It is working perfectly now. I really appreciate all of your help :)

mc12345678:

Both issues addressed to my "current" satisfaction. :) There is room for expansion and other application, some of which will eventually get incorporated, but for now, the product marking has been modified for stores that allow checkout with product that are out-of-stock (either by variant or by total product) to just mark the individual variant and not as observed where all variants for a product would be marked out-of-stock. There has been a switch point incorporated to allow such identification for those that have determined such a need (STOCK_MARK_ALLOW_MIX_TOTAL_ALL set to true will change the operation to show all variants of a product as out-of-stock when the total quantity of variant in the cart exceeds the allowable total positive quantity of product. ie. quantity of variant - total product quantity < 0).

On the shopping cart page, if a variant is marked out of stock (less than 0 or purchasing will result in such) then based on the actual quantity that remain one of three types of message (which were already in the overridden shopping_cart template) will be displayed. If the total quantity of the available variant is <=0 then out-of-stock will be displayed, then if the quantity of variant is less than the STOCK_REORDER_LEVEL (level at which notification is made to re-order stock), then a low-level with remaining quantity message will appear. then, if however the remaining quantity of the variant is above that number a message indicating the available quantity only will be displayed. Of course these messages can be modified, but thought those interested might like to understand under the hood a little.

This is all captured in the latest download of the master branch: https://www.github.com/mc12345678/Stock_By_Attributes_Combined.

Additional comment welcome.

Danielle:

Thank you! It is working perfectly now. I really appreciate all of your help :)

Thanks for the feedback (before and now), can only know to make changes when an issue is identified. Thank you also for putting up with me. :) normally I'm not so difficult. Verbose... sure (almost a running joke around here.). But wouldn't think difficult. :)

mc12345678:

Thanks for the feedback (before and now), can only know to make changes when an issue is identified. Thank you also for putting up with me. :) normally I'm not so difficult. Verbose... sure (almost a running joke around here.). But wouldn't think difficult. :)

No, I didn't think you were difficult at all! I thought I was being difficult haha. I am super impressed and grateful for how quickly you addressed and resolved this!

Having an issue: The admin page is blank after installing this module.

Downloaded it from: https://www.zen-cart.com/downloads.php?do=file&id=202
Version is 1.5.3
My Zen Cart version is 1.5.5e

Renamed the admin and template folders as instructed. Used Filezilla to drag and drop the files

The error log shows:

PHP Fatal error: Call to undefined function zen_get_ip_address() in /home/(myfolder)/public_html/(myadmin)/includes/init_includes/init_sessions.php on line 31

Line 31 of that file is: $ipAddressArray = explode(',', zen_get_ip_address());

What am I missing?

In2Deep:

Having an issue: The admin page is blank after installing this module.

Downloaded it from: https://www.zen-cart.com/downloads.php?do=file&id=202
Version is 1.5.3
My Zen Cart version is 1.5.5e

Renamed the admin and template folders as instructed. Used Filezilla to drag and drop the files

The error log shows:

PHP Fatal error: Call to undefined function zen_get_ip_address() in /home/(myfolder)/public_html/(myadmin)/includes/init_includes/init_sessions.php on line 31

Line 31 of that file is: $ipAddressArray = explode(',', zen_get_ip_address());

What am I missing?

The files compatible with ZC 1.5.5 (and more up-to-date) that can be found at: https://github.com/mc12345678/Stock_By_Attributes_Combined

The version currently for download from zen-cart.com is only for ZC 1.5.1 (or rather requires a lot of effort to merge/work with ZC 1.5.5 that efort has already been done at the above location and with additional improvements).

Please post with additional question and/or status.

mc12345678:

The files compatible with ZC 1.5.5 (and more up-to-date) that can be found at: https://github.com/mc12345678/Stock_By_Attributes_Combined

The version currently for download from zen-cart.com is only for ZC 1.5.1 (or rather requires a lot of effort to merge/work with ZC 1.5.5 that efort has already been done at the above location and with additional improvements).

Please post with additional question and/or status.

Thank you, should I restore from my backed up files and database and then try again with these files or would it suffice to just upload these new files from github?

In2Deep:

Thank you, should I restore from my backed up files and database and then try again with these files or would it suffice to just upload these new files from github?
I would restore the files. The database has not been affected in a way that needs restoration.

mc12345678:

I would restore the files. The database has not been affected in a way that needs restoration.

Got it. Seems to be working just fine now. I wish they would just remove that old plugin link.

In2Deep:

Got it. Seems to be working just fine now. I wish they would just remove that old plugin link.

I can respect and understand the thought; however, there is nothing wrong with the software as advertised in that it only works with ZC 1.5.1 as advertised. But, as to having a more up-to-date version presented there, I'd say that's on me. In order to submit software for posting, there are some minimum instructions required. Potteryhouse began some, but they describe only a limited amount of what the software can do and at this time do not really want to advertise it having such limited capability. For the time being having been providing support through this forum where even in the recent few pages most "issues" are covered and capability described. Atop that, while I have received some development support, often other priorities make it to the top of the list.

Further as is the case with plugins and open source, users should protect themselves like you did of backing up before trying something new and try on a development location first.

Test install of ZenCart upgrade from 1.5.1 to 1.5.4. on linux with SBA from github - using Stock_By_Attributes_Combined-master, file: 1_5_3 and 1_5_4

Can only work on this in our offseason so into it now for almost a year with a multitude of mods all working but SBA and numinex extra fields

Question: is there a sql statement I am missing for SBA? I can not see the SBA in the admin.
Question 2: am I using the correct file of 1_5_3 and 1_5_4 for ZenCart 1.5.4?

Thanks everyone for working on this mod. Our upgrades of zencart depend on it working. I've always had to tweak it so much... hoping progress is steady and sure.

athena:

Test install of ZenCart upgrade from 1.5.1 to 1.5.4. on linux with SBA from github - using Stock_By_Attributes_Combined-master, file: 1_5_3 and 1_5_4

Can only work on this in our offseason so into it now for almost a year with a multitude of mods all working but SBA and numinex extra fields

Question: is there a sql statement I am missing for SBA? I can not see the SBA in the admin.
Question 2: am I using the correct file of 1_5_3 and 1_5_4 for ZenCart 1.5.4?

Thanks everyone for working on this mod. Our upgrades of zencart depend on it working. I've always had to tweak it so much... hoping progress is steady and sure.

To be sure all in place: All SBA installs require the initial includes and admin directories (in an approaching change will be restructuring the file folders to make this easier to understand just by looking at the fileset). To further incorporate the software into the applicable ZC version then the applicable ZC version directory is used/merged (i.e. 1_5_3 and 1_5_4 to support installation to ZC 1.5.4).

Working in this sequence, there is no disruption to site operation during installation.

As to the absence of any SBA related items on the admin side, after all applicable files have been placed installation requires execution/access of the admin file: stock_by_attr_install.php (ie. YOUR_DOMAIN_NAME/YOUR_CATALOG_DIRECTORY/YOUR_ADMIN_DIRECTORY/stock_by_attr_install.php)

So any one or combination of the below could be the cause:

1. Depending also on the install/upgrade path/method the applicable files may not have been placed,
2. the database may not have yet been transferred to have the old "connection" to the install, or
3. the install has not been accessed with the currently loaded database in place.