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

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