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

As you know, I've been trying to eliminate php undefined variable and undefined index notices during operation of the zxpos add-on. zxpos uses zen cart as a point of sale system does as much processing as possible in the browser, so ajax and jscripts are used extensively. The products we plan to sell with the point of sale system are mostly products with attributes, hence all the interaction with you and SBA. The error I've been chasing lately is an undefined index in shopping_cart.php in function in_cart_product_mixed_changed_shopping_cart which occurs when the product quantity is changed on the zxpos main page. The error is caused because the products_mixed_quantity field is set to 1. After setting the field to 0, the error goes away and everything seems to work properly. But the processing path taken for updating quantity on the zxpos main page is completely different from the path when the quantity is changed on the normal zen cart shopping cart page or on the product info page. There are no undefined index notices and in fact, function in_cart_product_mixed_changed_shopping_cart is not entered at all, at least for my products, even when products_mixed_quantity is set to 1 in the database.

At this point, I have eliminated the error I was chasing and can't afford to spend more time finding out why the path is the way it is for the point of sale add-on. Thanks again for all the help and advice, and for your support of SBA.

Dave

Dave224:

As you know, I've been trying to eliminate php undefined variable and undefined index notices during operation of the zxpos add-on. zxpos uses zen cart as a point of sale system does as much processing as possible in the browser, so ajax and jscripts are used extensively. The products we plan to sell with the point of sale system are mostly products with attributes, hence all the interaction with you and SBA. The error I've been chasing lately is an undefined index in shopping_cart.php in function in_cart_product_mixed_changed_shopping_cart which occurs when the product quantity is changed on the zxpos main page. The **error (WHICH? CONTENT OF THE ERROR?) **is caused because the products_mixed_quantity field is set to 1. After setting the field to 0, the error goes away and everything seems to work properly. But the processing path taken for updating quantity on the zxpos main page is completely different from the path when the quantity is changed on the normal zen cart shopping cart page or on the product info page. There are no undefined index notices and in fact, function in_cart_product_mixed_changed_shopping_cart is not entered at all, at least for my products, even when products_mixed_quantity is set to 1 in the database.

At this point, I have eliminated the error I was chasing and can't afford to spend more time finding out why the path is the way it is for the point of sale add-on. Thanks again for all the help and advice, and for your support of SBA.

Dave
You know in the "search"... providing information allows others to figure out the why. Right now there is an issue that happens on some cart somewhere and a specific setting is involved... No problem, whatever.

That said I remember having a conversation with DrByte about setting various variables within that code section to mitigate the possibility of notices, I thought I had a commit/issue submitted on it, but at the moment can not find it.

Note though, not knowing even what the notice is about as in which line, which variable, etc means it could be anything anywhere and that the assistance offered gets returned in kind.

BTW, I happen to know that the code author of that section would really like to resolve any issues with it.

mc12345678:

...
That said I remember having a conversation with DrByte about setting various variables within that code section to mitigate the possibility of notices, I thought I had a commit/issue submitted on it, but at the moment can not find it.
...
Found it. Issue was raised by carlwhat, conversation ensued, solution was identified and proposed that appears to be adopted in ZC 1.5.8 (which could apply to 1.5.7 as well):
shopping cart notices on product update by mc12345678 · Pull Request #4181 · zencart/zencart (github.com)
Don't know if it would fix the above issue(s) though.

The error was an undefined offset notice in includes/classes/shopping_cart.php on or around lines 2593 and 2594 where 'total_change' and 'last_changed' are set. Code follows:
```
$changed_array = array(
'state'=>false,
'changed' => $product_changed,
'total_change' => $product_total_change[$pr_id],
'last_changed' => $product_last_changed[$pr_id],
'increase' => $product_increase,
'decrease' => $product_decrease,
);

Dave

Just downloaded the latest version via GitHub and I noticed the 1.5.7 specific admin folder only has one file, packingslip.php
1.5.6 has edits on attributes_controller.php, invoice.php, and orders.php.

Is this the only core file edit required for 1.5.7?

1.5.7 specific includes folder only has edits for templates, and yet 1.5.6 had an edit in modules/YOUR_TEMPLATE/attributes.php
Is this no longer required?

As well as the above queries, having installed the module, I'm getting the following log file generated when viewing products_with _attributes_stock page in admin.

PHP Fatal error: 1064:You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '))' at line 1 :: select count(distinct p.products_id) as total FROM products p, products_description pd WHERE pd.language_id=1 AND p.products_id = pd.products_id AND (p.products_id IN ( )) ==> (as called by) /Users/developer/Sites/localhost/mysite/myadmin/includes/classes/split_page_results.php on line 39

It looks like it's missing part of the query.

strelitzia:

Just downloaded the latest version via GitHub and I noticed the 1.5.7 specific admin folder only has one file, packingslip.php
1.5.6 has edits on attributes_controller.php, invoice.php, and orders.php.

Is this the only core file edit required for 1.5.7?

1.5.7 specific includes folder only has edits for templates, and yet 1.5.6 had an edit in modules/YOUR_TEMPLATE/attributes.php
Is this no longer required?

As well as the above queries, having installed the module, I'm getting the following log file generated when viewing products_with _attributes_stock page in admin.

PHP Fatal error: 1064:You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '))' at line 1 :: select count(distinct p.products_id) as total FROM products p, products_description pd WHERE pd.language_id=1 AND p.products_id = pd.products_id AND (p.products_id IN ( )) ==> (as called by) /Users/developer/Sites/localhost/mysite/myadmin/includes/classes/split_page_results.php on line 39

It looks like it's missing part of the query.
First off, need to look into what is causing that logged issue, certainly something is amiss there, even if the value within the parentheses should be 0, it well shouldn't be because no products_id should be 0. That said, there have been occurrences of databases losing their auto-numbering and then therefore a new product gets assigned to the products_id of 0.

As to the fileset, yes, there is only one admin file that is modified and it is only modified to support the use of an image swap plugin that needed to have the notifier that was included. I was asked to incorporate it long ago and so it remains in support of that site's use and potential further development for the community.

There are a few files on the catalog side if you want to use the provided dynamic dropdowns. Basically, after I did more testing and had seen additional "issues" of not keeping each ZC file up-to-date, I did what I could to divorce the code of the plugin from the core/template of ZC without losing any of the existing features of the plugin... There are some ways to remove the tpl_modules_attributes.php modifications, but its going to take me some work because for one, once I do that the "background" for displaying the information is going to get a serious overhaul. There are other better "dropdown" tools out there that could be incorporated with/against javascript/jQuery and that's the path/route that would need to be taken to basically remove the edits from that file.

As to not needing the other files for ZC 1.5.7 that are included in ZC 1.5.6? Well, I finally took advantage of some ZC version specifics... ZC V1.5.7 added a new style of observers and a few more observers were added in general. Now, if one hasn't updated to the latest of 1.5.7(c) then there may be some "features" missing. But because older versions don't have all of the same notifiers and do not process notifiers the same way, they currently need the extra edits and files (until either they also get updated or everyone upgrades. :))

Anyways, please read this post for more of the details that I likely missed above: https://www.zen-cart.com/showthread.php?47180-Stock-by-Attribute-v4-0-addon-for-v1-3-5-1-3-9&p=1380068#post1380068

Thanks for the detailed response there.

One thing I have noticed, line 995 of admin/products_with_attributes_stock.php appears to have a misplaced {

The line in question is ```
/if (zen_not_null($action))/ {

Now, I'll admit I didn't go over every line before it, given that the preceding code is all related to the header section of the page, it seems odd to see an opening brace here.

On another note, the file seems to have a LOT of commented out lines. Is this deprecated from older versions?
The reason for asking is that I was considering updating the page to use the newer admin divs and form fields, cleaning out the unrequited code whilst I was in there.
I realise that you may have avoided the page styling updates to maintain backward compatibility, but I don't work with anything but the latest ZC version, so having the newer styling would be more in keeping with the default zc pages.

strelitzia:

Thanks for the detailed response there.

One thing I have noticed, line 995 of admin/products_with_attributes_stock.php appears to have a misplaced {

The line in question is ```
/if (zen_not_null($action))/ {

> Now, I'll admit I didn't go over every line before it, given that the preceding code is all related to the header section of the page, it seems odd to see an opening brace here.
> 
> On another note, the file seems to have a LOT of commented out lines. Is this deprecated from older versions?
> The reason for asking is that I was considering updating the page to use the newer admin divs and form fields, cleaning out the unrequited code whilst I was in there.
> I realise that you may have avoided the page styling updates to maintain backward compatibility, but I don't work with anything but the latest ZC version, so having the newer styling would be more in keeping with the default zc pages.

It wouldn't be a line before it, but instead a line about 420 after it. Line 1416 containes the closing parentheses. At some point I realized that it seemed like the zen_not_null check was unnecessary, but I didn't have a handy ide available at the time and when I did get in with one, it wanted to readjust almost all of the code to proper spacing, blah, blah, blah... So I just commented out the "functional" part I no longer needed.

So other comments? Well, yeah, old code that was being used, but has been replaced or otherwise worked around... prob... this software has been in such a flux over the years that I didn't want to make it impossible to upgrade and in socases the concept was great, and in other cases as much as I try to test, there almost always seems to be something that doesn't bother how I use it, but does for someone else...

Personally, go ahead and do whatever with the admin formatting. I'm personally disappointed that there is no "structure" that things can be fit into and that there is so much busy work necessary to get things to look the way they do. Id be glad to use what you come up with and likely would just split the code up/out so that different versions can have different formatting. That's just me because I worry more about if/how things work than how they look. I also appreciate art, so don't get me wrong there.

Now, as to that earlier error message, there has to be more to that message because what I see is that there is a problem with the split page class as called from who knows what query, what data on the uri, etc... could I have the other sanitized info?

mc12345678:

Now, as to that earlier error message, there has to be more to that message because what I see is that there is a problem with the split page class as called from who knows what query, what data on the uri, etc... could I have the other sanitized info?

The entirety of the error log is below

[28-May-2021 00:45:28 Europe/Paris] Request URI: /myadmin/index.php?cmd=products_with_attributes_stock, IP address: ::1
#1 trigger_error() called at [/Users/developer/Sites/localhost/mysite/includes/classes/db/mysql/query_factory.php:170]
#2 queryFactory->show_error() called at [/Users/developeer/Sites/localhost/mysite/includes/classes/db/mysql/query_factory.php:142]
#3 queryFactory->set_error() called at [/Users/developer/Sites/localhost/mysite/includes/classes/db/mysql/query_factory.php:269]
#4 queryFactory->Execute() called at [/Users/developer/Sites/localhost/mysite/myadmin/includes/classes/split_page_results.php:39]
#5 splitPageResults->__construct() called at [/Users/developer/Sites/localhost/mysite/myadmin/includes/classes/products_with_attributes_stock.php:607]
#6 products_with_attributes_stock->displayExcessRows() called at [/Users/developer/Sites/localhost/mysite/myadmin/products_with_attributes_stock.php:1512]
#7 require(/Users/developer/Sites/localhost/mysite/myadmin/products_with_attributes_stock.php) called at [/Users/developer/Sites/localhost/mysite/myadmin/index.php:11]
--> PHP Fatal error: 1064:You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '))' at line 1 :: select count(distinct p.products_id) as total FROM products p, products_description pd WHERE pd.language_id=1 AND p.products_id = pd.products_id AND (p.products_id IN ( )) ==> (as called by) /Users/developer/Sites/localhost/mysite/myadmin/includes/classes/split_page_results.php on line 39 <== in /Users/developer/Sites/localhost/mysite/includes/classes/db/mysql/query_factory.php on line 170.

strelitzia:

The entirety of the error log is below

[28-May-2021 00:45:28 Europe/Paris] Request URI: /myadmin/index.php?cmd=products_with_attributes_stock, IP address: ::1
#1 trigger_error() called at [/Users/developer/Sites/localhost/mysite/includes/classes/db/mysql/query_factory.php:170]
#2 queryFactory->show_error() called at [/Users/developeer/Sites/localhost/mysite/includes/classes/db/mysql/query_factory.php:142]
#3 queryFactory->set_error() called at [/Users/developer/Sites/localhost/mysite/includes/classes/db/mysql/query_factory.php:269]
#4 queryFactory->Execute() called at [/Users/developer/Sites/localhost/mysite/myadmin/includes/classes/split_page_results.php:39]
#5 splitPageResults->__construct() called at [/Users/developer/Sites/localhost/mysite/myadmin/includes/classes/products_with_attributes_stock.php:607]
#6 products_with_attributes_stock->displayExcessRows() called at [/Users/developer/Sites/localhost/mysite/myadmin/products_with_attributes_stock.php:1512]
#7 require(/Users/developer/Sites/localhost/mysite/myadmin/products_with_attributes_stock.php) called at [/Users/developer/Sites/localhost/mysite/myadmin/index.php:11]
--> PHP Fatal error: 1064:You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '))' at line 1 :: select count(distinct p.products_id) as total FROM products p, products_description pd WHERE pd.language_id=1 AND p.products_id = pd.products_id AND (p.products_id IN ( )) ==> (as called by) /Users/developer/Sites/localhost/mysite/myadmin/includes/classes/split_page_results.php on line 39 <== in /Users/developer/Sites/localhost/mysite/includes/classes/db/mysql/query_factory.php on line 170.
Looks like in admin/includes/classes/products_with_attributes_stock.php Line 557 should change: isset to !empty

Seems the same applies to line 564 as well.
Changing
isset(
To:
!empty(
Alternatively could go ahead and initialize that variable from the code making the call. Instead of defaulting its value to an array, it could be defaulted to null and then made whatever is desired on that.

mc12345678:

Looks like in admin/includes/classes/products_with_attributes_stock.php Line 557 should change: isset to !empty

Seems the same applies to line 564 as well.
Changing
isset(
To:
!empty(
Alternatively could go ahead and initialize that variable from the code making the call. Instead of defaulting its value to an array, it could be defaulted to null and then made whatever is desired on that.
Confirmed, for those two locations, changing isset to !empty fixed the issue.
in admin/includes/classes/products_with_attributes_stock.php
from:

        if (isset($ReturnedProductID) && is_array($ReturnedProductID)) {
          foreach ($ReturnedProductID as $key => &$singleID) {
            $singleID = (int)zen_db_input($singleID);
          }
          unset($singleID);
          $w = " AND (p.products_id IN (" . implode(',', $ReturnedProductID) . " )) ";
          $ReturnedProductID = array_pop($ReturnedProductID);
        } elseif (isset($ReturnedProductID)) {
  

To:

        if (!empty($ReturnedProductID) && is_array($ReturnedProductID)) {
          foreach ($ReturnedProductID as $key => &$singleID) {
            $singleID = (int)zen_db_input($singleID);
          }
          unset($singleID);
          $w = " AND (p.products_id IN (" . implode(',', $ReturnedProductID) . " )) ";
          $ReturnedProductID = array_pop($ReturnedProductID);
        } elseif (!empty($ReturnedProductID)) {
  

mc12345678:

Confirmed, for those two locations, changing isset to !empty fixed the issue.

I was just about to confirm the same.
Thanks for your assistance on this McNumbers

strelitzia:

I was just about to confirm the same.
Thanks for your assistance on this McNumbers
Thanks for pointing it out and look forwards to the admin revisions. I updated the github fileset around the time I posted my verification.

I was able to confirm operation because I have/had a record that triggers the alternate group of information (which was showing when I went through testing). I "disabled" capturing the information to validate that the expected text "place holder" was shown. Not saying I really like the default text that is there, but I wanted something to be shown so that if/when a problem occurred one may recognize the discrepancy.

Further note that generally speaking I don't expect that this area of code will need to be accessed in a store that implemented SBA at/after the point that option names/values were monitored for deletion. It was prior to that point in time that deletion of option names/values from the standard part of the store did not carry into SBA. As a result a product that was previously tracked by SBA and had variants present before attribute deletion would appear to still be tracked by SBA even if it no longer had attributes. (When that happens a mydebug log gets generated during attempts to checkout) A little more can be read up on that in dbltoe's recent posts a few pages back (337 based on my current use of 10 posts per page).

mc12345678:

Thanks for pointing it out and look forwards to the admin revisions

I have a quick query regarding the initial products_with_attributes_stock page.

Below the text Stock By Attributes - Top there is a dropdown where I can select a category. Making a selection here will open the products_filter select which displays all the products within that category.
I'm trying to figure out the difference between the 'Search' button above the select, and the 'display' button to the right of the select.
Both seem to have the same end result of displaying the selected product. Can one of these be removed, or is there another purpose for one or the other that I am unaware of?
If one can be removed, which button label would you prefer to stay. IMO, 'display' seems to make more sense as you are not actually searching for anything at this point, merely making an option selection from what's presented in the select.

@mc12345678
A quick preview of the modified layout for the first section of the page (pending your response re the 'search' button.

I've come across an issue that appears to be SBA related as prior to it being installed there was no such problem.
Site is running ZC 1.5.7c with the latest version of SBA from Github
Admin>Configuration>Stock>Allow Checkout set to 'false'

If there are any products in the cart that DO NOT have variants set, these can be either products with, or without attributes, it is not possible to proceed from shopping cart to checkout.

The following error gets logged.

[08-Jun-2021 22:39:26 Europe/London] Request URI: /index.php?main_page=checkout_shipping, IP address: 82.5.203.28
#1 explode() called at [/home/mysite/public_html/includes/functions/functions_general_shared.php:147]
#2 zen_get_prid() called at [/home/mysite/public_html/includes/functions/functions_lookups.php:174]
#3 zen_get_products_stock() called at [/home/mysite/public_html/includes/classes/observers/class.products_with_attributes_stock.php:1869]
#4 products_with_attributes_stock->updateNotifyHeaderStartCheckoutShipping() called at [/home/mysite/public_html/includes/classes/class.base.php:118]
#5 base->notify() called at [/home/mysite/public_html/includes/modules/pages/checkout_shipping/header_php.php:11]
#6 require(/home/mysite/public_html/includes/modules/pages/checkout_shipping/header_php.php) called at [/home/mysite/public_html/index.php:35]
--> PHP Warning: explode() expects parameter 2 to be string, array given in /home/mysite/public_html/includes/functions/functions_general_shared.php on line 147.

Any suggestions on this issue?

strelitzia:

I've come across an issue that appears to be SBA related as prior to it being installed there was no such problem.
Site is running ZC 1.5.7c with the latest version of SBA from Github
Admin>Configuration>Stock>Allow Checkout set to 'false'

If there are any products in the cart that DO NOT have variants set, these can be either products with, or without attributes, it is not possible to proceed from shopping cart to checkout.

The following error gets logged.

[08-Jun-2021 22:39:26 Europe/London] Request URI: /index.php?main_page=checkout_shipping, IP address: 82.5.203.28
#1 explode() called at [/home/mysite/public_html/includes/functions/functions_general_shared.php:147]
#2 zen_get_prid() called at [/home/mysite/public_html/includes/functions/functions_lookups.php:174]
#3 zen_get_products_stock() called at [/home/mysite/public_html/includes/classes/observers/class.products_with_attributes_stock.php:1869]
#4 products_with_attributes_stock->updateNotifyHeaderStartCheckoutShipping() called at [/home/mysite/public_html/includes/classes/class.base.php:118]
#5 base->notify() called at [/home/mysite/public_html/includes/modules/pages/checkout_shipping/header_php.php:11]
#6 require(/home/mysite/public_html/includes/modules/pages/checkout_shipping/header_php.php) called at [/home/mysite/public_html/index.php:35]
--> PHP Warning: explode() expects parameter 2 to be string, array given in /home/mysite/public_html/includes/functions/functions_general_shared.php on line 147.

> 
> Any suggestions on this issue?
Reproduced with same setting of limiting stock to what is available (not allowing checkout if stock is out).

Brief review of the code of the observer indicates that because I've changed to using an array internally for this area of code, that at/before any return from the function should set the products_quantity and the handled flag. Further, because of the early escape reasons for leaving the function and that there is a reason within SBA code to effectively duplicate the return logic from zen_get_products_stock, I will create a separate internal class method that will effectively use the code from the ZC software. Not at all what I really want(ed) to do, but doing this removed(s) the need to modify the core code. Anyways, I expect to have something in a few hours. Have some other things to which to tend. 

I can say that testing of product with/without variants and attributes was performed it appears with the above configuration set to true. That works, but... does not support all stores and would permit overselling when that is not acceptable/desired...

strelitzia:

I've come across an issue that appears to be SBA related as prior to it being installed there was no such problem.
Site is running ZC 1.5.7c with the latest version of SBA from Github
Admin>Configuration>Stock>Allow Checkout set to 'false'

If there are any products in the cart that DO NOT have variants set, these can be either products with, or without attributes, it is not possible to proceed from shopping cart to checkout.

The following error gets logged.

[08-Jun-2021 22:39:26 Europe/London] Request URI: /index.php?main_page=checkout_shipping, IP address: 82.5.203.28
#1 explode() called at [/home/mysite/public_html/includes/functions/functions_general_shared.php:147]
#2 zen_get_prid() called at [/home/mysite/public_html/includes/functions/functions_lookups.php:174]
#3 zen_get_products_stock() called at [/home/mysite/public_html/includes/classes/observers/class.products_with_attributes_stock.php:1869]
#4 products_with_attributes_stock->updateNotifyHeaderStartCheckoutShipping() called at [/home/mysite/public_html/includes/classes/class.base.php:118]
#5 base->notify() called at [/home/mysite/public_html/includes/modules/pages/checkout_shipping/header_php.php:11]
#6 require(/home/mysite/public_html/includes/modules/pages/checkout_shipping/header_php.php) called at [/home/mysite/public_html/index.php:35]
--> PHP Warning: explode() expects parameter 2 to be string, array given in /home/mysite/public_html/includes/functions/functions_general_shared.php on line 147.

> Any suggestions on this issue?

> **mc12345678:**
>
> Reproduced with same setting of limiting stock to what is available (not allowing checkout if stock is out).
> 
> Brief review of the code of the observer indicates that because I've changed to using an array internally for this area of code, that at/before any return from the function should set the products_quantity and the handled flag. Further, because of the early escape reasons for leaving the function and that there is a reason within SBA code to effectively duplicate the return logic from zen_get_products_stock, I will create a separate internal class method that will effectively use the code from the ZC software. Not at all what I really want(ed) to do, but doing this removed(s) the need to modify the core code. Anyways, I expect to have something in a few hours. Have some other things to which to tend. 
> 
> I can say that testing of product with/without variants and attributes was performed it appears with the above configuration set to true. That works, but... does not support all stores and would permit overselling when that is not acceptable/desired...

How about this commit: <https://github.com/mc12345678/Stock_By_Attributes_Combined/commit/a0f94d35d531a77680ded4f26f4432003eba31ca>

I'll have a look at that in a moment and report back .

One other question. In the shopping cart it displays the image assigned to the attribute for the selected variant. Unless I missed it in admin somewhere, I don't see any way to override this as an option. The site where SBA is being used has icons to represent different strengths of a product, so having this display as the product image in cart is not a desirable option in this use case.
If it's not admin switchable, can you point me to the file where this is controlled so I can modify the behaviour? Perhaps add it as a configurable option if not already.

strelitzia:

I'll have a look at that in a moment and report back .

One other question. In the shopping cart it displays the image assigned to the attribute for the selected variant. Unless I missed it in admin somewhere, I don't see any way to override this as an option. The site where SBA is being used has icons to represent different strengths of a product, so having this display as the product image in cart is not a desirable option in this use case.
If it's not admin switchable, can you point me to the file where this is controlled so I can modify the behaviour? Perhaps add it as a configurable option if not already.

General design consideration had been to use/consider attribute swap to replace the main product image with the image for the selected attribute(s). The only control at the moment on the above particular feature was whether to show the image of the product on the shopping cart or not. Seeing as it is desired to show the image on the cart, an alternative "test" is/would be necessary to accomodate.

At the moment the "easiest" fix without touching the database (either adding options onto an existing switch or adding another admin option) would be to comment out one line of code:
In includes/classes/observers/class.products_with_attributes_stock.php line 1796 in the old version or 1833

//        $productArray[$i]['productsImage'] = (IMAGE_SHOPPING_CART_STATUS == 1 ? zen_image(DIR_WS_IMAGES . $productArray[$i]['attributeImage'][count($productArray[$i]['attributeImage']) - 1], $productArray[$i]['productsName'], IMAGE_SHOPPING_CART_WIDTH, IMAGE_SHOPPING_CART_HEIGHT) : '');