Quote Originally Posted by mc12345678 View Post
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).