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

[mc12345678]

There was a typo in the query.

The customid was used in another product. Changing the customid allowed the variant to be added. Thank you!!!

But I'm confused about what you said about the 2nd query. Is there something wrong with it? Seems to me that a failure or warning message should come up in this case. Is the integration with the barcode code faulty?

Dave
PS: I don't know why the attachment can't be opened.

A little backstory without too much detail. A previous method of identifying a duplicate customid upon submitting a record was not liked by more recent versions of MySQL and therefore had to be revised/rewritten. That was not done to full completion and thinking back I thought that I had removed the need for the customid to be unique from processing.

So, what about the above second query? It is written with the intent to identify the existence of the variant to not have the customid. The problem (as now completely identified) is that if the variant does not exist without the customid (count == 0) then it seems that there is not enough information yet gathered/evaluated to clearly communicate what needs to be done nor to take the expected action. What is known at that point is:
a customid is present for evaluation
the variant or the customid exists in the database, then
the customid exists in the database (the number of which is in the results), then
That variant might have the customid or another variant might have the customid (requesting additional information in the previous query would likely help or elminating the != portion of the query and just returning the customid(s) and processing them to see if the customid is in that grouping).

More evaluation is needed to identify the relationship between the customid and the remaining data. I think it was here that I stopped development. So yes, more information assistance would be appropriate.

Some things that I was trying to further address/consider were, what is the current status of the database: are duplicates allowed or not. If not allowed, then how bad is the current state and "where/when" should that be corrected? The change in allowance would be (at some point if not already present) through an admin configuration switch... Should transition of that switch kick off a process to evaluate and address duplicates? Probably best at that point. Simultaneously another admin may be in the process of adding/editing product or without that "auto process" duplicates should be seen/prevented when/where possible upon insertion.

Was also trying in one or more ways to minimize the queries to the database to evaluate the condition based on the possibility/existence of previous information. I was also trying to be sure that I could allow the level of questioning to be editable for other fields/logic.

I can say that at this very moment I'm a little flustered at identifying a best path forwards because I had some concerns that I was trying to address the importance of which I need to re-evaluate and I would say that obviously have not fully addressed customid duplication... Right now to see the new variant in the list of variants, the customid has to be unique, but the user doesn't get told that a duplication has occurred and I would say that the duplicate condition hasn't really been identified. Its just that an error doesn't occur in attempting to move forwards...

This aspect hasn't recently been an area of focus and likely others have either worked around it in some way outside of the github code... I know I had good intentions, but that portion is not there yet.

[Dave224]

Thank you for your active support of SBA! It would have taken me weeks to understand the processing to the point where I could have figured out that a duplicate customid was causing the problem. I appreciate all your efforts on zen cart and I'm sure others do too!
Dave

[Dave224]

I've encountered an undefined offset notice on lines 528, 529, and 530 of includes/extra_cart_actions/stock_by_attributes.php. Examining the code, the while loop is executed one more time than necessary with the result of an undefined offset and with three $_POST variables set to null on the last pass. The latter result is necessary (good) to prevent subsequent processing from increasing the quantity of the product. I changed the while test from <= to < on line 527, which eliminates the extra pass and undefined index, and unset the three $_POST variables following line 912 after the while loop to accomplish the result of the extra pass. While unset eliminates the three $_POST variables rather than setting them to null, it seems to work okay for my products, but I wondered if you had any thoughts about the change considering the variety of cases the code is designed for? Should I set the $_POST variables to null instead of unsetting them?
TIA,
Dave
zc157c, SBA 5.1.4 (March 22, 2021), php 7.3

[mc12345678]

I've encountered an undefined offset notice on lines 528, 529, and 530 of includes/extra_cart_actions/stock_by_attributes.php. Examining the code, the while loop is executed one more time than necessary with the result of an undefined offset and with three $_POST variables set to null on the last pass. The latter result is necessary (good) to prevent subsequent processing from increasing the quantity of the product. I changed the while test from <= to < on line 527, which eliminates the extra pass and undefined index, and unset the three $_POST variables following line 912 after the while loop to accomplish the result of the extra pass. While unset eliminates the three $_POST variables rather than setting them to null, it seems to work okay for my products, but I wondered if you had any thoughts about the change considering the variety of cases the code is designed for? Should I set the $_POST variables to null instead of unsetting them?
TIA,
Dave
zc157c, SBA 5.1.4 (March 22, 2021), php 7.3

Difficult to just say "sure"! I will say that it is open source and can be worked/reworked as necessary. Certainly would be helpful to understand the setup that is causing this situation. I thought I had tried all sorts of arrangements, I do know that there were some "options" originally considered that haven't been flushed out of that particular file. Those options are not active in the code in a base install and require someone making modifications to the file. But I haven't a clue if they are a part of this discussion or not.

What other changes had been made to the file? E.g. was the addition sequence of the below modified:

$grid_loop++ <= $grid_add_number

I'm not sure I follow how it occurs each and every time to be one extra.

Which to do with the variables? Somewhat a good question. In some cases I set it to null and in some other places I use unset... I tend to use unset more for clearing memory as in to dispel the existence of a variable and it is not expected to be used again or to have any significance. Setting to null? well, somewhat depends as well.. If it is to be used in an arraylike function then I would more likely set to an empty array so that it has the properties just not the information. Sometimes it is just try one and see if it breaks. :) Just being honest.

[Dave224]

The base SBA install code for this file was modified as part of installation of zxpos, but the changes do not affect the current discussion. I have been integrating that add-on into the system. However, we have very unique requirements that made significant changes to the overall zxpos add-on necessary, but not in extra_cart_actions/stock_by_attributes.php file. The basic integration is complete and works well and I am now working on getting rid of php notices such as the subject of this post.

I did not change the post-increment operator. As I understand it, the first time through the statement, the current value of $grid_loop is tested to see if it's less than or equal to $grid_add_number, and then $grid_loop is incremented. The first time through, $grid_loop is zero, and in my case, $grid_add_number is one. So when $grid_prod_id, $grid_id, and $prod_qty arrays are used in the next three lines, they are indexed by $grid_loop - 1 or 0, the first value in the arrays. The next time through the loop, $grid_loop is still one and is still less than or equal to $grid_add_number (one). $grid_loop is then incremented to 2, so the index into the arrays is 2-1, or 1, but there is no array key of 1, resulting in the undefined index of 1 message. Since there are no array elements with key of one, the three $_POST variables are set to null. The next line tests whether the $_POST['products_id'] is set or not, and if not, which is true when it's null, all of the following code to the end of the while loop is bypassed.

What I don't know is how or when, $grid_add_number is greater than 1. In fact, I'm not sure what the term "grid" refers to. Is it a grid display of some kind? And if so which display would allow a user to select more than one product and choose attributes at the same time?

Am I wrong in seeking to eradicate these php notices? It gets so frustrating trying to deploy a zc update with add-ons. I've abandoned several updates because the next version comes out before I'm finished with the updating. And I'll bet 158 comes out before I'm done with 157c.
Dave

[mc12345678]

The base SBA install code for this file was modified as part of installation of zxpos, but the changes do not affect the current discussion. I have been integrating that add-on into the system. However, we have very unique requirements that made significant changes to the overall zxpos add-on necessary, but not in extra_cart_actions/stock_by_attributes.php file. The basic integration is complete and works well and I am now working on getting rid of php notices such as the subject of this post.

I did not change the post-increment operator. As I understand it, the first time through the statement, the current value of $grid_loop is tested to see if it's less than or equal to $grid_add_number, and then $grid_loop is incremented. The first time through, $grid_loop is zero, and in my case, $grid_add_number is one. So when $grid_prod_id, $grid_id, and $prod_qty arrays are used in the next three lines, they are indexed by $grid_loop - 1 or 0, the first value in the arrays. The next time through the loop, $grid_loop is still one and is still less than or equal to $grid_add_number (one). $grid_loop is then incremented to 2, so the index into the arrays is 2-1, or 1, but there is no array key of 1, resulting in the undefined index of 1 message. Since there are no array elements with key of one, the three $_POST variables are set to null. The next line tests whether the $_POST['products_id'] is set or not, and if not, which is true when it's null, all of the following code to the end of the while loop is bypassed.

What I don't know is how or when, $grid_add_number is greater than 1. In fact, I'm not sure what the term "grid" refers to. Is it a grid display of some kind? And if so which display would allow a user to select more than one product and choose attributes at the same time?

Am I wrong in seeking to eradicate these php notices? It gets so frustrating trying to deploy a zc update with add-ons. I've abandoned several updates because the next version comes out before I'm finished with the updating. And I'll bet 158 comes out before I'm done with 157c.
Dave

Ahh. So you're *not* using the products attributes grid plugin for which all that grid stuff was developed.

Unfortunately then, I have no immediate assistance as I would have to look at the other software to determine what, if anything were to be kept or modified.

As to what that other software does (PAG): basically allows up to two attributes to be crossed with each other visually so that, for example, X large-blue pairs of shoes could be purchased as well as Y small-green pairs and Z XS-red... select add-to-cart (one time) and all three "product" are added to the cart in the quantity identified... Something like the add selected product to cart button that is available when looking at a product list and able to enter a quantity in the text box for each product.

That some other code is using a similar data structure, well, like said, I don't have much input at the moment on how its operation differs from the product attributes grid plugin. I seem to recall or think I've seen something like that discussed in here before as someone else has had to make some sort of similar change(s) to the extra_cart_actions file.

Thank you for your active support of SBA! It would have taken me weeks to understand the processing to the point where I could have figured out that a duplicate customid was causing the problem. I appreciate all your efforts on zen cart and I'm sure others do too!
Dave

While I still have some work to do on the installer to get rid of a few annoying things, I've updated the admin interface for inserting a variant to detect insertion of a duplicate customid and/or presence of multiple entries of that same customid. In other words, there should be/should have been more information made available when that duplicate customid was encountered and I believe that there now is... Of course, I attached it to a great number of other changes that have been made/incorporated such as for Zen Cart 1.5.7 admin side, there is only one modification made now and that is to potentially use/capture a notifier that had been a part of a past/earlier image swap type plugin that someone requested I incorporate. On the catalog side, there is very few modifications merged/incorporated, there is one for the shopping_cart to offer some additional messages about products when stock is "low" and there is the tpl_modules_attributes.php file that is modified to support the sequenced dropdowns (could be implemented in some other way and possibly with a better tool, but hasn't been worked out yet).

Dave224, mind trying this change?

This is what I think looks best for the insert/duplicate issue mostly: Single commit to: · mc12345678/Stock_By_Attributes_Combined@341f55b (github.com)
Based on the above date of download (and pointer for the master thread), the below is a link to show what all has changed since that particular download date: Comparing ee541d783dcd8e1136db57b4e088f5ba74b16449...master · mc12345678/Stock_By_Attributes_Combined (github.com)

I haven't done anything further to address the "grid" issue as in to try to force its operation to just the one plugin, so I expect there to still be differences to incorporate to address what is installed to your site.

FYI, I've been running this on PHP 8.0 with strict php operation in place. Doesn't mean that I haven't missed something because there are a lot of "paths" that logic can take. Basically down to a total of three files that get touched for *full* installation though the concept of the program works without any of those being incorporated. Those changes simply offer possible improved customer experience...

[Dave224]

You are right, I'm not using the grid addon. That said, what does the products_quantity_mixed field in table products indicate? It's set to 1 for every product in the database, even for deployed 155f and for products with and without attributes. And the default value is 0. Does this seem correct?
Dave

[mc12345678]

You are right, I'm not using the grid addon. That said, what does the products_quantity_mixed field in table products indicate? It's set to 1 for every product in the database, even for deployed 155f and for products with and without attributes. And the default value is 0. Does this seem correct?
Dave

See this docs writeup: https://docs.zen-cart.com/user/products/mixed_on/

While it mostly describes conditions for minimum quantities, it applies to maximum as well.

Seem right? Not really, but doesn mean anything to product without attributes. Haven't looked in a while, but it *may* have an effect in "processing" time to address handling the on state. Btw, this is seriously over the top in considerations, just one of those things... it could be set to 1 so as not to forget to set it as a routine part of adding product.

[Dave224]

I don't understand. Are you saying not to worry about that field being set to 1? As I read the document, it applies to me only for quantity discounts for products in two categories, and no attributes are involved. But that field *is* causing processing for other products to go down a path that creates an undefined index in shopping_cart.php.

[mc12345678]

I don't understand. Are you saying not to worry about that field being set to 1? As I read the document, it applies to me only for quantity discounts for products in two categories, and no attributes are involved. But that field *is* causing processing for other products to go down a path that creates an undefined index in shopping_cart.php.

Well, it may seem that when using the setting to address quantity discount related items, perhaps there is something amiss in the shopping cart for the area where the notice is being generated... Personally, I hadn't "remembered" or until rereading that section considered the flag for anything other than attributes... As a result and because I developed some of the cart handling code that handles some of the "mix", there likely is something not considered that should be.

To worry or not really depends on ones use and need... That doesn't mean that something shouldn't be adjusted/fixed though... It sounds like you generally have a need for the setting to be on so that quantity discounts can be applied. As a result, it also seems that the notice needs to be addressed. Where is the notice occurring?

Though, it may also relate to this other software that was triggering the grid related properties as it is doing something other than what core Zen Cart software does... Just guessing though since don't have the full information.