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

This was an upgrade from 1.5.5f(upgraded all the way from 1.2.7) to 1.5.7c. I do not know at what point SBA was originally added. Each product ID had more than one entry in the products_with_attributes_stock table. It is a warning and does NOT stop the shopper from purchasing the item.

We will just create a MySQL template to run in the admin each time one of these warnings comes up.

THANX for pointing me in the right direction.

dbltoe:

This was an upgrade from 1.5.5f(upgraded all the way from 1.2.7) to 1.5.7c. I do not know at what point SBA was originally added. Each product ID had more than one entry in the products_with_attributes_stock table. It is a warning and does NOT stop the shopper from purchasing the item.

We will just create a MySQL template to run in the admin each time one of these warnings comes up.

THANX for pointing me in the right direction.
At that point in processing, the "limit" would be expected to be the number of product available as defined in the product information page, if the site was set to not allow "overselling". Because the product would not have any limiting defined attributes and it is permitted to be sold without attributes (basis of the product), then the prevention factor should become how the store handles the total quantity of product.

I'll also look at providing some sort of information in the admin screen for product found in the SBA table that are not otherwise expected to be displayed (effectively products_id in the SBA table where that product does not have attributes).

The logged message was coded in as a warning (instead of an error) because of the above expected path to completion and the possibility of that situation. Basically, there is information in a portion of the database (SBA table) that shouldn't be there which is made "noticeable" because there is not an excess check on the catalog side for "accuracy" of the admin controlled data. E.g., there isn't a check against the products_attributes table while a customer is navigating to see that the potential attributes tracked by SBA no longer exist on the product... If/When properly/sufficiently managed on the admin, that discrepancy should not exist. Unfortunately, at the moment there isn't a ready tool to identify the condition identified (product "had" attributes, but no longer does and in managing the attributes the downstream data was not sufficiently updated.)

Now, there is a check of attributes "fed" to SBA to see how they relate to the tracked product and is generally expected to reject options that do not exist (there is the potential for exceptions) or where stock is not permitted to be drawn (attribute selections result in negative stock where negative stock is not permitted). Again, a lot of caveats available/possible.

That code section may be a good place to incorporate a notifier to permit some other operation to be performed instead of just generating a log. Again, note that should not just simply delete the product from that table when coming across that log generating area, again because the "tracking" of a product being associated with SBA is currently tied to the session of the visitor with limited points at which that gets regenerated. Looking to revise this aspect, but need to be sure to capture the information needed in the cases where pages change.

Can combinations of attributes be set up in SBA to track inventory but exclude other attributes? For example, I want to track inventory for each combination of shirt color and size, but not include another attribute which affects price, such as number of words printed on the shirt, since the words are printed after the sale.

I tried this on a sample product ignoring (not entering) the third attribute while setting up custom ids and inventory. But, although I can select the the first attribute while purchasing, the second and third attribute can not be selected. I'm using dynamic dropdowns. When I deleted the third attribute, everything worked with the two dropdowns.

If SBA can handle this case, how do I do it?

Thanks,

Dave

Dave224:

Can combinations of attributes be set up in SBA to track inventory but exclude other attributes? For example, I want to track inventory for each combination of shirt color and size, but not include another attribute which affects price, such as number of words printed on the shirt, since the words are printed after the sale.

I tried this on a sample product ignoring (not entering) the third attribute while setting up custom ids and inventory. But, although I can select the the first attribute while purchasing, the second and third attribute can not be selected. I'm using dynamic dropdowns. When I deleted the third attribute, everything worked with the two dropdowns.

If SBA can handle this case, how do I do it?

Thanks,

Dave
Yes, it is though at this time it is more via Install SQL Patches or phpMyAdmin than anything.

So there are some "hints" in the instructions in the configuration screen:

• To support the newly added non-stock table entry, follow the following guidance:

• A single product's value can be considered non-stock by entering the products_id as the source_id, the options_values_id as the type_id and the type as PV.

• A single product's options can be considered non-stock by entering the products_id as the source_id, the options_id as the type_id and the type as PO.

• A single option value (potentially applicable to all product) can be considered non-stock by entering 0 as the source_id, the options_values_id as the type_id and the type as AV.

• A single option (potentially applicable to all product) can be considered non-stock by entering 0 as the source_id, the options_id as the type_id and the type as AO.

• The expectation (upon software completion) is that an option_value will only be defined by only one of the above rules such that once all option values for an option name has been populated, then the option name itself will be defined and the individual records removed.

What does this mean? Well, there is a lengthy discussion of the "feature" that I again found by searching this forum on "gift wrap" which is along the lines of what this feature is considered. The ability to have something associated with the product that is not related to tracking the stock of the product.. The above "fields" are those that are in the table 'products_with_attributes_stock_attributes_non_stock'. The file 'includes\extra_configures\pwas_non_stock.php' contains CONSTANTS' and their associated definition which is expected to match to the database value(s).

I found that post #2811 contained a link back to where discussion centers on the feature asked about above. Obviously I suggest also looking around that post and the referenced post(s) as there may be further discussion around them that could offer some help.

Basically would need to identify how you plan on that particular attribute working throughout any Stock By Attributes relationship. In the case of text, yes it may be that you don't want to track the option name (option) for this one product, but may want to for another product... If it is for the one product, then would be considering the PO option above, if it is ever and always that it is desired to NEVER have it be related to stock then would consider the AO option. But remember if you pick a larger grouping, when it becomes desirable to then allow that specific characteristic either have to create a new attribute, find a way to exclude that product from the grouping or some other solution. Best to plan for your possibilities, understand the limitations, try to identify ways for things to be better and then implement whatever is needed.

I don't yet have a "visualization" of those options in the admin. I'm in the midst of some updates right now for the ZC 1.5.7 specific files which results in suggesting only two ZC 1.5.7 files need editing to support the full complement of features. Those two are admin/packingslip.php and includes/templates/YOUR_TEMP/templates/tpl_shopping_cart_default.php

Yes there are two files in the core includes directory that still need/could use modification, both are located in includes/templates/YOUR_TEMPLATE/templates and they are tpl_modules_attributes.php (which is edited primarily for dynamic dropdowns as they are not yet implemented as javascript/jQuery type objects) and tpl_modules_main_product_image.php to help enforce that the newly added id parameter though that might be possible through an observer when displaying the image... Likely will look into that so do not have to modify that template file either...

As to dynamic dropdowns, last I knew it works with this non-stock feature. I haven't tested it in a while but I would expect the above linked post(s) to provide information about it.

Just pushed a really big set of changes to github, though refrained from putting it on the master branch... For now...
It seems to be working for me in the many different testings that I've done, but, there are even many more differences out there...

So, biggest changes? (Possibly not yet incorporated into the admin installer "directions"), There are now only basically 3 files that get modified/overridden. They are:

1. includes/templates/YOUR_TEMPLATE/templates/tpl_shopping_cart_default.php
2. includes/templates/YOUR_TEMPLATE/templates/tpl_modules_attributes.php
   and
3. admin/packingslip.php

Reasoning for each:

1. To support display of additional information offered by SBA to include the total quantity of a variant that exists, if stock is low, etc... Also includes modification to support display of customid information
2. Fully support the current rendition of Dynamic Dropdowns. There are other "tools" that could provide the display that this offers. More work needs to be done for either.
3. This incorporates a notifier that was added many years ago in support of a sort of picture display/swap plugin that was requested to be made compatible with SBA. The solution was to make SBA more compatible with that. As a result, this notifier has been retained.

What that also means though, is that if all of the current software is taken to a site, then the changes that were introduced into other template files and admin files from "previous" versions would need to be removed... NOTE the CHANGES need to be removed, NOT THE FILES (generally speaking)... These changes for the most part apply all the way back to ZC 1.5.1 (first tracked version for this plugin). I have attempted to remove the file(s) as appropriate from the distribution. That said, if you leave the changes in the template/admin files and navigate to an SBA product, then if the new method applies to your older version you will see that customid/model information twice...

I've kept the commit history of my changes. In some cases there was a progression from one style to another, in others I just make the full change at once. I have also gone and refactored a lot of the code to make reading it a little easier and to remove a lot of the if() { if() { if() { if() { if() {}}}}} type statements and similar things with loops where early exits are provided instead of large groupings of if statements that otherwise result in just moving to the next record.

I also transitioned many of the loops from for loops to foreach loops, in this way an interim item could be removed from the list and operation could continue without giving some sort of logged feedback that the item was missing or needing excess code to check for the presence/absence of the item.

I also addressed the issue that dbltoe brought up where now at the bottom of the screen there is a separate "listing" if product are identified in the product_with_attributes_stock table that currently do not have attributes assigned. The display appears similar to the current display when attributes are assigned. Could say it is still a work in progress, but basically if that problem does not exist, then the bottom of the screen from the viewer's perspective looks the same as it did. There is/will be a little extra html code, but....

Added an ignore statement associated with deleting product attributes to prevent operation from stopping/creating a mydebug file. I hadn't seen one, but the logic tells me that the ignore statement was needed.

Updated some of the catalog side observers to operate similar to their admin counterpart which has/had an effect on customid aspects.

Added observer files for customid display as well as image swap operation (this observer allowed removal of edits to the main_products_images file(s)). On image swap operation, I haven't tested the javascript/jQuery response when navigating to product not tracked by SBA where the attribute selection type is the newly added SBA simple select (dropdown).

One thing I did was to convert to using an array when requesting response from zen_get_products_stock or zen_check_stock where the array is made of the products_id and the attributes of the product. This information makes processing of the information easier than trying to possibly sort through the cart or an order, especially where processing of an order could change the attributes associated with the product. At any rate, this is to also replace a previous method that was used and is becoming more difficult to use as PHP versions go on. For the time being both methods remain available (sending as an array or overloading those two functions with the attributes information).

To see these new "features" can go to: mc12345678/Stock_By_Attributes_Combined at next-update (github.com)
or to see the differences to the current master: Comparing master...next-update · mc12345678/Stock_By_Attributes_Combined (github.com)

Haven't really looked forwards to some of the changes made here, because again, there has been code introduced to files since initial usage that no longer are considered necessary because I have found somewhere "convenient" to insert the value(s) sought... Doesn't mean it works great with YOUR store, but it is somewhere that works in a default store.

I'm having trouble adding attribute combinations for a product. Everything was fine adding attribute combinations until I tried to add the 61st item for an item. There are two attributes: color and size for one product: tee shirts. When I submit the 61st item from the attribute selection, description, custom id and quantity input page, the green success message appears at the top of the page but the new item is not displayed on the product attribute list page and is not recorded in table products_with_attributes_stock. The highest stock_id for that table is 150. Have I hit a limit somewhere?
Dave
PHP 7.3, zc 157c, SBA version dated Mar 22, 2021 and downloaded from GIT

Dave224:

I'm having trouble adding attribute combinations for a product. Everything was fine adding attribute combinations until I tried to add the 61st item for an item. There are two attributes: color and size for one product: tee shirts. When I submit the 61st item from the attribute selection, description, custom id and quantity input page, the green success message appears at the top of the page but the new item is not displayed on the product attribute list page and is not recorded in table products_with_attributes_stock. The highest stock_id for that table is 150. Have I hit a limit somewhere?DavePHP 7.3, zc 157c, SBA version dated Mar 22, 2021 and downloaded from GITThere is no programmed "maximum" number of variants that would limit the resulting number of variants. This could be "proven" by removing a variant and then attempting to add this "problem" variant. If still not successful, then its not the 61 variant issue, but instead a problem with the combination of the attributes. That said, the next thing is to try to identify the cause(s) of 1) the variant not being added, but a report of success...I haven't seen such a report in a possible long time. I thought I may have come across it several years ago, but...So, heres the things that would help to know about in no particular order:Attributes associated with the product as shown in the attributes controller, what option name types are associated (check box, dropdown, etc..)While I see that you are familiar with looking over the database, are equally familiar with reviewing the source page code of a web page? If so, please identify the value(s) for the dropdown option selections for these attributes that are being combined and any other dropdown selection values that would be expected to be submitted as part of generating this variant.Does this store support more than one language? (I don't know of a current issue with that, but have had to previously make some changes to support it.)Unfortunately also need to ask about the "history" of the store... is it an upgraded store (database is the item of interest/concern), from what if so, etc...I think from there, might have additional questions about the information that gets submitted, but a next consideration is identifying which of the processing paths are taken to reach the attempt to submit the variant, the data that is being fed to that insert method and then to chase down the processing of the data within that class method.Ultimately the "test" that is indicating a successful addition has multiple potential ways to support identifying success, so the condition(s) that are being met for that would be helpful but not by itself. Meaning, need to know some upstream info to likely be able to resolve this discrepancy. I'm all for solving it as it shouldn't be happening.

mc12345678,
Here are some answers to your questions:
(1) Attributes associated with the product as shown in the attributes controller: color and size
(2) Option name types: both are radio buttons
(3) Values for the dropdown option selections for those attributes that are being combined: Ash, "Good for the Next 100 years!" and S (for small)
(4) Any other dropdown selection values that would be expected to be submitted as part of generating the variant: none if you mean other attributes for the variant that fails. Values for other variants include M,L,XL,2XL,3XL for size, and 11 other colors/descriptive info for color.
(5) More than one language: no, only english
(6) History of the store: fresh install of zc157c with SBA, Edit Orders, ZXPOS (purchased), ZCA Bootstrap Template (but not currently using), Better Together and other purchased SW Guy discount addons, and other custom tailoring. Database was copied over from v155f and updated via the zc v157c installer. Of note is that the SBA-related tables have a mix of products with and without a Unique Combo value. The product I am having trouble with has Unique Combo values for each variant.
(7) Processing path taken to reach the attempt: The success message displayed when adding the variant fails is "Product successfully updated" (PWA_UPDATE_SUCCESS). This is generated in only one place: in admin/products_with_attributes_stock.php. The browser URL (or URI?) is index.php?cmd=products_with_attributes_stock&action=add&products_id=706&search_order_by=p.products_model. The products_id is correct and I was trying to add a variant.
(8) Data fed to insert method: examining $saveResult when $messageStack is set to PWA_UPDATE_SUCCESS looks correct. sql_query is 'UPDATE products_with_attributes_stock set quantity = 10, customid = 'ASH_GOOD_S', title= 'POS: Ash, Good..., S',barcode= null WHEREproducts_id= 706 ANDstock_attributes= '163755,163806". Note thatbarcode` is added as part of the ZXPOS add-on.
(9) Conditions that are being met to generate the success message: I developed a debug function that emails values of variables/expressions. See attachment.

Hope this helps,
Dave

Attachment #19578

Very useful information, thank you. While each answer didn't necessarily provide the sought information, the other information filled in many of the gaps.

Ok, so a couple of things I see... The query: 'UPDATE products_with_attributes_stock set quantity = 10, customid = 'ASH_GOOD_S', title= 'POS: Ash, Good..., S',barcode= null WHEREproducts_id= 706 ANDstock_attributes= '163755,163806" has a mistake in it, though I don't know if that was manually typed or copy/pasted. Aftercustomid there should be another backquote (on US keyboard the key in the upper left corner in combination with the tilde (~).)

As far as uniqueness, based on what I'm seeing in admin/includes/classes/products_with_attributes_stock.php at/around line 716:

      $query = "SELECT count(*) AS total FROM " . TABLE_PRODUCTS_WITH_ATTRIBUTES_STOCK . " WHERE (products_id = :products_id: AND stock_attributes = :stock_attributes:) " . (isset($productAttributeCombo) ? "OR product_attribute_combo = :product_attribute_combo: " : "") . (isset($customid) /* @TODO if customid is not required to be unique then and with a false */ ? "OR customid = :customid:" : "");

It appears that a duplicate/existing record is being found based on this query or the query as modified to support barcode.
The goal of this query is to use the provided information that determines if a lookup identifies a duplicate entry in the pwas table. Based on what happens next, it seems that there is a duplicate found. If the query is unmodified to support the additional field, then it would seem that the customid is non-unique. This is first based on the fact that it seems that the combination of products_id and stock_attributes being entered does not exist (report of variant not being in the list nor in the database) and that just before this call, the product_attribute_combo is generated to equal the combination of those two fields which since that original combination doesn't exist I wouldn't expect this one to exist either. Therefore, the only remaining "duplicate" is the customid of 'ASH_GOOD_S'. Please confirm that customid already exists in the database for any product. If it does not, please identify how this query is otherwise different than originally provided.

Then, if the customid actually is the duplicate record, then it would seem that the next "duplicate" searching query has not been updated to further reflect the comparison criteria or I have a problem with the evaluation that immediately follows. The words/concepts "seem" right, but the results don't seem to match. The query I'm speaking to is:

"SELECT count(*) as total FROM "  . TABLE_PRODUCTS_WITH_ATTRIBUTES_STOCK . " WHERE ((products_id = :products_id: AND stock_attributes = :stock_attributes:) " . (isset($productAttributeCombo) ? "OR product_attribute_combo = :product_attribute_combo: " : "") . ") AND `customid` != :customid:";
                  // If find a record, then the customid was assigned to some other product or the two parts of the where

As the logic is this: have already found that the earlier query identified one or more records searched on an 'or' basis. Because we are talking about whether the customid is unique or not, it could be that the customid is already assigned to this one product or it could have been used in multiple places... If it is already assigned to this one product, then it is fine that the customid "already" exists because the customid identifies to this product... But, if the customid is used elsewhere, then attempting to apply the customid to this record would mean that at least a duplicate exists, could be used more times than one. So... This query is expected to identify if the combination for this variant exists where the variant is not assigned to the current customid (with the customid not being empty)...

There may be an incorrect action after this for not finding a match, but I think at this point it would be good to get the results from above first... I know that I had made changes to the "duplicate" customid inspection some time ago with the possibility of not requiring a unique customid for all variants.

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.

Dave224:

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.

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

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

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

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

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

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

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

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

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

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.

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.

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