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

I've encountered a problem when Dynamic Drop Downs, Product InfoMultiple Attribute Display Plugin is set as 'multiple_dropdowns'.

To rule out compatibility issues with other installed modules I've tested this on a clean installation of Zen Cart 1.5.6c and the latest version of SBA from GitHub, connected to the original site database.

When viewing a product that has two attributes, only the first attribute is shown as two separate drop downs. The label shown in both instances is that of the first attribute.

If I change admin settings to either sequenced_dropdowns or sba_sequenced_dropdowns it correctly displays the two attributes.

Quote:

---

Originally Posted by simon1066

In ZC v1.57a (compared to v1.57) there are changes to

admin/packingslip.php
admin/invoice.php

that make it difficult for me to incorporate the SBA edits - bit of a guessing game. Would it be possible to update the Github code at some point?

---

Recently saw that there were some new additions to ZC in the area of changes made by SBA. Would be nice if can just use the changes mase without anything additional. Will see...

So yes, will need to do something to bring it up-to-date...

Quote:

---

Originally Posted by strelitzia

I've encountered a problem when Dynamic Drop Downs, Product InfoMultiple Attribute Display Plugin is set as 'multiple_dropdowns'.

To rule out compatibility issues with other installed modules I've tested this on a clean installation of Zen Cart 1.5.6c and the latest version of SBA from GitHub, connected to the original site database.

When viewing a product that has two attributes, only the first attribute is shown as two separate drop downs. The label shown in both instances is that of the first attribute.

If I change admin settings to either sequenced_dropdowns or sba_sequenced_dropdowns it correctly displays the two attributes.

---

This issue is caused by errors in includes/classes/pad_multiple_dropdowns.php

Line 108 is only referring to $attributes[0], meaning that it will only ever output the first attribute data of the array.

Change line 108 from

$out.='<tr><td align="right" class="main"><b>'.$attributes[0]['oname'].":</b></td><td class=\"main\">".zen_draw_pull_down_menu('id['.$attributes[0]['oid'].']',array_merge(array(array('id'=>0, 'text'=>'Select '.$attributes[0]['oname'])), $attributes[0]['ovals']),$attributes[0]['default'], "onchange=\"i".$attributes[0]['oid']."(this.form);\"")."</td></tr>\n";


to

$out .= '<tr><td align="right" class="main"><b>' . $attributes[$o]['oname'] . ":</b></td><td class=\"main\">" . zen_draw_pull_down_menu('id[' . $attributes[$o]['oid'] . ']', array_merge(array(array('id' => 0, 'text' => 'Select ' . $attributes[$o]['oname'])), $attributes[$o]['ovals']), $attributes[$o]['default'], "onchange=\"i" . $attributes[$o]['oid'] . "(this.form);\"") . "</td></tr>\n";

This will loop through all the attributes.

I am trying to improve my inventory control and would like to be able to insert a Item Location and MFG Item Number on the SBA item. Does anyone have any idea how I might do this?

Quote:

---

Originally Posted by strelitzia

I've encountered a problem when Dynamic Drop Downs, Product InfoMultiple Attribute Display Plugin is set as 'multiple_dropdowns'.

To rule out compatibility issues with other installed modules I've tested this on a clean installation of Zen Cart 1.5.6c and the latest version of SBA from GitHub, connected to the original site database.

When viewing a product that has two attributes, only the first attribute is shown as two separate drop downs. The label shown in both instances is that of the first attribute.

If I change admin settings to either sequenced_dropdowns or sba_sequenced_dropdowns it correctly displays the two attributes.

---

The software was purposefully setup, directed and is supported to *not* use multiple_dropdowns in all available areas... Specifically, the information about how many options are available for any second selection is lost. Consider the situation where any possible selection is made available for two selection lists. If an item is selected from the second list that causes a choice from the second list to become non-available then the content of the first list needs to be updated or the customer only finds out after attempting to add the product to the cart... In that situation though, now if the customer is willing to use any of the items from the second list but must have that unavailable item from the first list, either an option from the second list must be selected that has an available first option or some sort of "reset" has to be done on the page.... Let me just say that offering software support for that is/would be exhausting.

Quote:

---

Originally Posted by strelitzia

This issue is caused by errors in includes/classes/pad_multiple_dropdowns.php

Line 108 is only referring to $attributes[0], meaning that it will only ever output the first attribute data of the array.

Change line 108 from

$out.='<tr><td align="right" class="main"><b>'.$attributes[0]['oname'].":</b></td><td class=\"main\">".zen_draw_pull_down_menu('id['.$attributes[0]['oid'].']',array_merge(array(array('id'=>0, 'text'=>'Select '.$attributes[0]['oname'])), $attributes[0]['ovals']),$attributes[0]['default'], "onchange=\"i".$attributes[0]['oid']."(this.form);\"")."</td></tr>\n";


to

$out .= '<tr><td align="right" class="main"><b>' . $attributes[$o]['oname'] . ":</b></td><td class=\"main\">" . zen_draw_pull_down_menu('id[' . $attributes[$o]['oid'] . ']', array_merge(array(array('id' => 0, 'text' => 'Select ' . $attributes[$o]['oname'])), $attributes[$o]['ovals']), $attributes[$o]['default'], "onchange=\"i" . $attributes[$o]['oid'] . "(this.form);\"") . "</td></tr>\n";

This will loop through all the attributes.

---

But... What you can see is that the software does support this "minor" change to allow someone to use this option that was determined in development to not receive support... It is not a "bug" but a true design consideration that was made possible to have by some code modification/refactoring, but was specifically left to be processed as provided where mutliple_dropdowns is used when a product has a single attribute (option name) and one of the sequenced dropdowns is used for a product that has multiple attributes (multiple option names). Going the route of using multiple_dropdowns for this situation is considered not supported at this time and features otherwise built into the software are not available to the customer through the existing code...

Quote:

---

Originally Posted by jodean

I am trying to improve my inventory control and would like to be able to insert a Item Location and MFG Item Number on the SBA item. Does anyone have any idea how I might do this?

---

How are you currently using the custom id field if at all?

A similar field could be incorporated/added to the SBA data table(s) to support capturing this additional information. For one the "location" data could be made up of a reference to some other location table that is independently maintained. The MFG Item Number tends to be used/put in the customid field.

From there the question becomes what is needed to be done that needs assistance? Mind you, the details of which may be more appropriate in a separate branch. Here all that I see needed is to be sure that there is a storage location and perhaps some interface for entry and/or display...

Quote:

---

Originally Posted by mc12345678

How are you currently using the custom id field if at all?

A similar field could be incorporated/added to the SBA data table(s) to support capturing this additional information. For one the "location" data could be made up of a reference to some other location table that is independently maintained. The MFG Item Number tends to be used/put in the customid field.

From there the question becomes what is needed to be done that needs assistance? Mind you, the details of which may be more appropriate in a separate branch. Here all that I see needed is to be sure that there is a storage location and perhaps some interface for entry and/or display...

---

Does this work on 1.5.7b?

Quote:

---

Originally Posted by Nick1973

Does this work on 1.5.7b?

---

A little surprised no one else has chimed in on this one yet. :) But, I do have a minor dig and meant in the kindest of ways at least in a way of concern for one's site... What issues have been seen by installing the software onto your BACKUP/TEST version of your site that is version 1.5.7b?

Additionally, it appears that on the previous page, there is a post about version 1.5.7a which if anything is asking for an updated version of the files that are touched to support some of the available features. That post is: https://www.zen-cart.com/showthread....86#post1374386

So, to possibly minimize extra deliberation, understand that the full fileset on github is made of the standard "two parts". There are the files of the program and then there are the things that are Zen Cart version "dependent". In many ways both sets have been updated over time to try to improve the integration. This also means that because a file was used in a previous ZC version does not mean that it is needed in a newer ZC version. For example, the previous includes/modules/YOUR_TEMPLATE/attributes.php file no longer needs to be carried over in a ZC 1.5.7x environment because the version of the file provided in ZC 1.5.7 has enough features in it to not require overriding.

I don't know of anything changed between 1.5.7a and 1.5.7b that would have caused an issue with the software. I've been trying to run all of my test software through the highest available PHP version and with strict operation where possible. So, to what I started with, recommendation is to always have some sort of a backup/development site where you can make mistakes and have zero impact on your live store (other than taking time away from selling)... Sure, ideally there are no mistakes to be had, but one of the best ways to avoid that is through practice and on a system that "can't be bothered". :)

Quote:

---

Originally Posted by mc12345678

A little surprised no one else has chimed in on this one yet. :) But, I do have a minor dig and meant in the kindest of ways at least in a way of concern for one's site... What issues have been seen by installing the software onto your BACKUP/TEST version of your site that is version 1.5.7b?

Additionally, it appears that on the previous page, there is a post about version 1.5.7a which if anything is asking for an updated version of the files that are touched to support some of the available features. That post is: https://www.zen-cart.com/showthread....86#post1374386

So, to possibly minimize extra deliberation, understand that the full fileset on github is made of the standard "two parts". There are the files of the program and then there are the things that are Zen Cart version "dependent". In many ways both sets have been updated over time to try to improve the integration. This also means that because a file was used in a previous ZC version does not mean that it is needed in a newer ZC version. For example, the previous includes/modules/YOUR_TEMPLATE/attributes.php file no longer needs to be carried over in a ZC 1.5.7x environment because the version of the file provided in ZC 1.5.7 has enough features in it to not require overriding.

I don't know of anything changed between 1.5.7a and 1.5.7b that would have caused an issue with the software. I've been trying to run all of my test software through the highest available PHP version and with strict operation where possible. So, to what I started with, recommendation is to always have some sort of a backup/development site where you can make mistakes and have zero impact on your live store (other than taking time away from selling)... Sure, ideally there are no mistakes to be had, but one of the best ways to avoid that is through practice and on a system that "can't be bothered". :)

---

Ok, a straightforward 'Yes' or 'No' would have been sufficient :D

What you are saying more or less says it does work on 1.5.7a, and in turn should work on 1.5.7b. That is all I need to know at this point as I am working on a dev site anyway. :smile:

Quote:

---

Originally Posted by Nick1973

Ok, a straightforward 'Yes' or 'No' would have been sufficient :D

What you are saying more or less says it does work on 1.5.7a, and in turn should work on 1.5.7b. That is all I need to know at this point as I am working on a dev site anyway. :smile:

---

Yes possible, but also seems like something of a self discovery as well... With as little feedback as I get about issues with the software, at times I often wonder if it only works for me. I therefore only encourage the use of it and to provide feedback, because otherwise any self-identified, unannounced issues just die in place to maybe not be discovered. Yes, there are some known issues most of which can be overcome with a little more development and incorporation of other tools.

Now, moving "beyond" ZC 1.5.7b, there *may* be an issue that I have seen as a possibility. I'm about to look into it, but the function zen_not_null will be changing return values in some specific cases. I need to verify that if and where I used that function that it will not cause an unexpected result. See this github discussion at least starting at the following post for further understanding: https://github.com/zencart/zencart/i...ment-751158215

Quote:

---

Originally Posted by mc12345678

Yes possible, but also seems like something of a self discovery as well... With as little feedback as I get about issues with the software, at times I often wonder if it only works for me. I therefore only encourage the use of it and to provide feedback, because otherwise any self-identified, unannounced issues just die in place to maybe not be discovered. Yes, there are some known issues most of which can be overcome with a little more development and incorporation of other tools.

Now, moving "beyond" ZC 1.5.7b, there *may* be an issue that I have seen as a possibility. I'm about to look into it, but the function zen_not_null will be changing return values in some specific cases. I need to verify that if and where I used that function that it will not cause an unexpected result. See this github discussion at least starting at the following post for further understanding: https://github.com/zencart/zencart/i...ment-751158215

---

Yes that is all good with me. I am working on a dev site so it won't be so much of an issue if bugs are found at this point. I will obviously report anything back here.

Quote:

---

Originally Posted by mc12345678

Yes possible, but also seems like something of a self discovery as well... With as little feedback as I get about issues with the software, at times I often wonder if it only works for me. I therefore only encourage the use of it and to provide feedback, because otherwise any self-identified, unannounced issues just die in place to maybe not be discovered. Yes, there are some known issues most of which can be overcome with a little more development and incorporation of other tools.

Now, moving "beyond" ZC 1.5.7b, there *may* be an issue that I have seen as a possibility. I'm about to look into it, but the function zen_not_null will be changing return values in some specific cases. I need to verify that if and where I used that function that it will not cause an unexpected result. See this github discussion at least starting at the following post for further understanding: https://github.com/zencart/zencart/i...ment-751158215

---

Fyi and fwiw, there are cases of the use of zen_not_null that will be affected in the future by the way the function is being changed. Am working through the logic and code to confirm and replace as necessary. My expectation is to update them in a single commit as best as possible.

Quote:

---

Originally Posted by mc12345678

Fyi and fwiw, there are cases of the use of zen_not_null that will be affected in the future by the way the function is being changed. Am working through the logic and code to confirm and replace as necessary. My expectation is to update them in a single commit as best as possible.

---

Um ... I thought we'd resolved that so there's no functional change to the zen_not_null() function, despite PHP8's apparent change.

Quote:

---

Originally Posted by DrByte

Um ... I thought we'd resolved that so there's no functional change to the zen_not_null() function, despite PHP8's apparent change.

---

Unfortunately no, please see the post that was two down in the github path discussed above. The post that provides how it works in upcoming versions is: https://github.com/zencart/zencart/i...ment-751171029

Under the new code (using !== 'NULL' while using PHP <8.0 or at any time PHP 8.x is used) the result of passing an integer value of 0 to zen_not_null is different than how zen_not_null operated in ZC 1.5.7b and below (when using PHP < 8.0).

Personally, while it appears that the function (zen_not_null) was intended to address/respond to text, a null value and the return of database queries, I believe that the code of SBA (written over many years) could use a little updating to move away from using zen_not_null for cases that should be covered by empty or other similar evaluation methods. I say that, if for no other reason than, to ensure that the code is setting, expecting, and handling all of the appropriate data types to minimize any undesirable vectors.

Okay. I'll concede that it's changing: It's changing to what it was always intended to do.

I'll add for clarification: In Zen Cart core code zen_not_null is/was never used for assessing integers specifically.
(I can't speak for how/whether addons have used it in that way.)
Testing the truthy-ness of an integer is better done with empty().

Starting from v1.5.8 zen_not_null is only used where empty() would not be appropriate: prices, search, dates.

I've tried installing SBA on 1.5.7b and I am getting a blank admin page when going to Catalog > Attributes Controller

This is in the logs:

[11-Jan-2021 17:17:06 Europe/London] Request URI: /~MYWEBSITE/zcadmin/index.php?cmd=attributes_controller&products_filter=1&current_category_id=5, IP address: 86.17.120.117
#1 trigger_error() called at [/home/MYWEBSITE/public_html/includes/classes/db/mysql/query_factory.php:170]
#2 queryFactory->show_error() called at [/home/MYWEBSITE/public_html/includes/classes/db/mysql/query_factory.php:142]
#3 queryFactory->set_error() called at [/home/MYWEBSITE/public_html/includes/classes/db/mysql/query_factory.php:269]
#4 queryFactory->Execute() called at [/home/MYWEBSITE/public_html/zcadmin/attributes_controller.php:762]
#5 require(/home/MYWEBSITE/public_html/zcadmin/attributes_controller.php) called at [/home/MYWEBSITE/public_html/zcadmin/index.php:11]
--> PHP Fatal error: 1146:Table 'MYDB_zenca28.zengp_products_with_attributes_stock' doesn't exist :: select distinct products_id FROM zengp_products_with_attributes_stock where products_id = 1
==> (as called by) /home/MYWEBSITE/public_html/zcadmin/attributes_controller.php on line 762

So zengp_products_with_attributes_stock table is missing. Is there an SQL file somewhere that needs processing? It isn't clear as there aren' any installation instructions that I can see.

Quote:

---

Originally Posted by Nick1973

I've tried installing SBA on 1.5.7b and I am getting a blank admin page when going to Catalog > Attributes Controller

This is in the logs:

[11-Jan-2021 17:17:06 Europe/London] Request URI: /~MYWEBSITE/zcadmin/index.php?cmd=attributes_controller&products_filter=1&current_category_id=5, IP address: 86.17.120.117
#1 trigger_error() called at [/home/MYWEBSITE/public_html/includes/classes/db/mysql/query_factory.php:170]
#2 queryFactory->show_error() called at [/home/MYWEBSITE/public_html/includes/classes/db/mysql/query_factory.php:142]
#3 queryFactory->set_error() called at [/home/MYWEBSITE/public_html/includes/classes/db/mysql/query_factory.php:269]
#4 queryFactory->Execute() called at [/home/MYWEBSITE/public_html/zcadmin/attributes_controller.php:762]
#5 require(/home/MYWEBSITE/public_html/zcadmin/attributes_controller.php) called at [/home/MYWEBSITE/public_html/zcadmin/index.php:11]
--> PHP Fatal error: 1146:Table 'MYDB_zenca28.zengp_products_with_attributes_stock' doesn't exist :: select distinct products_id FROM zengp_products_with_attributes_stock where products_id = 1
==> (as called by) /home/MYWEBSITE/public_html/zcadmin/attributes_controller.php on line 762

So zengp_products_with_attributes_stock table is missing. Is there an SQL file somewhere that needs processing? It isn't clear as there aren' any installation instructions that I can see.

---

In earlier design, I had a request to be able to install the software but not to activate it until one wanted to activate it. That said, it appears that the attributes_controller aspect does not currently support that.

Regardless, while it is true that there is not a set of instructions currently associated with the install (reason it is not updated in the ZC plugins area), generally speaking the installation instructions are still the same as potteryhouse issued years ago...

Effectively, to complete the installation (after file upload), go to admin/stock_by_attr_install.php and that will initiate the installation and/or support installing the software to include this missing database table (along with others that are installed).

I have updated the 1.5.6 and 1.5.7 versions of the attributes_controller to basically "skip" that logic if the table is not defined or if the table is not in the database... I also updated the file for those two versions to incorporate whatever code is currently out there to bring that file up-to-date.

Note that my plan (at some point) is actually to remove the code that is in the file and have its output incorporated into the display by way of javascript or jQuery unless another notifier gets introduced that will better support what is needed in these two places... Use of javascript/jQuery will introduce its own issues and concerns with support, but will at least eliminate the file modification.

In updating the file for this, I also realized that I had set aside some text response in this area to be adjusted based on the product being tracked by SBA or not. I had merged a few statements because they generally had the same complexity, but were expected to output something different. So this is addressed/corrected in this area of code: https://github.com/mc12345678/Stock_....php#L770-L775

It only affected ZC 1.5.7 as 1.5.6 and before had it spread out more and was a little "messier"..

Anyways, updates have been pushed to the master branch:
https://github.com/mc12345678/Stock_By_Attributes_Combined

Quote:

---

Originally Posted by mc12345678

I have updated the 1.5.6 and 1.5.7 versions of the attributes_controller to basically "skip" that logic if the table is not defined or if the table is not in the database... I also updated the file for those two versions to incorporate whatever code is currently out there to bring that file up-to-date.

Note that my plan (at some point) is actually to remove the code that is in the file and have its output incorporated into the display by way of javascript or jQuery unless another notifier gets introduced that will better support what is needed in these two places... Use of javascript/jQuery will introduce its own issues and concerns with support, but will at least eliminate the file modification.

In updating the file for this, I also realized that I had set aside some text response in this area to be adjusted based on the product being tracked by SBA or not. I had merged a few statements because they generally had the same complexity, but were expected to output something different. So this is addressed/corrected in this area of code: https://github.com/mc12345678/Stock_....php#L770-L775

It only affected ZC 1.5.7 as 1.5.6 and before had it spread out more and was a little "messier"..

Anyways, updates have been pushed to the master branch:
https://github.com/mc12345678/Stock_By_Attributes_Combined

---

Ok, well going to admin/stock_by_attr_install.php seemed to work and it appears to have installed.

On GitHub it says it only goes up to 1.5.6 and you have 1.5.7 files in the installation. Perhaps you need to update what it says on GitHub as well?

Quote:

---

Originally Posted by Nick1973

Ok, well going to admin/stock_by_attr_install.php seemed to work and it appears to have installed.

On GitHub it says it only goes up to 1.5.6 and you have 1.5.7 files in the installation. Perhaps you need to update what it says on GitHub as well?

---

In review to answer your question I noticed the same.

When I went back into my local git repository I saw that I had that prepped but hadn't loaded it.

The repository is updated; however, I still want to indicate that as of right now with the revision forthcoming to Zen Cart 1.5.7 (1.5.7c) and/or the use of PHP 8.x that this plugin will not operate correctly until its use of zen_not_null is modified. In some cases more evaluation is needed in a code segment, in other cases a completely different evaluation should be used such as !empty, isset or similar.

I am going through the code where zen_not_null has been used and making modifications, with all to be pushed as a single commit instead of by piecemeal. This is a result of my incorrect usage of that function and that the function is being further modified to provide the result(s) that had been expected for its use. In the discussion had, it was not intended to be a replacement for functions such as is_null, empty, isset, === false, etc... It has a somewhat more narrow use, primarily appearing to be for the evaluation of query data.

Will identify when that update is complete.

Quote:

---

Originally Posted by mc12345678

In review to answer your question I noticed the same.

When I went back into my local git repository I saw that I had that prepped but hadn't loaded it.

The repository is updated; however, I still want to indicate that as of right now with the revision forthcoming to Zen Cart 1.5.7 (1.5.7c) and/or the use of PHP 8.x that this plugin will not operate correctly until its use of zen_not_null is modified. In some cases more evaluation is needed in a code segment, in other cases a completely different evaluation should be used such as !empty, isset or similar.

I am going through the code where zen_not_null has been used and making modifications, with all to be pushed as a single commit instead of by piecemeal. This is a result of my incorrect usage of that function and that the function is being further modified to provide the result(s) that had been expected for its use. In the discussion had, it was not intended to be a replacement for functions such as is_null, empty, isset, === false, etc... It has a somewhat more narrow use, primarily appearing to be for the evaluation of query data.

Will identify when that update is complete.

---

Among other general code updates for either internal code readability and alignment, I've updated the code as associated to the use of the Zen Cart function zen_not_null. As discussed here and a few other places in the forum as well as on github for Zen Cart, 1) I incorrectly incorporated the use of that function to (ab)use its results in a way that worked for the code. I have updated the code to generally only use the Zen Cart function in cases where text type results are expected ($_GET/$_POST if used or processing fields from a database query before the field has been "sanitized"), to evaluate query results or in some cases where an SBA function provides mixed results (though the results are: null, false, an array or a query result). The function continues to identify the following as "null": false, empty array, null, effectively no results from a query, a text result that is not empty spaces/no content, or if the value is the all capital text word 'NULL'.

In the case of an evaluated value has reasonable expectation to be set as the string word 'NULL', I believe I have incorporated appropriate checks to support/allow that value (thinking the customid for example). If I have missed such a "check", please let me know what field was desired to be set as 'NULL', at what location it was attempted to be added and during what operation that seemed to "disappear".

I also finally discovered where/how when a cart was expected to indicate that it contained a product that was out-of-stock had the potential to continue through checkout. Basically found by accident, but upon further review of the problem code area, it's "obvious"...

A while ago, I had modified the approach to indicating that a cart had out-of-stock product. Having seen other plugins introduce their own "text" or result, I didn't want SBA to clobber that information, so I tried to go a sort of reverse route by *trying* (and failing) to only make the SBA product appear out-of-stock if it was not already marked as such. What I had instead was to unmark the cart as containing out-of-stock product if all product were in stock, but was missing a forceful action of: if the cart was not marked to have out-of-stock product and it should identify that it has out-of-stock product, then tag the cart as having out-of-stock product.

For the zen_not_null revisions (supporting the currently "unreleased" Zen Cart 1.5.7c and beyond), please see commit: https://github.com/mc12345678/Stock_...3c8d7112dbc6b2

For the out-of-stock correction, please see commit: https://github.com/mc12345678/Stock_...4fccbfa5b963ca

To take advantage of several code changes and improvements on the internal operation of the plugin, please consider installing the latest files as found at:
https://github.com/mc12345678/Stock_...butes_Combined

There still is a little more work to be done to fully support PHP 8.0 as I had incorporated a code operation that is being removed in that version. Effectively I was looking back at code operation and information passed to collect data instead of reconstructing information or internally collecting the information by bypassing the code inspection and just passing the needed data along. This code problem is in the catalog side observer class for evaluating the quantity of product available. A solution is in mind; however, has not been fully implemented/tested yet.

I also have received some feedback to reduce code modification in at least one of the files touched by the module, specifically either by incorporating the Zen Cart 1.5.7c admin/attributes_controller.php file into a previous Zen Cart 1.5.7 version or in use of 1.5.7c specifically, admin/attributes_controller.php will not need any touching. This would reduce the number of admin touched files from 4 to 3 with overrides used in the catalog side to support display/use of the customid (if not using that feature, then currently the only files really touched are the templates/tpl_modules_attributes.php file to support cascade attribute selection (really could be done with javascript/jQuery but hasn't been implemented) and templates/tpl_modules_main_product_image.php to support image swap which also probably could be performed without that modification).

Quote:

---

Originally Posted by mc12345678

There still is a little more work to be done to fully support PHP 8.0 as I had incorporated a code operation that is being removed in that version. Effectively I was looking back at code operation and information passed to collect data instead of reconstructing information or internally collecting the information by bypassing the code inspection and just passing the needed data along. This code problem is in the catalog side observer class for evaluating the quantity of product available. A solution is in mind; however, has not been fully implemented/tested yet.

I also have received some feedback to reduce code modification in at least one of the files touched by the module, specifically either by incorporating the Zen Cart 1.5.7c admin/attributes_controller.php file into a previous Zen Cart 1.5.7 version or in use of 1.5.7c specifically, admin/attributes_controller.php will not need any touching. This would reduce the number of admin touched files from 4 to 3 with overrides used in the catalog side to support display/use of the customid (if not using that feature, then currently the only files really touched are the templates/tpl_modules_attributes.php file to support cascade attribute selection (really could be done with javascript/jQuery but hasn't been implemented) and templates/tpl_modules_main_product_image.php to support image swap which also probably could be performed without that modification).

---

Come to find out that the issue is/was not so directly PHP 8.0 nor that the changes were going to prevent the use of the code as written, it was that there has been a change to generally prevent the use of the feature taken advantage of unless something additional was implemented.

Basically, PHP 7.4 and PHP 8.0+ were both to be impacted without some additional code. I have incorporated some additional operations to permit the continued use of the code as is until either a refactor to centralize some code or to incorporate additional operations to sort it all out. Anyways, I pushed the change to the master branch, but the specific change that supports continued use in default installations of PHP 7.4+ is:
Address default php.ini setting for php 7.4+ · mc12345678/Stock_By_Attributes_Combined@9884e3d (github.com)

As discussed in: Alternative method needed for PHP 8 as will remove argument evaluation/modification · Issue #95 · mc12345678/Stock_By_Attributes_Combined (github.com)

Quote:

---

Originally Posted by mc12345678

Come to find out that the issue is/was not so directly PHP 8.0 nor that the changes were going to prevent the use of the code as written, it was that there has been a change to generally prevent the use of the feature taken advantage of unless something additional was implemented.

Basically, PHP 7.4 and PHP 8.0+ were both to be impacted without some additional code. I have incorporated some additional operations to permit the continued use of the code as is until either a refactor to centralize some code or to incorporate additional operations to sort it all out. Anyways, I pushed the change to the master branch, but the specific change that supports continued use in default installations of PHP 7.4+ is:
Address default php.ini setting for php 7.4+ · mc12345678/Stock_By_Attributes_Combined@9884e3d (github.com)

As discussed in: Alternative method needed for PHP 8 as will remove argument evaluation/modification · Issue #95 · mc12345678/Stock_By_Attributes_Combined (github.com)

---

Seems like there's probably a better way to detect arguments, perhaps by passing more information via the core code's notifier call?

Quote:

---

Originally Posted by DrByte

Seems like there's probably a better way to detect arguments, perhaps by passing more information via the core code's notifier call?

---

The core's notifier as far as I have been able to tell doesn't pick up any extra parameters sent to the function that activated the notifier...

For example:

Code:

---

  function zen_get_products_stock($products_id) {
    global $db;
   
    // -----
    // Give an observer the chance to modify this function's return value.
    //
    $products_quantity = 0;
    $quantity_handled = false;
    $GLOBALS['zco_notifier']->notify(
        'ZEN_GET_PRODUCTS_STOCK',
        $products_id,
        $products_quantity,
        $quantity_handled
    );
    if ($quantity_handled) {
        return $products_quantity;
    }

---

If it is called as such:
$returned_value = zen_get_products_stock($products_id, $attributes);

Then there is nothing it seems within the notifier that is able to pull back the second parameter that was sent to the function..

The notifier provides the class (which is the base class at this point), the notifier designation itself, the read only most likely already hashed $products_id; however, that hashed value could have been formed by any number of things and ways and there really are only a few things needed by the plugin to support evaluation.

Of course, and as I indicated in the issue, if I merge information from the base SBA class with the observer class or provide some sort of interface, then it seems that the only time that the additional data is necessary is from the extra_cart_actions and if/when called from within the base SBA class. This is because there are no other edits to core code, there doesn't appear to be any other times at which that additional information is passed though it could be of use elsewhere.

The other perspective I had (a long time ago anyways) was to take the known/present attributes from either the cart or the orders, run that through the "typical" hash routine and then if/where those matched the provided $products_id, I would have a match of sorts, even if what I had to do was to take that known information and present it in different sequences so that I could get the information to hash with equivalence... At any rate, when working towards trying to remove/eliminate other modifications, this was what fell out of that development to be able to consider further potential use regardless of a call from cart or order...

If there is something in the above that I'm missing, I'm all ears. Currently, the consideration is to be able to determine, using an observer of 'ZEN_GET_PRODUCTS_STOCK', what additional parameters were sent to it and what their value(s) are and repeat the same type evaluation from 'ZEN_CHECK_STOCK_MESSAGE'.

I'm assuming that SBA is passing the extra $attributes parameter? But if the function doesn't declare that parameter in its function signature, the function won't do anything with it (hence I guess why you're trying to do backflips to read it?).
And newer PHP versions will soon begin actively rejecting the function call if it doesn't match the signature.

Perhaps there's an opportunity to improve core code.

Quote:

---

Originally Posted by DrByte

I'm assuming that SBA is passing the extra $attributes parameter? But if the function doesn't declare that parameter in its function signature, the function won't do anything with it (hence I guess why you're trying to do backflips to read it?).
And newer PHP versions will soon begin actively rejecting the function call if it doesn't match the signature.

Perhaps there's an opportunity to improve core code.

---

By no means shying away from the opportunity to improve core code, I haven't found anything that suggests that the following will become a problem. Perhaps I don't have all of the tea leaves though:

Code:

---

function thisFunction($param1) {
    // Evaluate parameters provided, if there are extra parameters, then do something with them.
    //    This evaluation and additional action could be before, after or during the normal action on $param1.
    // Do something with $param1
}

$data = 'Data';
$extra_parameter = 'use also';
thisFunction($data, $extra_parameter);

---

Where even if some sort of data type is forced for $param1 that if the original/expected data type is provided then it seems from my review of php requirements that the call to the function will still be accepted. What I have seen is issues that could occur based on some of the php 8 chosen directions and more specifically on the use or potential use of optional values within the original function (if not accounted for properly downstream), Variable Arguments or possibly use of Named Arguments. My thought though in this particular code section is that the use/operation is so "limited" that changes made to the parameters of the functions would be relatively easy to see/address with the code being changed/updated as necessary to interface properly with the core code.

That all said, the follow on question to address potential core code is where such modification may be best considered... The function as a class method, additional data collected/passed in the function call, the observer class making more information available about the code surrounding the notifier (parameters of the call to the outer function?)?

In part it seems that a lot of the data possibly to be sent could be captured within the associated orders/cart classes. My issue is/was that I wanted to have the exact information that is being attempted to be used not what was at some point determined. In other words potentially the current data from the associated object, or in the case of wanting to "test" the ability to take an action the value(s) being tested... At the same time I wanted to try to use as much of the default/core code as possible rather than generating alternative code. This would appear to make it easier to make changes that apply across the board rather than having to possibly make the same change in multiple places. Further, where might be a good place to further capture this discussion? I'm aware that changes made will likely impact many.

As for use of the hashed attribute information, pretty much all is well and good when looking at possibly generating/regenerating the possible hash value from the known attribute(s) assigned to a product except when text/a file is involved... The hash is specifically modified by the content of the associated text so it is not feasible to "guess" the hash from the possible attributes when either of those two attribute types are present. The only thing that could be done at that point is to capture/borrow the associated text from the applicable order/cart object and relate it to the associated file/text so that the potential hash values could be generated by sequencing/resequencing them in a mash up to see if the provided/identified hash is feasible within the variants assigned within SBA...

Anyways, although I saw this a good number of hours ago, I wanted to at least provide my feedback on what looks like a "scare" to upcoming coding standards... I'm thinking in my limited view that in relation to the function signature that there may have been a little extra concern than what currently is described as proposed...


I got a lot of the above from: https://www.php.net/manual/en/functions.arguments.php

Another direction that I somewhat had forgotten about for this module was to in essence "stuff" the $products_id when used specifically by the module to include whatever data is needed. Obviously then it could be managed by the module and information needed be sent back as "processed". It appears that in the cases where core code makes calls that might be of interest that the data structure appears to be in the use of the orders class which appears to also be in the global space and also consistently uses $i as the increment variable... A lot of "just right" constraints that "happen" to work out...

Course it involves recoding of some aspects but I think that it would eliminate this additional "look back" process that was thrown together to span both types of calls with potential to work across all uses. I just need to find the infrequently used function that torvista added to the attributes controller I think it was where an array is created with elements that have the same name as the variable being used... Like said though, open to making core mods if there is some concept to implement. If it means anything I've been trying for too long to find alternative attribute data models but the idea of a good one seems to be a coveted or complex concept.

Complex indeed.
And ultimately shouldn't be only applicable to attributes.

I have the latest SWA from Github on 1.5.7b, and am having a problem with search. Entering the product model no. into the search box brings the product into the search list box, but doesn't display it on the page. Clicking search on the product, which is now in the search list box, brings it up on the page for editing, but gives this error.

PHP Fatal error: Uncaught Error: Class 'language' not found in /admin/includes/classes/products_with_attributes_stock.php:267

function displayFilteredRows($SearchBoxOnly = null, $NumberRecordsShown = null, $ReturnedProductID = null) {
global $db, $sniffer, $languages;
if (empty($languages)) {
267 $languages = new language();
}
Can anyone help with this?

Quote:

---

Originally Posted by cefyn

I have the latest SWA from Github on 1.5.7b, and am having a problem with search. Entering the product model no. into the search box brings the product into the search list box, but doesn't display it on the page. Clicking search on the product, which is now in the search list box, brings it up on the page for editing, but gives this error.

PHP Fatal error: Uncaught Error: Class 'language' not found in /admin/includes/classes/products_with_attributes_stock.php:267

function displayFilteredRows($SearchBoxOnly = null, $NumberRecordsShown = null, $ReturnedProductID = null) {
global $db, $sniffer, $languages;
if (empty($languages)) {
267 $languages = new language();
}
Can anyone help with this?

---

Didn't have this issue at times in the past with some version of ZC 1.5.7, but I agree that there is the above issue. Pushing the commit change in a moment. Don't like the solution or perhaps it is the fact that such a solution has to be generated, but it does take in consideration of the history of Zen Cart unfortunately...

Quote:

---

Originally Posted by cefyn

I have the latest SWA from Github on 1.5.7b, and am having a problem with search. Entering the product model no. into the search box brings the product into the search list box, but doesn't display it on the page. Clicking search on the product, which is now in the search list box, brings it up on the page for editing, but gives this error.

PHP Fatal error: Uncaught Error: Class 'language' not found in /admin/includes/classes/products_with_attributes_stock.php:267

function displayFilteredRows($SearchBoxOnly = null, $NumberRecordsShown = null, $ReturnedProductID = null) {
global $db, $sniffer, $languages;
if (empty($languages)) {
267 $languages = new language();
}
Can anyone help with this?

---

Quote:

---

Originally Posted by mc12345678

Didn't have this issue at times in the past with some version of ZC 1.5.7, but I agree that there is the above issue. Pushing the commit change in a moment. Don't like the solution or perhaps it is the fact that such a solution has to be generated, but it does take in consideration of the history of Zen Cart unfortunately...

---

Fix that has worked for me is by applying the changes identified in the following: Address missing language class in ZC 1.5.7b · mc12345678/Stock_By_Attributes_Combined@a41d979 (github.com)

Quote:

---

Originally Posted by mc12345678

Fix that has worked for me is by applying the changes identified in the following: Address missing language class in ZC 1.5.7b · mc12345678/Stock_By_Attributes_Combined@a41d979 (github.com)

---

Added some additional code for those that have taken extra action to clean up their store files. After applying the above, also apply: Prevent trying non-existent file · mc12345678/Stock_By_Attributes_Combined@890bc16 (github.com) or just use the master branch files...

Thanks for your reply, and for all your work on ZenCart.
The search works with the first edit, but gives the error
--> PHP Warning: Illegal string offset 'id' in /admin/includes/classes/products_with_attributes_stock.php on line 503.
The search works with both edits, but gives the error
--> PHP Warning: Illegal string offset 'id' in /admin/includes/classes/products_with_attributes_stock.php on line 506.

Using the `zen_get_languages` function in your last edit fixed it. Great that the solution didn't add weight either.

What does one do if they run 1.5.7? Is there an update that addresses the depreciated files such as admin/includes/classes/order.php?

Quote:

---

Originally Posted by TheGrimReaper

What does one do if they run 1.5.7? Is there an update that addresses the depreciated files such as admin/includes/classes/order.php?

---

The version loaded to github includes all of the files that are needed to support 1.5.7 (as far as they have been reworked). Meaning, when looking at the overall process to upgrade, the recommendation is/has been to rebuild the site, incorporate changes that were made and bring on updated plugins (in no particular sequence).

The core files of SBA remain core to whatever version of Zen Cart is being used. Then the sub-directory for the ZC version includes files that are specific for operation in that version and in attempt to provide the expected output for operation.

For ZC 1.5.7, there are four admin files that are "touched" (though really the attributes_controller.php file is just the ZC 1.5.7"c" release of the file and there are no modifications to the file away from that version). There are 3 catalog side files specific to ZC 1.5.7 and those are only for template type information. Most of the modifications made in any/all of these files is to support the display of the customid...

That said, the only template file that *really* does something is found in the "core" files (because these files remain unchanged in ZC even up to this point) of: includes/templates/YOUR_TEMPLATE/templates/tpl_modules_attributes.php. This file is what provides the sequenced dropdowns. In truth if more were put into the output of the results in a javascript/jQuery way, then this file would not even need to be touched/modified and I think may be true about the main product image file.

FYI, there is no longer a need to override includes/modules/attributes.php if using the ZC 1.5.7 version of that file.

Anyways, depending on where you are at with your store, one way to go about things is to remove/restore the files found in your version's modifications that are not found in the 1.5.7 version's fileset. Why? because when using the more recent ZC fileset *and* the recent github fileset, less needs to be incorporated/touched... It just folds together...

Thanks for the edits and additional codes!

Quote:

---

Originally Posted by DeonEva

Thanks for the edits and additional codes!

---

Welcome

:)

. Please identify issues and/or improvements with the software if/when they occur (preferably at least after a little research has been done :) ).

I'm missing something in installing SBA in zc 157c. I've added all the files and run stock_by_attr_install.php in admin, but I don't see the usual admin menu item under Catalog. Are there detailed installation instructions available somewhere?
TIA,
Dave

Quote:

---

Originally Posted by Dave224

I'm missing something in installing SBA in zc 157c. I've added all the files and run stock_by_attr_install.php in admin, but I don't see the usual admin menu item under Catalog. Are there detailed installation instructions available somewhere?
TIA,
Dave

---

After accessing the stock_by_attr_install.php file, need to run the install (if haven't) within that. Note, above there has been some reporting of installation issues. I haven't been able to reproduce them and there is a sort of "test" plan described at this post. Initial report was that perhaps the browser used has/had something to do with it, but I haven't heard back about the testing that should more reliably identify some level of commonality.

There are a lot of other possible ways to track down the issue if it can reliably be reproduced. I'm also going to try to see what I can discover, but I basically did that testing on a new site but didn't experience the described issues...

Quote:

---

Originally Posted by mc12345678

After accessing the stock_by_attr_install.php file, need to run the install (if haven't) within that. Note, above there has been some reporting of installation issues. I haven't been able to reproduce them and there is a sort of "test" plan described at this post. Initial report was that perhaps the browser used has/had something to do with it, but I haven't heard back about the testing that should more reliably identify some level of commonality.

There are a lot of other possible ways to track down the issue if it can reliably be reproduced. I'm also going to try to see what I can discover, but I basically did that testing on a new site but didn't experience the described issues...

---

Yeah, I ran the install/update script before posting my question. I'm glad I didn't miss anything obvious. I'll keep digging and perhaps try your tests but I hate to start all over again with a fresh zc install.

Thank you for all that you do for us!

Dave

Quote:

---

Originally Posted by Dave224

Yeah, I ran the install/update script before posting my question. I'm glad I didn't miss anything obvious. I'll keep digging and perhaps try your tests but I hate to start all over again with a fresh zc install.

Thank you for all that you do for us!

Dave

---

Did you try running it a second time? That's really what the above testing is/was about in my opinion. Another thought is had you logged out and then logged back in (refreshing session information) to see if the data became available?

In that testing I used the "fresh" install perspective because of the information provided in the two previous posts that had indicated the problem. Seemed for them that running the install twice took care of the issue. They were set on it being a browser issue to which I disagree. The testing is all about identifying which situation is true. If there's a "need" to run it twice, then I need to figure out what operation is not reaching the database at the right time with the right information the first time around. Now that I think about it, I wouldn't be surprised if there is some database caching issue where a select query is run one time before an install step and then again after the install step and the same data is returned which is that the action taken didn't happen.
‎
Ok, I may have found the issue considering I only found one recent code change that may have caused installation not to complete. I would have expected some sort of message to be provided about it (in the list of content on the install page), but not sure that gets reviewed for what was done/not done...

I've uploaded a patch that I think corrects the installation issue: Correct installation · mc12345678/Stock_By_Attributes_Combined@45d01a9 (github.com)

This change appears to be the only change that may have had an effect on operation and may be the reason that a portion of the installation did not finish. Still would be nice to know basically what the last output line was on the install screen.

I found one problem with my install...I had missed installing a few new files. Got that fixed. Ran install again. I now have the SBA menu item in admin under catalog. But I get a fatal error of unknown column popt.products_options_track_stock when looking at product info page for SBA product.

I put debug statements in stock_by_attr_install.php and discovered that $action=null when first starting the install process, which brings up the info screen and script selection box which was expected. But when selecting a script and clicking run script, nothing happens except a return to admin home. No $action variable is set, leading me to believe the installer script(s) were not run.

There is nothing SBA-related displayed at the bottom of the install page or admin home page. I ran installer twice, same result. I installed SBA all over again with the patch (March 18 version). Same results.

I'm using Firefox on Mac. Tried Chrome on Mac...same results.

Dave

zc157c, SBA 1.5.4 (March 18 GITHUB version), php 7.3.21

Quote:

---

Originally Posted by Dave224

I found one problem with my install...I had missed installing a few new files. Got that fixed. Ran install again. I now have the SBA menu item in admin under catalog. But I get a fatal error of unknown column popt.products_options_track_stock when looking at product info page for SBA product.

I put debug statements in stock_by_attr_install.php and discovered that $action=null when first starting the install process, which brings up the info screen and script selection box which was expected. But when selecting a script and clicking run script, nothing happens except a return to admin home. No $action variable is set, leading me to believe the installer script(s) were not run.

There is nothing SBA-related displayed at the bottom of the install page or admin home page. I ran installer twice, same result. I installed SBA all over again with the patch (March 18 version). Same results.

I'm using Firefox on Mac. Tried Chrome on Mac...same results.

Dave

zc157c, SBA 1.5.4 (March 18 GITHUB version), php 7.3.21

---

So as far as the fileset on github, that field 'products_options_track_stock' is only in three files and really is not used by the code at least from a settings perspective. The three files are:
admin/stock_by_attr_install.php
includes/classes/pad_base.php
includes/classes/pad_sba_sequenced_dropdowns.php

So yes, if the database install is not successful, then accessing a catalog side product information page of a product tracked by SBA will begin to generate issues. There is no catalog side "detection" to prevent this. There shouldn't really be, because if the admin installation is successful, then the information expected on the catalog side will be there for use.

As to the issue with information following the "action", the dropdown is within a form that uses $_GET to provide information. Therefore selecting an item from the dropdown list and pressing Run Script, assigns the selected item to the URI parameter selectSBAinstall, so it and then '$action' will be set to whatever was selected.

I can not seem to reproduce the problem described above with the patch applied.

Performed test 1 as you recommended in the referenced post. Same results as before. There is no output from the install script. All that happens is the admin home page comes up after clicking "run script". No change on second run of script. No difference when running the check files script. The SBA menu item is not placed in the admin/catalog menu.

I installed a clean (unmodified) zc version 1.5.7c, installing the test data. I loaded all the SBA files in the March 18 version from Github that were in the admin and includes folders and the files in the 1.5.7 folder. The YOUR TEMPLATE files were placed in the template_default folder and the classic green template selected. I did not install the Dutch or French language files. No merging of the five files that were different from the base zc files was done; the SBA files were written over the 1.5.7c files.

I logged in to admin and added stock_by_attr_istall.php to the url and hit return. The help/select script page comes up as expected (Stock By Attribute (SBA) installation script SBA Version 1.5.4 for Zen Cart Version 1.5.7c). I selected the Full/Upgrade DB install script and clicked run script.

The url in the browser admin home page url window following running the script was my_domain/admin/index.php?cmd=home&selectSBAinstall=installAll&getSBAinstallPage=Run+Script if that helps.

I'm running with Mac OS 10.15.7 (Catalina) with Firefox (86.0.1) on a local development MAMP Pro 6.0.1 server running php 7.3.21, Apache 2.4.46, and MySql 5.7.30.

Hope this helps. What configuration are you using that won't reproduce the problem?

Dave

I think there may be something wrong with the github distribution. Admin/includes contains folders and files that are or should be in the store-side includes folder. There are files in admin that are not shown in the list of new admin files or new core files shown in the install help page for zc 157c.
Dave

Quote:

---

Originally Posted by Dave224

I think there may be something wrong with the github distribution. Admin/includes contains folders and files that are or should be in the store-side includes folder. There are files in admin that are not shown in the list of new admin files or new core files shown in the install help page for zc 157c.
Dave

---

Please provide specifics. Github location, files that are perceived to be incorrectly placed. What led to this conclusion.

The following files are included in the SBA zc157c distribution but not listed on the SBA install help page:
admin/includes/auto_loaders/config.eo_sba.php
admin/includes/auto_loaders/config.products_with_attributes_stock.php
admin/includes/auto_loaders/config.zc154_compatibility.php
admin/includes/classes/observers/class.products_with_attributes_stock.php
admin/functions/extra_functions/products_with_attributes_stock.php
admin/includes/functions/extra_functions/reg_ddsba.php
admin/includes/init_includes/init_eo_sba.php
admin/includes/init_includes/init_sba_copy_to_confirm_messagestack.php
admin/includes/init_includes/init_sba_copy_to_confirm/php
admin/includes/init_includes/init_zc154_compatibility.php
admin/includes/languages/english/edit_orders_sba.php
admin/includes/languages/english/extra_definiotions/reg_ddsba.php
admin/includes/languages/english/images/buttons/button_sba_link.gif
admin/includes/languages/english/modules/product_sba.php
includes/classes/class.products_with_attributes_class_stock.php
includes/classes/observers/auto.advanced_search_categories_custom_id.php
includes/classes/pad_base.php
includes/classes/pad_multiple_dropdowns.php
includes/classes/pad_sba_sequenced_dropdowns.php
includes/classes/pad_sba_single_dropdown.php
includes/classes/pad_sequenced_dropdowns.php
includes/classes/pad_single_dropdown.php
includes/classes/pad_single_radioset.php
includes/extra_configures/pwas_non_stock.php
includes/extra_datafiles/dynamicdropdownfor sba.php
includes/languages/english/extra_definitions/dynamic_dropdowns_sba.php
includes/templates/YOUR_TEMPLATE/templates/tpl_modules_attributes.php
includes/templates/YOUR_TEMPLATE/templates/tpl_main_product_image.php

The following files are shown on the install help page as changed or updated core files but are not included in the zc 1.5.7c SBA distribution (Are they listed for other zc versions?):
admin/options_name_manager.php
admin/options_values_manager.php
admin/includes/functions/general.php
admin/includes/classes/order.php
includes/classes/order.php
includes/functions/functions_lookups.php
includes/functions/extra_functions/products_with_attributes.php
includes/modules/pages/checkout_shipping/header_php.php
includes/modules/pages/shopping_cart/header_php.php

The following override files are listed in the SBA install help page but not included in the SBA zc157c distribution:
includes/modules/YOUR_TEMPLATE/attributes.php

The distribution is Stock_By_Attributes_Combined-master.zip located at https://github.com/mc12345678/Stock_...ads/master.zip with date of March 18, 2021. Files used are in the admin, includes and 1_5_7 folders.

My intention is to try and get to the bottom of my SBA install difficulties. My thought was that there may be extra or missing files in the distribution that are messing up the install after studying the install help page. I realize I'm grasping at straws.

Dave

Quote:

---

Originally Posted by Dave224

The following files are included in the SBA zc157c distribution but not listed on the SBA install help page:
admin/includes/auto_loaders/config.eo_sba.php
admin/includes/auto_loaders/config.products_with_attributes_stock.php
admin/includes/auto_loaders/config.zc154_compatibility.php
admin/includes/classes/observers/class.products_with_attributes_stock.php
admin/functions/extra_functions/products_with_attributes_stock.php
admin/includes/functions/extra_functions/reg_ddsba.php
admin/includes/init_includes/init_eo_sba.php
admin/includes/init_includes/init_sba_copy_to_confirm_messagestack.php
admin/includes/init_includes/init_sba_copy_to_confirm/php
admin/includes/init_includes/init_zc154_compatibility.php
admin/includes/languages/english/edit_orders_sba.php
admin/includes/languages/english/extra_definiotions/reg_ddsba.php
admin/includes/languages/english/images/buttons/button_sba_link.gif
admin/includes/languages/english/modules/product_sba.php
includes/classes/class.products_with_attributes_class_stock.php
includes/classes/observers/auto.advanced_search_categories_custom_id.php
includes/classes/pad_base.php
includes/classes/pad_multiple_dropdowns.php
includes/classes/pad_sba_sequenced_dropdowns.php
includes/classes/pad_sba_single_dropdown.php
includes/classes/pad_sequenced_dropdowns.php
includes/classes/pad_single_dropdown.php
includes/classes/pad_single_radioset.php
includes/extra_configures/pwas_non_stock.php
includes/extra_datafiles/dynamicdropdownfor sba.php
includes/languages/english/extra_definitions/dynamic_dropdowns_sba.php
includes/templates/YOUR_TEMPLATE/templates/tpl_modules_attributes.php
includes/templates/YOUR_TEMPLATE/templates/tpl_main_product_image.php

The following files are shown on the install help page as changed or updated core files but are not included in the zc 1.5.7c SBA distribution (Are they listed for other zc versions?):
admin/options_name_manager.php
admin/options_values_manager.php
admin/includes/functions/general.php
admin/includes/classes/order.php
includes/classes/order.php
includes/functions/functions_lookups.php
includes/functions/extra_functions/products_with_attributes.php
includes/modules/pages/checkout_shipping/header_php.php
includes/modules/pages/shopping_cart/header_php.php

The following override files are listed in the SBA install help page but not included in the SBA zc157c distribution:
includes/modules/YOUR_TEMPLATE/attributes.php

The distribution is Stock_By_Attributes_Combined-master.zip located at https://github.com/mc12345678/Stock_...ads/master.zip with date of March 18, 2021. Files used are in the admin, includes and 1_5_7 folders.

My intention is to try and get to the bottom of my SBA install difficulties. My thought was that there may be extra or missing files in the distribution that are messing up the install after studying the install help page. I realize I'm grasping at straws.

Dave

---

So, the incomplete list of files on the install screen... that definitely isn't a factor of the problem with the install. That's a problem with updating the list of files in that area to match the reality of the code as cross referenced with the ZC version in use (assuming that the reported version actually matches the fileset as distributed for that version, etc...).

I do know this. In ZC 1.5.7, the admin side of ZC changed to using a "cmd" parameter to represent the page that is being used/accessed. I don't currently have the background of why it was implemented, what problems it resolved, etc... but it has become a part of the core code.

There are a few pieces throughout that exist to support it and keep it working the way intended. One of which that helps is for things like installations to actually happen basically through natural navigation of the admin. Either through the modules->plugins manager, or by being logged in and accessing say a configuration menu...

Well, the way SBA was written for installation, was to not cause any changes to the store *until* the install was accessed. When the install is accessed, the configuration menu is supposed to be generated. Sort of, not here until you see it situation. Yes, there are files associated with that part of the installation process which is why anywhere I have discussed installation has been to load all of the files in the includes and admin folders to their respective location (a few are template related because they have been the same for all associated ZC versions and have not (yet) deserved being somewhere separate/copied multiple times). Then, where a specific ZC version is considered, to use the files only from that version (some have thought they had to "build" up to the current version of something). In some cases, because of improvements to the ZC core code, less has needed to be modified about that code to support the features offered.

So, anyways, one of the "factors" of the new cmd parameter, is a sort of chicken/egg condition of the parameter already being in the browser uri and being set to the current page... I actually maybe describing that slightly incorrect as it is a bit of a brain twister of what needs to be set to what, before/after this/that in order for operation to continue as likely expected/desired.

If I may suggest, if the configuration option exists for SBA after any of these tests that one navigate to it from somewhere in the store and then attempt the install script. I need to disable a few things on my test store that might be preventing this problem to see if I have to add/incorporate some work around for ZC 1.5.7. I had previously reported an issue with zen_draw_form when using a 'get' type form, though don't recall if it was resolved or remains open. It was reported in github and offered a sort of work around but its something that should at some point be corrected.

I will say this though too. Not all files that are included with the plugin are "mandated" for operation. Some offer an improved convenience of the drop down restrictions, but the central aspect of the software works just fine without it or with some variation. There is at least one file that is listed/present that really is only there because it is now an empty file where previous versions had the file there...

I still need to look into/at operation or the various ways that this issue could be generated to either provide approriate guidance to support the install process or to modify the install script to prevent the problem even if it is to apply a work around.

I think I'll go away for a while to give you time to find the solution. I'm afraid I don't understand everything you posted, but please let me know if you need more information from me.

Thank you for all you do for zen cart!

Dave

I don't want to muddy the waters but, I believe this may be part of the problem.

The distro from github contains a folder called 1_5_7.

The first file is an exact match for the current 1.5.7c

The second file has portions that have been updated by DrByte SINCE the release date of the file. So if you blindly overrite that file, you will lose the changes in line 184 of the current 1.5.7c file.

The third file is the same situation as the second BUT the more recent changes on lines 15/16, 157, 162, 200, 424, 450, 1120-1122, 1252-1254, 1265-1268, 1277, and 1288 will be missed because the github version is dated

Code:

---

* @version $Id: DrByte 2020 Jun 08 Modified in v1.5.7 $

---

while the 1.5.7c version is dated

Code:

---

* @version $Id: mc12345678 2021 Feb 22 Modified in v1.5.7c $

---

:dontgetit

The fourth file is basically the same situation as the third except the update this time was done by DrByte. The shipped file is dated

Code:

---

* @version $Id: DrByte 2020 Oct 05 Modified in v1.5.7 $

---

While the current 1.5.7c version is dated

Code:

---

* @version $Id: DrByte 2020 Oct 28 Modified in v1.5.7a $

---

You also need to carefully merge the admin/orders.php file if you have any mod installed that used that file.

Hopefully, that knowledge will help in the process.

I have not yet fully tested my installation (empty database) but, I will be testing it this week and will report back what I find.

Quote:

---

Originally Posted by Dave224

I think I'll go away for a while to give you time to find the solution. I'm afraid I don't understand everything you posted, but please let me know if you need more information from me.

Thank you for all you do for zen cart!

Dave

---

Fixed through a commit that incorporates the "work around" I described. It's a pain, but it works. Oddly too, for some reason, this time I was able to reproduce the issue before implementing the fix at this commit. It is already now a part of the master branch.

Assign the installer to the cmd parameter for ZC 1.5.7 on · mc12345678/Stock_By_Attributes_Combined@ee541d7 (github.com)

For those that have been landing back at the "main screen" when clicking the Run Script button in ZC 1.5.7, this is expected to resolve that issue that has *finally* been reproduced and resolved with the changes at the above link.

Quote:

---

Originally Posted by mc12345678

Fixed through a commit that incorporates the "work around" I described. It's a pain, but it works. Oddly too, for some reason, this time I was able to reproduce the issue before implementing the fix at this commit. It is already now a part of the master branch.

Assign the installer to the cmd parameter for ZC 1.5.7 on · mc12345678/Stock_By_Attributes_Combined@ee541d7 (github.com)

For those that have been landing back at the "main screen" when clicking the Run Script button in ZC 1.5.7, this is expected to resolve that issue that has *finally* been reproduced and resolved with the changes at the above link.

---

For what it's worth, this "issue" was identified in GitHub at issue 3922.

Yes, a correction would be to use a post type form instead of get. I will have to look at the impact of doing so because there are some "benefits" of having action possible through uri parameters.

I ask that those that have "taken advantage" of using the browser path information to "readily" access installation options to please post something about it either here or on GitHub: https://github.com/mc12345678/Stock_...ombined/issues.

In this way I can try to sustain an appropriate level of "compatibility".

Thank you, thank you, thank you! I finally got the installer to actually echo info back to me! Coffee on the way.
Dave

Quote:

---

Originally Posted by dbltoe

getting foreach() warning for line 1696 of /includes/classes/observers/class.products_with_attributes_stock.php

---

Line 1690 should follow what the text above it says by changing:

Code:

---

if (empty($order->products[$i]) && empty($order->products[$i]['attributes'])) return;

---

to:

Code:

---

if (empty($order->products[$i]) || empty($order->products[$i]['attributes'])) return;

---

I think I tried to do some sort of refactoring and missed a step. (An alternate solution would be to not the entire first evaluation, but I think the proposed solution here is more readable.)

entered in error

Would that be the same fix for line 1180 of /includes/classes/class.products_with_attributes_class_stock.php?

Code:

---

    if (!empty($attribute_list) && is_array($attribute_list)) {

---

Also, in the same file, getting

Code:

---

[13-Apr-2021 12:27:06 US/Central] Request URI: /index.php?main_page=product_info&cPath=18_94&products_id=394&action=add_product, IP address: ***.***.***.***
#1 trigger_error() called at [/includes/classes/class.products_with_attributes_class_stock.php:1148]
#2 products_with_attributes_class_stock->zen_get_sba_attribute_info() called at [/includes/extra_cart_actions/stock_by_attributes.php:721]
#3 include(/includes/extra_cart_actions/stock_by_attributes.php) called at [/includes/main_cart_actions.php:26]
#4 require(/includes/main_cart_actions.php) called at [/includes/init_includes/init_cart_handler.php:44]
#5 require_once(/includes/init_includes/init_cart_handler.php) called at [/includes/autoload_func.php:37]
#6 require(/includes/autoload_func.php) called at [/includes/application_top.php:222]
#7 require(/includes/application_top.php) called at [/index.php:25]
--> PHP Warning: SBA product can not have any attributes in /includes/classes/class.products_with_attributes_class_stock.php on line 1148.

---

Product 394 has no attributes and is not listed on the SBA page.

Quote:

---

Originally Posted by dbltoe

Would that be the same fix for line 1180 of /includes/classes/class.products_with_attributes_class_stock.php?

Code:

---

    if (!empty($attribute_list) && is_array($attribute_list)) {

---

Also, in the same file, getting

Code:

---

[13-Apr-2021 12:27:06 US/Central] Request URI: /index.php?main_page=product_info&cPath=18_94&products_id=394&action=add_product, IP address: ***.***.***.***
#1 trigger_error() called at [/includes/classes/class.products_with_attributes_class_stock.php:1148]
#2 products_with_attributes_class_stock->zen_get_sba_attribute_info() called at [/includes/extra_cart_actions/stock_by_attributes.php:721]
#3 include(/includes/extra_cart_actions/stock_by_attributes.php) called at [/includes/main_cart_actions.php:26]
#4 require(/includes/main_cart_actions.php) called at [/includes/init_includes/init_cart_handler.php:44]
#5 require_once(/includes/init_includes/init_cart_handler.php) called at [/includes/autoload_func.php:37]
#6 require(/includes/autoload_func.php) called at [/includes/application_top.php:222]
#7 require(/includes/application_top.php) called at [/index.php:25]
--> PHP Warning: SBA product can not have any attributes in /includes/classes/class.products_with_attributes_class_stock.php on line 1148.

---

Product 394 has no attributes and is not listed on the SBA page.

---

The only way that this line of code is reached (which specifically generates an error log because there is some sort of data issue) is if the product is determined to be tracked by SBA (as a result of its product id existing in TABLE_PRODUCTS_WITH_ATTRIBUTES_STOCK) or, since the tracking mechanism is held as a session variable, that during the session the product changed from an attribute product in the SBA table to one that no longer is and overall that product doesn't have attributes captured in the combination of the products_options and products_attributes tables.

As to 1180, no that would not be the same fix of changing and (&&) to or (||) because an error *would* occur in the follow on operation if either is false. $compArray is already defined as an array(), if $attribute_list doesn't become a non-empty array, then the steps in the below foreach loop do not need to execute. Execution is prevented by $compArray being pre-defined as an empty array and *not* taking on a non-array type value. That it remains an empty array is fine because then the contents of the foreach are not executed. If the two evaluations are OR'd, then if/when $attribute_list is provided with a non-array/non-iterable type variable, the foreach would absolutely fail. This is considered acceptable programatically as well because $specAttribute is pre-defined as an empty array with the same concept in mind.

So, what issue(s) are considered to be stemming from this logic area of line 1180 in includes/classes/class.products_with_attributes_class_stock.php?

Is the problem described something that is reproducible on demand through normal operation or does it require some level of page modification? I ask because I seem to recall making a suggestion for a shopping cart modification though I thought I had incorporated it into the extra cart actions as well already...

Okay, I guess there was more assuming going on on my part. The product mentioned in the warning is not listed as having any attributes BUT, it is in the table you mentioned. Turns out the owner was recycling ids rather than create new ones if the information was correct.
For instance an item is available in red, green, and blue. It is entered correctly and stock is tracked until the green and blue are no longer available and won't be. They just changed the description to red and deleted the items from the Attributes Controller.
Knowing that one of their employees may do the same again, should they delete from SBA first in order to have it drop from the table? Obviously simply dropping the attributes from the controller does not affect the table.
THANX

Quote:

---

Originally Posted by dbltoe

Okay, I guess there was more assuming going on on my part. The product mentioned in the warning is not listed as having any attributes BUT, it is in the table you mentioned. Turns out the owner was recycling ids rather than create new ones if the information was correct.
For instance an item is available in red, green, and blue. It is entered correctly and stock is tracked until the green and blue are no longer available and won't be. They just changed the description to red and deleted the items from the Attributes Controller.
Knowing that one of their employees may do the same again, should they delete from SBA first in order to have it drop from the table? Obviously simply dropping the attributes from the controller does not affect the table.
THANX

---

Well, there are three observers that were designed to be associated with deletion from the attributes controller. One is when all attributes are deleted, one is when an attribute is deleted and one when deleting an option name value. The expectation of activating any of those is to delete the record(s) within the SBA table associated with that action. There are delete operations for some of the other areas in the site. It would be more helpful to fully understand where such action was taken to be able to identify what is not working correctly or what other "avenue" has been generated. Additionally, it would be further helpful to know what Zen Cart version is in question. I intend to focus on 1.5.7 at the moment, but hopefully it is understood that there is some complexity involved. As to a "sound" way forwards, yeah, it would be better to delete the item(s) from the SBA table before deleting them from the attributes controller, but as far as "naming" of attributes, SBA doesn't care what the name of the attribute is but the record information associated with it... More to follow as this gets researched based on the information thus far provided... Would be nice to know if that SBA table contained *all* historical records of attributes for the product or just a single "final" one or something in between...

This was an upgrade from 1.5.5f(upgraded all the way from 1.2.7) to 1.5.7c. I do not know at what point SBA was originally added. Each product ID had more than one entry in the products_with_attributes_stock table. It is a warning and does NOT stop the shopper from purchasing the item.

We will just create a MySQL template to run in the admin each time one of these warnings comes up.

THANX for pointing me in the right direction.

Quote:

---

Originally Posted by dbltoe

This was an upgrade from 1.5.5f(upgraded all the way from 1.2.7) to 1.5.7c. I do not know at what point SBA was originally added. Each product ID had more than one entry in the products_with_attributes_stock table. It is a warning and does NOT stop the shopper from purchasing the item.

We will just create a MySQL template to run in the admin each time one of these warnings comes up.

THANX for pointing me in the right direction.

---

At that point in processing, the "limit" would be expected to be the number of product available as defined in the product information page, if the site was set to not allow "overselling". Because the product would not have any limiting defined attributes and it is permitted to be sold without attributes (basis of the product), then the prevention factor should become how the store handles the total quantity of product.

I'll also look at providing some sort of information in the admin screen for product found in the SBA table that are not otherwise expected to be displayed (effectively products_id in the SBA table where that product does not have attributes).

The logged message was coded in as a warning (instead of an error) because of the above expected path to completion and the possibility of that situation. Basically, there is information in a portion of the database (SBA table) that shouldn't be there which is made "noticeable" because there is not an excess check on the catalog side for "accuracy" of the admin controlled data. E.g., there isn't a check against the products_attributes table while a customer is navigating to see that the potential attributes tracked by SBA no longer exist on the product... If/When properly/sufficiently managed on the admin, that discrepancy should not exist. Unfortunately, at the moment there isn't a ready tool to identify the condition identified (product "had" attributes, but no longer does and in managing the attributes the downstream data was not sufficiently updated.)

Now, there is a check of attributes "fed" to SBA to see how they relate to the tracked product and is generally expected to reject options that do not exist (there is the potential for exceptions) or where stock is not permitted to be drawn (attribute selections result in negative stock where negative stock is not permitted). Again, a lot of caveats available/possible.

That code section may be a good place to incorporate a notifier to permit some other operation to be performed instead of just generating a log. Again, note that should not just simply delete the product from that table when coming across that log generating area, again because the "tracking" of a product being associated with SBA is currently tied to the session of the visitor with limited points at which that gets regenerated. Looking to revise this aspect, but need to be sure to capture the information needed in the cases where pages change.

Can combinations of attributes be set up in SBA to track inventory but exclude other attributes? For example, I want to track inventory for each combination of shirt color and size, but not include another attribute which affects price, such as number of words printed on the shirt, since the words are printed after the sale.

I tried this on a sample product ignoring (not entering) the third attribute while setting up custom ids and inventory. But, although I can select the the first attribute while purchasing, the second and third attribute can not be selected. I'm using dynamic dropdowns. When I deleted the third attribute, everything worked with the two dropdowns.

If SBA can handle this case, how do I do it?

Thanks,

Dave

Quote:

---

Originally Posted by Dave224

Can combinations of attributes be set up in SBA to track inventory but exclude other attributes? For example, I want to track inventory for each combination of shirt color and size, but not include another attribute which affects price, such as number of words printed on the shirt, since the words are printed after the sale.

I tried this on a sample product ignoring (not entering) the third attribute while setting up custom ids and inventory. But, although I can select the the first attribute while purchasing, the second and third attribute can not be selected. I'm using dynamic dropdowns. When I deleted the third attribute, everything worked with the two dropdowns.

If SBA can handle this case, how do I do it?

Thanks,

Dave

---

Yes, it is though at this time it is more via Install SQL Patches or phpMyAdmin than anything.

So there are some "hints" in the instructions in the configuration screen:

Quote:

---

• To support the newly added non-stock table entry, follow the following guidance:
• A single product's value can be considered non-stock by entering the products_id as the source_id, the options_values_id as the type_id and the type as PV.
• A single product's options can be considered non-stock by entering the products_id as the source_id, the options_id as the type_id and the type as PO.
• A single option value (potentially applicable to all product) can be considered non-stock by entering 0 as the source_id, the options_values_id as the type_id and the type as AV.
• A single option (potentially applicable to all product) can be considered non-stock by entering 0 as the source_id, the options_id as the type_id and the type as AO.
• The expectation (upon software completion) is that an option_value will only be defined by only one of the above rules such that once all option values for an option name has been populated, then the option name itself will be defined and the individual records removed.

---

What does this mean? Well, there is a lengthy discussion of the "feature" that I again found by searching this forum on "gift wrap" which is along the lines of what this feature is considered. The ability to have something associated with the product that is not related to tracking the stock of the product.. The above "fields" are those that are in the table 'products_with_attributes_stock_attributes_non_stock'. The file 'includes\extra_configures\pwas_non_stock.php' contains CONSTANTS' and their associated definition which is expected to match to the database value(s).

I found that post #2811 contained a link back to where discussion centers on the feature asked about above. Obviously I suggest also looking around that post and the referenced post(s) as there may be further discussion around them that could offer some help.

Basically would need to identify how you plan on that particular attribute working throughout any Stock By Attributes relationship. In the case of text, yes it may be that you don't want to track the option name (option) for this one product, but may want to for another product... If it is for the one product, then would be considering the PO option above, if it is ever and always that it is desired to *NEVER* have it be related to stock then would consider the AO option. But remember if you pick a larger grouping, when it becomes desirable to then allow that specific characteristic either have to create a new attribute, find a way to exclude that product from the grouping or some other solution. Best to plan for your possibilities, understand the limitations, try to identify ways for things to be better and then implement whatever is needed.

I don't yet have a "visualization" of those options in the admin. I'm in the midst of some updates right now for the ZC 1.5.7 specific files which results in suggesting only two ZC 1.5.7 files need editing to support the full complement of features. Those two are admin/packingslip.php and includes/templates/YOUR_TEMP/templates/tpl_shopping_cart_default.php

Yes there are two files in the core includes directory that still need/could use modification, both are located in includes/templates/YOUR_TEMPLATE/templates and they are tpl_modules_attributes.php (which is edited primarily for dynamic dropdowns as they are not yet implemented as javascript/jQuery type objects) and tpl_modules_main_product_image.php to help enforce that the newly added id parameter though that might be possible through an observer when displaying the image... Likely will look into that so do not have to modify that template file either...

As to dynamic dropdowns, last I knew it works with this non-stock feature. I haven't tested it in a while but I would expect the above linked post(s) to provide information about it.

Just pushed a really big set of changes to github, though refrained from putting it on the master branch... For now...
It seems to be working for me in the many different testings that I've done, but, there are even many more differences out there...

So, biggest changes? (Possibly not yet incorporated into the admin installer "directions"), There are now only basically 3 files that get modified/overridden. They are:
1) includes/templates/YOUR_TEMPLATE/templates/tpl_shopping_cart_default.php
2) includes/templates/YOUR_TEMPLATE/templates/tpl_modules_attributes.php
and
3) admin/packingslip.php

Reasoning for each:
1) To support display of additional information offered by SBA to include the total quantity of a variant that exists, if stock is low, etc... Also includes modification to support display of customid information
2) Fully support the current rendition of Dynamic Dropdowns. There are other "tools" that could provide the display that this offers. More work needs to be done for either.
3) This incorporates a notifier that was added many years ago in support of a sort of picture display/swap plugin that was requested to be made compatible with SBA. The solution was to make SBA more compatible with that. As a result, this notifier has been retained.

What that also means though, is that if all of the current software is taken to a site, then the changes that were introduced into other template files and admin files from "previous" versions would need to be removed... NOTE the CHANGES need to be removed, NOT THE FILES (generally speaking)... These changes for the most part apply all the way back to ZC 1.5.1 (first tracked version for this plugin). I have attempted to remove the file(s) as appropriate from the distribution. That said, if you leave the changes in the template/admin files and navigate to an SBA product, then if the new method applies to your older version you will see that customid/model information twice...

I've kept the commit history of my changes. In some cases there was a progression from one style to another, in others I just make the full change at once. I have also gone and refactored a lot of the code to make reading it a little easier and to remove a lot of the if() { if() { if() { if() { if() {}}}}} type statements and similar things with loops where early exits are provided instead of large groupings of if statements that otherwise result in just moving to the next record.

I also transitioned many of the loops from for loops to foreach loops, in this way an interim item could be removed from the list and operation could continue without giving some sort of logged feedback that the item was missing or needing excess code to check for the presence/absence of the item.

I also addressed the issue that dbltoe brought up where now at the bottom of the screen there is a separate "listing" if product are identified in the product_with_attributes_stock table that currently do not have attributes assigned. The display appears similar to the current display when attributes are assigned. Could say it is still a work in progress, but basically if that problem does not exist, then the bottom of the screen from the viewer's perspective looks the same as it did. There is/will be a little extra html code, but....

Added an ignore statement associated with deleting product attributes to prevent operation from stopping/creating a mydebug file. I hadn't seen one, but the logic tells me that the ignore statement was needed.

Updated some of the catalog side observers to operate similar to their admin counterpart which has/had an effect on customid aspects.

Added observer files for customid display as well as image swap operation (this observer allowed removal of edits to the main_products_images file(s)). On image swap operation, I haven't tested the javascript/jQuery response when navigating to product not tracked by SBA where the attribute selection type is the newly added SBA simple select (dropdown).

One thing I did was to convert to using an array when requesting response from zen_get_products_stock or zen_check_stock where the array is made of the products_id and the attributes of the product. This information makes processing of the information easier than trying to possibly sort through the cart or an order, especially where processing of an order could change the attributes associated with the product. At any rate, this is to also replace a previous method that was used and is becoming more difficult to use as PHP versions go on. For the time being both methods remain available (sending as an array or overloading those two functions with the attributes information).

To see these new "features" can go to: mc12345678/Stock_By_Attributes_Combined at next-update (github.com)
or to see the differences to the current master: Comparing master...next-update · mc12345678/Stock_By_Attributes_Combined (github.com)

Haven't really looked forwards to some of the changes made here, because again, there has been code introduced to files since initial usage that no longer are considered necessary because I have found somewhere "convenient" to insert the value(s) sought... Doesn't mean it works great with *YOUR* store, but it is somewhere that works in a default store.

I'm having trouble adding attribute combinations for a product. Everything was fine adding attribute combinations until I tried to add the 61st item for an item. There are two attributes: color and size for one product: tee shirts. When I submit the 61st item from the attribute selection, description, custom id and quantity input page, the green success message appears at the top of the page but the new item is not displayed on the product attribute list page and is not recorded in table products_with_attributes_stock. The highest stock_id for that table is 150. Have I hit a limit somewhere?
Dave
PHP 7.3, zc 157c, SBA version dated Mar 22, 2021 and downloaded from GIT

Quote:

---

Originally Posted by Dave224

I'm having trouble adding attribute combinations for a product. Everything was fine adding attribute combinations until I tried to add the 61st item for an item. There are two attributes: color and size for one product: tee shirts. When I submit the 61st item from the attribute selection, description, custom id and quantity input page, the green success message appears at the top of the page but the new item is not displayed on the product attribute list page and is not recorded in table products_with_attributes_stock. The highest stock_id for that table is 150. Have I hit a limit somewhere?DavePHP 7.3, zc 157c, SBA version dated Mar 22, 2021 and downloaded from GIT

---

There is no programmed "maximum" number of variants that would limit the resulting number of variants. This could be "proven" by removing a variant and then attempting to add this "problem" variant. If still not successful, then its not the 61 variant issue, but instead a problem with the combination of the attributes. That said, the next thing is to try to identify the cause(s) of 1) the variant not being added, but a report of success...I haven't seen such a report in a possible long time. I thought I may have come across it several years ago, but...So, heres the things that would help to know about in no particular order:Attributes associated with the product as shown in the attributes controller, what option name types are associated (check box, dropdown, etc..)While I see that you are familiar with looking over the database, are equally familiar with reviewing the source page code of a web page? If so, please identify the value(s) for the dropdown option selections for these attributes that are being combined and any other dropdown selection values that would be expected to be submitted as part of generating this variant.Does this store support more than one language? (I don't know of a current issue with that, but have had to previously make some changes to support it.)Unfortunately also need to ask about the "history" of the store... is it an upgraded store (database is the item of interest/concern), from what if so, etc...I think from there, might have additional questions about the information that gets submitted, but a next consideration is identifying which of the processing paths are taken to reach the attempt to submit the variant, the data that is being fed to that insert method and then to chase down the processing of the data within that class method.Ultimately the "test" that is indicating a successful addition has multiple potential ways to support identifying success, so the condition(s) that are being met for that would be helpful but not by itself. Meaning, need to know some upstream info to likely be able to resolve this discrepancy. I'm all for solving it as it shouldn't be happening.

mc12345678,
Here are some answers to your questions:
(1) Attributes associated with the product as shown in the attributes controller: color and size
(2) Option name types: both are radio buttons
(3) Values for the dropdown option selections for those attributes that are being combined: Ash, "Good for the Next 100 years!" and S (for small)
(4) Any other dropdown selection values that would be expected to be submitted as part of generating the variant: none if you mean other attributes for the variant that fails. Values for other variants include M,L,XL,2XL,3XL for size, and 11 other colors/descriptive info for color.
(5) More than one language: no, only english
(6) History of the store: fresh install of zc157c with SBA, Edit Orders, ZXPOS (purchased), ZCA Bootstrap Template (but not currently using), Better Together and other purchased SW Guy discount addons, and other custom tailoring. Database was copied over from v155f and updated via the zc v157c installer. Of note is that the SBA-related tables have a mix of products with and without a Unique Combo value. The product I am having trouble with has Unique Combo values for each variant.
(7) Processing path taken to reach the attempt: The success message displayed when adding the variant fails is "Product successfully updated" (PWA_UPDATE_SUCCESS). This is generated in only one place: in admin/products_with_attributes_stock.php. The browser URL (or URI?) is index.php?cmd=products_with_attributes_stock&action=add&products_id=706&search_o rder_by=p.products_model. The products_id is correct and I was trying to add a variant.
(8) Data fed to insert method: examining $saveResult when $messageStack is set to PWA_UPDATE_SUCCESS looks correct. sql_query is 'UPDATE products_with_attributes_stock set `quantity` = 10, `customid = 'ASH_GOOD_S', `title` = 'POS: Ash, Good..., S', `barcode` = null WHERE `products_id` = 706 AND `stock_attributes` = '163755,163806". Note that `barcode` is added as part of the ZXPOS add-on.
(9) Conditions that are being met to generate the success message: I developed a debug function that emails values of variables/expressions. See attachment.

Hope this helps,
Dave

Attachment 19578

Very useful information, thank you. While each answer didn't necessarily provide the sought information, the other information filled in many of the gaps.

Ok, so a couple of things I see... The query: 'UPDATE products_with_attributes_stock set `quantity` = 10, `customid = 'ASH_GOOD_S', `title` = 'POS: Ash, Good..., S', `barcode` = null WHERE `products_id` = 706 AND `stock_attributes` = '163755,163806"
has a mistake in it, though I don't know if that was manually typed or copy/pasted. After `customid there should be another backquote (on US keyboard the key in the upper left corner in combination with the tilde (~).)

As far as uniqueness, based on what I'm seeing in admin/includes/classes/products_with_attributes_stock.php at/around line 716:

Code:

---

      $query = "SELECT count(*) AS total FROM " . TABLE_PRODUCTS_WITH_ATTRIBUTES_STOCK . " WHERE (products_id = :products_id: AND stock_attributes = :stock_attributes:) " . (isset($productAttributeCombo) ? "OR product_attribute_combo = :product_attribute_combo: " : "") . (isset($customid) /* @TODO if customid is not required to be unique then and with a false */ ? "OR customid = :customid:" : "");

---

It appears that a duplicate/existing record is being found based on this query or the query as modified to support `barcode`.
The goal of this query is to use the provided information that determines if a lookup identifies a duplicate entry in the pwas table. Based on what happens next, it seems that there is a duplicate found. If the query is unmodified to support the additional field, then it would seem that the customid is non-unique. This is first based on the fact that it seems that the combination of products_id and stock_attributes being entered does not exist (report of variant not being in the list nor in the database) and that just before this call, the product_attribute_combo is generated to equal the combination of those two fields which since that original combination doesn't exist I wouldn't expect this one to exist either. Therefore, the only remaining "duplicate" is the customid of 'ASH_GOOD_S'. Please confirm that customid already exists in the database for any product. If it does not, please identify how this query is otherwise different than originally provided.

Then, if the customid actually is the duplicate record, then it would seem that the next "duplicate" searching query has not been updated to further reflect the comparison criteria or I have a problem with the evaluation that immediately follows. The words/concepts "seem" right, but the results don't seem to match. The query I'm speaking to is:

Code:

---

"SELECT count(*) as total FROM "  . TABLE_PRODUCTS_WITH_ATTRIBUTES_STOCK . " WHERE ((products_id = :products_id: AND stock_attributes = :stock_attributes:) " . (isset($productAttributeCombo) ? "OR product_attribute_combo = :product_attribute_combo: " : "") . ") AND `customid` != :customid:";
                  // If find a record, then the customid was assigned to some other product or the two parts of the where

---

As the logic is this: have already found that the earlier query identified one or more records searched on an 'or' basis. Because we are talking about whether the customid is unique or not, it could be that the customid is already assigned to this one product or it could have been used in multiple places... If it is already assigned to this one product, then it is fine that the customid "already" exists because the customid identifies to this product... But, if the customid is used elsewhere, then attempting to apply the customid to this record would mean that at least a duplicate exists, could be used more times than one. So... This query is expected to identify if the combination for this variant exists where the variant is not assigned to the current customid (with the customid not being empty)...

There may be an incorrect action after this for not finding a match, but I think at this point it would be good to get the results from above first... I know that I had made changes to the "duplicate" customid inspection some time ago with the possibility of not requiring a unique customid for all variants.

There was a typo in the query.

The customid was used in another product. Changing the customid allowed the variant to be added. Thank you!!!

But I'm confused about what you said about the 2nd query. Is there something wrong with it? Seems to me that a failure or warning message should come up in this case. Is the integration with the barcode code faulty?

Dave
PS: I don't know why the attachment can't be opened.

Quote:

---

Originally Posted by Dave224

There was a typo in the query.

The customid was used in another product. Changing the customid allowed the variant to be added. Thank you!!!

But I'm confused about what you said about the 2nd query. Is there something wrong with it? Seems to me that a failure or warning message should come up in this case. Is the integration with the barcode code faulty?

Dave
PS: I don't know why the attachment can't be opened.

---

A little backstory without too much detail. A previous method of identifying a duplicate customid upon submitting a record was not liked by more recent versions of MySQL and therefore had to be revised/rewritten. That was not done to full completion and thinking back I thought that I had removed the need for the customid to be unique from processing.

So, what about the above second query? It is written with the intent to identify the existence of the variant to not have the customid. The problem (as now completely identified) is that if the variant does not exist without the customid (count == 0) then it seems that there is not enough information yet gathered/evaluated to clearly communicate what needs to be done nor to take the expected action. What is known at that point is:
a customid is present for evaluation
the variant or the customid exists in the database, then
the customid exists in the database (the number of which is in the results), then
That variant might have the customid or another variant might have the customid (requesting additional information in the previous query would likely help or elminating the != portion of the query and just returning the customid(s) and processing them to see if the customid is in that grouping).

More evaluation is needed to identify the relationship between the customid and the remaining data. I think it was here that I stopped development. So yes, more information assistance would be appropriate.

Some things that I was trying to further address/consider were, what is the current status of the database: are duplicates allowed or not. If not allowed, then how bad is the current state and "where/when" should that be corrected? The change in allowance would be (at some point if not already present) through an admin configuration switch... Should transition of that switch kick off a process to evaluate and address duplicates? Probably best at that point. Simultaneously another admin may be in the process of adding/editing product or without that "auto process" duplicates should be seen/prevented when/where possible upon insertion.

Was also trying in one or more ways to minimize the queries to the database to evaluate the condition based on the possibility/existence of previous information. I was also trying to be sure that I could allow the level of questioning to be editable for other fields/logic.

I can say that at this very moment I'm a little flustered at identifying a best path forwards because I had some concerns that I was trying to address the importance of which I need to re-evaluate and I would say that obviously have not fully addressed customid duplication... Right now to see the new variant in the list of variants, the customid has to be unique, but the user doesn't get told that a duplication has occurred and I would say that the duplicate condition hasn't really been identified. Its just that an error doesn't occur in attempting to move forwards...

This aspect hasn't recently been an area of focus and likely others have either worked around it in some way outside of the github code... I know I had good intentions, but that portion is not there yet.

Thank you for your active support of SBA! It would have taken me weeks to understand the processing to the point where I could have figured out that a duplicate customid was causing the problem. I appreciate all your efforts on zen cart and I'm sure others do too!
Dave

I've encountered an undefined offset notice on lines 528, 529, and 530 of includes/extra_cart_actions/stock_by_attributes.php. Examining the code, the while loop is executed one more time than necessary with the result of an undefined offset and with three $_POST variables set to null on the last pass. The latter result is necessary (good) to prevent subsequent processing from increasing the quantity of the product. I changed the while test from <= to < on line 527, which eliminates the extra pass and undefined index, and unset the three $_POST variables following line 912 after the while loop to accomplish the result of the extra pass. While unset eliminates the three $_POST variables rather than setting them to null, it seems to work okay for my products, but I wondered if you had any thoughts about the change considering the variety of cases the code is designed for? Should I set the $_POST variables to null instead of unsetting them?
TIA,
Dave
zc157c, SBA 5.1.4 (March 22, 2021), php 7.3

Quote:

---

Originally Posted by Dave224

I've encountered an undefined offset notice on lines 528, 529, and 530 of includes/extra_cart_actions/stock_by_attributes.php. Examining the code, the while loop is executed one more time than necessary with the result of an undefined offset and with three $_POST variables set to null on the last pass. The latter result is necessary (good) to prevent subsequent processing from increasing the quantity of the product. I changed the while test from <= to < on line 527, which eliminates the extra pass and undefined index, and unset the three $_POST variables following line 912 after the while loop to accomplish the result of the extra pass. While unset eliminates the three $_POST variables rather than setting them to null, it seems to work okay for my products, but I wondered if you had any thoughts about the change considering the variety of cases the code is designed for? Should I set the $_POST variables to null instead of unsetting them?
TIA,
Dave
zc157c, SBA 5.1.4 (March 22, 2021), php 7.3

---

Difficult to just say "sure"! I will say that it is open source and can be worked/reworked as necessary. Certainly would be helpful to understand the setup that is causing this situation. I thought I had tried all sorts of arrangements, I do know that there were some "options" originally considered that haven't been flushed out of that particular file. Those options are not active in the code in a base install and require someone making modifications to the file. But I haven't a clue if they are a part of this discussion or not.

What other changes had been made to the file? E.g. was the addition sequence of the below modified:

Code:

---

$grid_loop++ <= $grid_add_number

---

I'm not sure I follow how it occurs each and every time to be one extra.

Which to do with the variables? Somewhat a good question. In some cases I set it to null and in some other places I use unset... I tend to use unset more for clearing memory as in to dispel the existence of a variable and it is not expected to be used again or to have any significance. Setting to null? well, somewhat depends as well.. If it is to be used in an arraylike function then I would more likely set to an empty array so that it has the properties just not the information. Sometimes it is just try one and see if it breaks. :) Just being honest.

The base SBA install code for this file was modified as part of installation of zxpos, but the changes do not affect the current discussion. I have been integrating that add-on into the system. However, we have very unique requirements that made significant changes to the overall zxpos add-on necessary, but not in extra_cart_actions/stock_by_attributes.php file. The basic integration is complete and works well and I am now working on getting rid of php notices such as the subject of this post.

I did not change the post-increment operator. As I understand it, the first time through the statement, the current value of $grid_loop is tested to see if it's less than or equal to $grid_add_number, and then $grid_loop is incremented. The first time through, $grid_loop is zero, and in my case, $grid_add_number is one. So when $grid_prod_id, $grid_id, and $prod_qty arrays are used in the next three lines, they are indexed by $grid_loop - 1 or 0, the first value in the arrays. The next time through the loop, $grid_loop is still one and is still less than or equal to $grid_add_number (one). $grid_loop is then incremented to 2, so the index into the arrays is 2-1, or 1, but there is no array key of 1, resulting in the undefined index of 1 message. Since there are no array elements with key of one, the three $_POST variables are set to null. The next line tests whether the $_POST['products_id'] is set or not, and if not, which is true when it's null, all of the following code to the end of the while loop is bypassed.

What I don't know is how or when, $grid_add_number is greater than 1. In fact, I'm not sure what the term "grid" refers to. Is it a grid display of some kind? And if so which display would allow a user to select more than one product and choose attributes at the same time?

Am I wrong in seeking to eradicate these php notices? It gets so frustrating trying to deploy a zc update with add-ons. I've abandoned several updates because the next version comes out before I'm finished with the updating. And I'll bet 158 comes out before I'm done with 157c.
Dave

Quote:

---

Originally Posted by Dave224

The base SBA install code for this file was modified as part of installation of zxpos, but the changes do not affect the current discussion. I have been integrating that add-on into the system. However, we have very unique requirements that made significant changes to the overall zxpos add-on necessary, but not in extra_cart_actions/stock_by_attributes.php file. The basic integration is complete and works well and I am now working on getting rid of php notices such as the subject of this post.

I did not change the post-increment operator. As I understand it, the first time through the statement, the current value of $grid_loop is tested to see if it's less than or equal to $grid_add_number, and then $grid_loop is incremented. The first time through, $grid_loop is zero, and in my case, $grid_add_number is one. So when $grid_prod_id, $grid_id, and $prod_qty arrays are used in the next three lines, they are indexed by $grid_loop - 1 or 0, the first value in the arrays. The next time through the loop, $grid_loop is still one and is still less than or equal to $grid_add_number (one). $grid_loop is then incremented to 2, so the index into the arrays is 2-1, or 1, but there is no array key of 1, resulting in the undefined index of 1 message. Since there are no array elements with key of one, the three $_POST variables are set to null. The next line tests whether the $_POST['products_id'] is set or not, and if not, which is true when it's null, all of the following code to the end of the while loop is bypassed.

What I don't know is how or when, $grid_add_number is greater than 1. In fact, I'm not sure what the term "grid" refers to. Is it a grid display of some kind? And if so which display would allow a user to select more than one product and choose attributes at the same time?

Am I wrong in seeking to eradicate these php notices? It gets so frustrating trying to deploy a zc update with add-ons. I've abandoned several updates because the next version comes out before I'm finished with the updating. And I'll bet 158 comes out before I'm done with 157c.
Dave

---

Ahh. So you're *not* using the products attributes grid plugin for which all that grid stuff was developed.

Unfortunately then, I have no immediate assistance as I would have to look at the other software to determine what, if anything were to be kept or modified.

As to what that other software does (PAG): basically allows up to two attributes to be crossed with each other visually so that, for example, X large-blue pairs of shoes could be purchased as well as Y small-green pairs and Z XS-red... select add-to-cart (one time) and all three "product" are added to the cart in the quantity identified... Something like the add selected product to cart button that is available when looking at a product list and able to enter a quantity in the text box for each product.

That some other code is using a similar data structure, well, like said, I don't have much input at the moment on how its operation differs from the product attributes grid plugin. I seem to recall or think I've seen something like that discussed in here before as someone else has had to make some sort of similar change(s) to the extra_cart_actions file.

Quote:

---

Originally Posted by Dave224

Thank you for your active support of SBA! It would have taken me weeks to understand the processing to the point where I could have figured out that a duplicate customid was causing the problem. I appreciate all your efforts on zen cart and I'm sure others do too!
Dave

---

While I still have some work to do on the installer to get rid of a few annoying things, I've updated the admin interface for inserting a variant to detect insertion of a duplicate customid and/or presence of multiple entries of that same customid. In other words, there should be/should have been more information made available when that duplicate customid was encountered and I believe that there now is... Of course, I attached it to a great number of other changes that have been made/incorporated such as for Zen Cart 1.5.7 admin side, there is only one modification made now and that is to potentially use/capture a notifier that had been a part of a past/earlier image swap type plugin that someone requested I incorporate. On the catalog side, there is very few modifications merged/incorporated, there is one for the shopping_cart to offer some additional messages about products when stock is "low" and there is the tpl_modules_attributes.php file that is modified to support the sequenced dropdowns (could be implemented in some other way and possibly with a better tool, but hasn't been worked out yet).

Dave224, mind trying this change?

This is what I think looks best for the insert/duplicate issue mostly: Single commit to: · mc12345678/Stock_By_Attributes_Combined@341f55b (github.com)
Based on the above date of download (and pointer for the master thread), the below is a link to show what all has changed since that particular download date: Comparing ee541d783dcd8e1136db57b4e088f5ba74b16449...master · mc12345678/Stock_By_Attributes_Combined (github.com)

I haven't done anything further to address the "grid" issue as in to try to force its operation to just the one plugin, so I expect there to still be differences to incorporate to address what is installed to your site.

FYI, I've been running this on PHP 8.0 with strict php operation in place. Doesn't mean that I haven't missed something because there are a lot of "paths" that logic can take. Basically down to a total of three files that get touched for *full* installation though the concept of the program works without any of those being incorporated. Those changes simply offer possible improved customer experience...

You are right, I'm not using the grid addon. That said, what does the products_quantity_mixed field in table products indicate? It's set to 1 for every product in the database, even for deployed 155f and for products with and without attributes. And the default value is 0. Does this seem correct?
Dave

Quote:

---

Originally Posted by Dave224

You are right, I'm not using the grid addon. That said, what does the products_quantity_mixed field in table products indicate? It's set to 1 for every product in the database, even for deployed 155f and for products with and without attributes. And the default value is 0. Does this seem correct?
Dave

---

See this docs writeup: https://docs.zen-cart.com/user/products/mixed_on/

While it mostly describes conditions for minimum quantities, it applies to maximum as well.

Seem right? Not really, but doesn mean anything to product without attributes. Haven't looked in a while, but it *may* have an effect in "processing" time to address handling the on state. Btw, this is seriously over the top in considerations, just one of those things... it could be set to 1 so as not to forget to set it as a routine part of adding product.

I don't understand. Are you saying not to worry about that field being set to 1? As I read the document, it applies to me only for quantity discounts for products in two categories, and no attributes are involved. But that field *is* causing processing for other products to go down a path that creates an undefined index in shopping_cart.php.

Quote:

---

Originally Posted by Dave224

I don't understand. Are you saying not to worry about that field being set to 1? As I read the document, it applies to me only for quantity discounts for products in two categories, and no attributes are involved. But that field *is* causing processing for other products to go down a path that creates an undefined index in shopping_cart.php.

---

Well, it may seem that when using the setting to address quantity discount related items, perhaps there is something amiss in the shopping cart for the area where the notice is being generated... Personally, I hadn't "remembered" or until rereading that section considered the flag for anything other than attributes... As a result and because I developed some of the cart handling code that handles some of the "mix", there likely is something not considered that should be.

To worry or not really depends on ones use and need... That doesn't mean that something shouldn't be adjusted/fixed though... It sounds like you generally have a need for the setting to be on so that quantity discounts can be applied. As a result, it also seems that the notice needs to be addressed. Where is the notice occurring?

Though, it may also relate to this other software that was triggering the grid related properties as it is doing something other than what core Zen Cart software does... Just guessing though since don't have the full information.

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

Quote:

---

Originally Posted by 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.

Quote:

---

Originally Posted by 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:

Code:

---

$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.

Quote:

---

Originally Posted by 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....68#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

Code:

---

/*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.

Quote:

---

Originally Posted by 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

Code:

---

/*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?

Quote:

---

Originally Posted by 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.

Quote:

---

Originally Posted by 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.

Quote:

---

Originally Posted by 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:

Code:

---

        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:

Code:

---

        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)) {

---

Quote:

---

Originally Posted by 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

Quote:

---

Originally Posted by 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).

Quote:

---

Originally Posted by 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.

Attachment 19591

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?

Quote:

---

Originally Posted by 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.

Code:

---

[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...

Quote:

---

Originally Posted by 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.

Code:

---

[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?

---

Quote:

---

Originally Posted by 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_...4432003eba31ca

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.

Quote:

---

Originally Posted by 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

Code:

---

//        $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) : '');

---