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.
Printable View
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.
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¤t_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
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.