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.

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

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?

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.

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

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

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?

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.php?47180-Stock-by-Attribute-v4-0-addon-for-v1-3-5-1-3-9&p=1374386#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". :)

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.php?47180-Stock-by-Attribute-v4-0-addon-for-v1-3-5-1-3-9&p=1374386#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:

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/issues/4145#issuecomment-751158215

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/issues/4145#issuecomment-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.

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/issues/4145#issuecomment-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.

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.

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/issues/4145#issuecomment-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.

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_By_Attributes_Combined/blob/01f9b26dc3bb0fe6f65886ae9b4f0137e5421aa5/1_5_7/admin/attributes_controller.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

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_By_Attributes_Combined/blob/01f9b26dc3bb0fe6f65886ae9b4f0137e5421aa5/1_5_7/admin/attributes_controller.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?

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.