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

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

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

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

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_By_Attributes_Combined/archive/refs/heads/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

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_By_Attributes_Combined/archive/refs/heads/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 ```

• @version $Id: DrByte 2020 Jun 08 Modified in v1.5.7 $
  while the 1.5.7c version is dated
• @version $Id: mc12345678 2021 Feb 22 Modified in v1.5.7c $

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 ```
 * @version $Id: DrByte 2020 Oct 05 Modified in v1.5.7 $
```While the current 1.5.7c version is dated ```
 * @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.

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.

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_By_Attributes_Combined/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

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:

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

to:

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?```
if (!empty($attribute_list) && is_array($attribute_list)) {

Also, in the same file, getting ```
[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.

dbltoe:

Would that be the same fix for line 1180 of /includes/classes/class.products_with_attributes_class_stock.php?```
if (!empty($attribute_list) && is_array($attribute_list)) {

> 
> Also, in the same file, getting ```
[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

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