Actually, thought it best to confirm, for you and others, that yes your code change does resolve the issue.
Printable View
Actually, thought it best to confirm, for you and others, that yes your code change does resolve the issue.
Thank you for that. Yes, that was a good action. Cool, I'll incorporate it into github as soon as I can.Quote:
Originally Posted by simon1066
Quote:
Originally Posted by mc12345678
Incorporated plus a few more code changes to address strict error reporting.Quote:
Originally Posted by mc12345678
So I caught on somewhat on what you are talking about. I'm building the site now so the products are being created now without attributes. I knew I could make one and copy attributes to others. when it comes to sql i'm lost that last part you were talking about sounds like what i want to do.Quote:
Originally Posted by mc12345678
I thought that option might be more along what you are wanting, just hadn't thought of it being used that way. :) users can be so creative!Quote:
Originally Posted by cubmanky
Suggest taking a look at/around post 2725. There had been a new feature added and it does require executing some SQL to make it work, but hopefully it isn't too complicated to figure out. Generally speaking you'll need to look at either/both of the options names manager and/or options values manager to identify the value associated with the needed options.
Hmm, that did remind me. I don't think I implemented copying of product specific information when using that feature and copying product and it's attributes. Will start a new issue on that.
So I looked at 2725 I seethis is kinda the opposite of what I want to do.Quote:
Originally Posted by Christian_Wagner View Post
Is there a way to have dropdowns on a page have independent quantities that aren't affected by each other? ie. I'm selling a product (dropdown #1)
So I made two test products. one I assigned all the colors and linked to SBA, for the second one I copied all the attributes to it. I guess it needs to be dumed down a little more for me.
The final "result" is still the same thing. You want to have an option that is always available (until you decide to make it not available) no matter what else is going on around it. In your case though, you want an option value to always be available (many option values really), but each one to be "assigned" as necessary... Now, considering that you've said that you don't really track the stock *quantity* AND when say "blue" is gone, it is to be gone everywhere, I suggest *not* assigning variants to the SBA tracked product. If you do, then the existence of the stock quantity will make the option available until the stock quantity is set to 0. And if you set the quantity to 0 (with the code as written), then the option will be unavailable even with the appropriate SQL statement. I do have a "comment" in the code that would work in an opposite way to this, but haven't assigned a constant to it yet.Quote:
Originally Posted by cubmanky
Anyways, for your situation where options_value_id 143 is to be available for all product that have it assigned in the attributes controller and the product is tracked by SBA, then one sql statement (to address a single option value) would be:
Where the option value id for your color is 143. The option value id can be found in the catalog->Option Values Manager section and is the number to the left of the option value's name... Then, when you want the item to be out-of-stock or "non-existent" you would do a SQL statement like this:Code:INSERT INTO products_with_attributes_stock_attributes_non_stock (attribute_type, attribute_type_id, attribute_type_source_id) VALUES ('OV', 143, 0);
Code:DELETE FROM products_with_attributes_stock_attributes_non_stock WHERE attribute_type = 'OV' AND attribute_type_id = 143 AND attribute_type_source_id = 0;
Hmmm.. Btw, just thinking about this, because I haven't tried it is that you may need to assign at least one variant to a product to be so tracked... Just thinking a little about the overall assignment(s)/operation(s) that basically the SBA code doesn't kick in unless a product is found in the SBA table which is to have a products_id in the list even if there is otherwise useless information.
So I ran the following code and replace # for the Option Value Name. I did this for all 59 colors.
I made two test products, added all the colors to one and then copied that attribute to the second one.Code:INSERT INTO zc_products_with_attributes_stock_attributes_non_stock (attribute_type, attribute_type_id, attribute_type_source_id) VALUES ('OV', #, 0);
I ran the full upgrade script along with the Add all Product Attributes
I can see all colors on my two products.
next I ran the following code
2 is the id for white. White still showing as a color option. I have both test products linked to SBACode:DELETE FROM zc_products_with_attributes_stock_attributes_non_stock WHERE attribute_type = 'OV' AND attribute_type_id = 2 AND attribute_type_source_id = 0;
my site is http://www.visionsinvinyldesigns.com...=index&cPath=1
click on test or test 2 for products
I just went in and add qty as 100 for variant of pick color on test2 product
Quote:
Originally Posted by cubmanky
I want to be sure that we are both considering addressing the same aspect of operation. In absence of the latest message where a variant quantity ended up being applied against an attribute selection, SBA basically would have not been a factor in this display. Now that every attribute variant has been provided a quantity of 100 (though it only needed one of them to have a quantity applied) test2 is actually a product tracked by SBA.Quote:
Originally Posted by cubmanky
So it seems to me that you're trying to validate that the non-stock feature can be used across the product. While that may be the ultimate goal, there are a few things yet to consider.
At last check all attributes of the test2 product had quantity assigned. As a result of that the non-stock field setting presence/absence will not change the existence of the applicable option. Having stock overrides that an attribute is non-stock tracked as far as being displayed or not.
Then there is the issue of whether an attribute is to be displayed or not and whether it is to be identified as out-of-stock. These other settings can affect whether an option is displayed or not. The important part as far as purchasing is whether the associated selection can be added to the cart. Ie. If the store can not be oversold and a selected combination is entered as not existing, then that combination should not be able to be added to the cart.
Again at my last look, I would say that the test of the "white" attribute would require removing the quantity from the white variant (ie. Removing the variant that has that attribute.)
On another note, it seems that the "Please select color..." option is not setup properly to be a display only, default attribute. I could be wrong.
It does seem that the option name type is correctly set and that the dynamic dropdowns options are correctly set to use the SBA simple select (dropdown) options. I say this because the quantity of available product is shown and I don't see any remnants of the Dynamic Dropdown javascript in the source code.
SO I went in and stripped the attributes for both test products, rebeuilt the attributes for test only and linked it the SBA. I just picked the select color and mad it qty of 100 only but then all the other options get populated with a qty number
Also if I set the pick a color as read only then in SBA I can not select it to add a qty to.
I have not been able to reproduce a problem where a specific option value was selected and data entered to be populated causing all option values to be populated with that information.Quote:
Originally Posted by cubmanky
At least that seems to be what was described above as being attempted.
Read only or display only? (read only is an option name type, display only is a setting in the attributes controller.)Quote:
Originally Posted by cubmanky
As to not being able to add quantity to a display only attribute, that is by design. The original idea was that if not able to select the option to add it to the cart, then how could it have a quantity? Now with this concept of using the non-stock option, that may need to be revisited in some way.
Attachment 18074
this is what showing on my end.
So click on a color, it shows in stock, but when you click to add to cart gives you a out of stock msg. This is for all colors, now if I click on the pick a color it will add it.
So if I make a test product, set the attributes and link it to SBA. I go in an set 20 color in stock and all the others as out of stock, I can then copy the attributes from this test product to others and it will keep the stock/ out of stock settings for all.
Also will say I getat the top of the Products with Attributes stock page, I'm running 1.5.5 and uploaded the files in the 1.5.5 folderQuote:
Stock By Attribute (SBA) Stock Page Version 1.5.4
Anything on my end to help with figuring what is going on. I can do the copy attributes over but that could be difficult
Well, I guess the first thing is to clearly identify what it is that is needing adjustment?Quote:
Originally Posted by cubmanky
I have found that the nullDataEntry method in the admin class is unnecessarily adding quotes around text that is later self quoted by ZC. This effects multi-attribute product and was modified in my upload of last month.
I also looked back at the query written to use the non-stock feature (at least the one received via email) and saw that an unsupported attribute_type was identified for use.
My apologies, if anything in the message before the above message, I referenced the wrong attribute_type. Post 2725 clearly identifies the 4 currently recognized (the values are actually constants that you could change if you wanted, though would be just as easy to execute a sql statement against the table to modify the values already entered.)Quote:
Originally Posted by cubmanky
The values recognized are:
There are four designated "groups" which are considered capable of being non-stock dependent:
All Option ("AO")
All Values ("AV")
Product's Option ("PO")
Product's Value ("PV")
Now that said, yesterday I tried to take advantage of "AO" against a multi-attribute product where variants were assigned in combinations but did not get the result(s) I thought I expected to get.
So for you, you might want to execute:
The above sql statement is executable for ZC 1.5.1 and above from within tools->Install SQL Patches in the ZC admin.Code:UPDATE products_with_attributes_stock_attributes_non_stock SET attribute_type = 'AV' WHERE attribute_type = 'OV';
So I grabbed the files from https://github.com/mc12345678/Stock_...butes_Combined and uploaded them to my site. I ran the above script and looking inand the attribute type is set to AV, Still no luck. On test product I have set the qty for each color individual. for test2 product I just made pick a color at 100 units I have in the out of stock that white is out. Still any color i click on will tell me out of stock when i try to click to add it to the cart.Quote:
`zc_products_with_attributes_stock_attributes_non_stock`
I ran the following sql files
Installation
Full/Upgrade DB Install
Full, makes all script changes to the database (DB) (i.e., adds new SBA table, adds entries into the Admin page, and new entries into the Configuration file).
Upgrade, updates Configuration file and the SBA table as needed. If run again, it will "Clean" table entries and reapply the settings, it will not affect current data in the "products_with_attributes_stock" table.
and Add all Product Attributes
So if for each item I set up the quantity for each color individual it will work. Attachment 18076
If I set just the pick color so it will run SBA Attachment 18077
it only shows pick color in stock and all others are out of stock.
Attachment 18078
Unfortunately I'm having to look into this as my tests being run in parallel with yours are also not working as expected. I've even gone into the class file and changed the setting that is supposed to determine the attribute stock presence by either first looking at the loaded stock or by looking at the non_stock table and ignore the SBA quantity variant.Quote:
Originally Posted by cubmanky
I needed to look more at the code with the proposed setup in mind. I couldn't seem to recall if/how other settings came into play such as checking the stock level, reducing stock after purchase, allowance for overselling, etc... I knew that when it was first incorporated and publicized, it worked...
Mind you, when this was first incorporated the primary thought/concern was what was considered the "gift" option. A choice that could be made that would *always* be available when selecting other attributes that were related to the stock of the product... So, what that meant was that there would always be at least 2 attributes (2 option names) with every product except for some specific characteristic type attributes (Files and text boxes)... Well, development was considered for the single attribute product, but it was not completed. Further, I built in a sort of "safety" of overselling product by causing those such options to not support the non-stock characteristics. Could have left just a little more of a note to myself; however, had commented the area about what needed to be done not so much of how it behaved currently.
Anyways, if you go to includes/classes/class.products_with_attributes_class_stock.php and then modify line 1351 from:
to:Code:return false;
Then when the product has a single attribute and the option values/option names are identified as being non-stock, if the option value is not assigned to SBA, it will be possible to select it and add it to the cart. The total available will be identified as the quantity of product as entered in the product information page.Code:return true;
One thing about it though is that I had set aside some comments in that area of things I thought would be valuable to address to ensure that the data pushed would be validated. I'll get to it, but at least you can get through this issue now. There are a few things to consider as I realized when working with a single attribute that if the option value is not captured in SBA then a quantity is displayed, but when I tried to add the product to the cart, the cart notified that the option wasn't available, even though it appeared in the list. I've spent a great deal more on multiple attributes than single attributes, so need to go back and revisit that operation and functionality.
First I'm glad its not something on my end as you are having the issue.
I made the change and updated the file on my site
On my test2 product it shows all colors in stock. On white I have it still set as out of stock. I click white color and pick 5 then click add to cart It adds them but tells me 1 available.
SO I went in a deleted all variants for test2 then went back and added 100 to pick a color and I get the error Product 23 update failed: IT still shows 100 for each color in the dropdown window
when a product is out of stock, mark_product_out_of_stock it looks at products_quantity to determine this, A splash screen in red shows up and informs the customer, and the products are marked out of stock(Special Ordered) how can i also get it to look at the attribute stock, and show that same splash screen. some of the attributes are instock and some are not but the products quantity has quantity from the ones that do.
this is when no product quantity Attachment 18079
and this is no attribute quantity Attachment 18080
i modified a shipping module to detect out of stock to ship another way so having a problem looking at attribute stock to determine
ex.Code:// Variable holds information about the products in the order
$this->_products = $_SESSION['cart']->get_products();
$_SESSION['cart']->shopping_stock = 1;
$inStock = 0;
$outStock = 0;
$_SESSION['cart']->in_stock_products = [];
$_SESSION['cart']->out_stock_products = [];
foreach ($this->_products as $product) {
$pid = $product["id"];
$qty = $product["quantity"];
$product_query = "select products_quantity
from " . TABLE_PRODUCTS . "
where products_id = '" . (int)$pid . "'";
$product = $db->Execute($product_query);
$quantity = $product->fields["products_quantity"];
if ($quantity < $qty){
$_SESSION['cart']->shopping_stock = 2;
array_push($_SESSION['cart']->out_stock_products,(int)$pid);
$outStock = 1;
}else{
$_SESSION['cart']->shopping_stock = 1;
array_push($_SESSION['cart']->in_stock_products,(int)$pid);
$inStock = 1;
}
}
if($outStock == 1 && $inStock == 1 && count($this->_products) > 0){
$_SESSION['cart']->shopping_stock=3;
}
There's already a ZC function that determines the stock availability which SBA "hooks" into (reason the includes/functions/functions_lookups.php file requires modification in ZC 1.5.5 and below. In ZC 1.5.6 there is expected to be code that will be in place and won't require modification of that file). There is also a function in the includes/classes file added for SBA that also supports, but I would recommend using the modified SBA function if for any reason SBA is removed.Quote:
Originally Posted by jimmie
The modification made to the function is to obtain/use the attributes of the product and from there determine if it is tracked by SBA and what the associated stock is. That function is:
You only need to pass the first two parameters. I'm not where I can easily identify (and at the moment don't remember) the makeup of the attributes portion off of a cart's entry to say what it takes to pull the attributes off of the product information. I'd have to get back to you if you don't know/find it.Code:zen_get_products_stock($products_id, $attributes = null, $dupTest = null)
Found it:
$_SESSION['cart']->contents[$products_id]['attributes']
or as used above:
$product['attributes']
So something like:
Code:$attributes = null;
if (isset($product['attributes']) {
$attributes =$product['attributes'];
}
$quantity = zen_get_products_stock($products_id, $attributes);
Darnit, forgot a right parenthesis on the if statement line. Just happened to be looking over the code and see the imbalance.Quote:
Originally Posted by mc12345678
Code:$attributes = null;
if (isset($product['attributes'])) {
$attributes = $product['attributes'];
}
$quantity = zen_get_products_stock($products_id, $attributes);
Finally being able to zoom in on these two images, I see that they are as later reported related to the shipping module, so hopefully the other assistance provided clarifiesQuote:
Originally Posted by jimmie
(or closely clarifies)this issue.
i will come back to this, very busy
Couple of things.Quote:
Originally Posted by cubmanky
SBA works off of two stock quantities, 1 for the specific attribute (attribute combination when more than one attribute is involved) and the quantity of product identified overall for the product.
Deleting the attribute(s) from the product and reassigning them does not change the non_stock table. This means that if an action hasn't been taken to remove the entries from the non-stock table, then the ones previously assigned remain in place and will cause the single dropdown option to appear to have the quantity available that is entered for the overall product once those attributes are again assigned to the product and the product assigned to SBA.
The recommendation I made a few days ago to change return false to return true will cause the shopping_cart page to only support a quantity of 1 existing in the cart, even though on the product page it will appear that there are more available. The "value" returned should be the quantity of product that are purchasable at that time (either some sort of total quantity of all available product or perhaps some sort of maximum per purchase. This portion of the code as previously said had not been flushed out. Even now with this new concept of using it there are additional caveats to consider.
If configuration->stock->subtract stock is true, then with each purchase, the total available quantity will decrease for both the attribute and the overall product quantity. So, recommend considering how the store's stock is used when trying to flush out operation. At the moment there is no individual setting against SBA that would prevent this decrease for either/both values other than the above described stock setting.
So I hope that with any combination of the above information at least there is some more understanding. Of course I'd like to finish off the section of code in question.
So I still have this changed to true
For test2 I have now added two attributes. the first one is pick type of vinyl, the second one is to pick color. It works, but the colors I have shown in zc_products_with_attributes_stock_attributes_non_stock is what it shows as in stock.Quote:
Anyways, if you go to includes/classes/class.products_with_attributes_class_stock.php and then modify line 1351 from:
Code:
return false;
to:
Code:
return true;
How do i incorporate this into code above. if products qty 0 and products attribute stock 0 this item is nonstock.Quote:
Originally Posted by mc12345678
if products qty 1 and products attribute stock 0 this item is nonstock,
if products qty 0 and products attribute stock 1 this item is instock, etc.
Quote:
Originally Posted by jimmie
Quote:
Originally Posted by mc12345678
Mind you, there is also a function that has been incorporated/modified for SBA called zen_check_stock, which returns a string of text if the product is out-of-stock (less than zero would remain if the provided quantity to be removed from the stock would cause the quantity to be less than zero).Quote:
Originally Posted by jimmie
The modified version of this call is: zen_check_stock($products_id, $quantity_to_try_to_obtain, $attributes);
In your case, the second parameter would be $qty.
While on the surface of things I would approach this differently, I have used the code I previously provided in the below since you have indicated that you want to know the actual numbers involved and not just whether the item would be in stock or not based on the program/code written to provide that information (zen_check_stock).
Now, I note that here in the "shipping" page you are trying to assign/capture the current stock status. I don't know if the above is a one time only check or will be called again just before closing out the order during the order generation process. But there is a stock check evolution performed in checkout_confirmation processing to try to prevent an individual from checking out with product that have "just" been purchased by someone else. Further though, the session variables set here could become out-of-date if the purchase is not pushed through "quickly" and someone else purchases those items.Code:// Variable holds information about the products in the order
$this->_products = $_SESSION['cart']->get_products();
$_SESSION['cart']->shopping_stock = 1;
$inStock = 0;
$outStock = 0;
$_SESSION['cart']->in_stock_products = [];
$_SESSION['cart']->out_stock_products = [];
foreach ($this->_products as $product) {
$pid = $product["id"];
$qty = $product["quantity"];
/*$product_query = "select products_quantity
from " . TABLE_PRODUCTS . "
where products_id = '" . (int)$pid . "'";
$product = $db->Execute($product_query);
$quantity = $product->fields["products_quantity"]; */
$attributes = null;
if (isset($product['attributes'])) {
$attributes = $product['attributes'];
}
$quantityAttrib = zen_get_products_stock($products_id, $attributes);
$quantityProd = zen_get_products_stock($products_id);
/* Do whatever is necessary to mark product as in stock here in place of this comment block and then below take action if it is identified as out-of-stock */
$quantity = $qty;
if (isset($attributes) && $quantityAttrib <= 0) {
/* out-of-stock */
/* This if block says that if there are attributes associated with the product (assuming all of the appropriate attributes have been provided)
and those attributes have made it such that there are no attribute related product then the product is considered out-of-stock
regardless of the quantity of the original product.
*/
$quantity = $quantityAttrib;
} else if (!isset($attributes) && $quantityProd <= 0) {
/* out-of-stock */
/* This block identifies that the product is out-of-stock based on not having attributes and the quantity available associated is out-of-stock.*/
$quantity = $quantityProd;
}
if ($quantity < $qty){
$_SESSION['cart']->shopping_stock = 2;
array_push($_SESSION['cart']->out_stock_products,(int)$pid);
$outStock = 1;
}else{
$_SESSION['cart']->shopping_stock = 1;
array_push($_SESSION['cart']->in_stock_products,(int)$pid);
$inStock = 1;
}
}
if($outStock == 1 && $inStock == 1 && count($this->_products) > 0){
$_SESSION['cart']->shopping_stock=3;
}
Thank you, u already know you are a coding genius, LOL
one more thing, when products are not in stock a banner in reds tells the customer this, but banner doesnt show with attributes out of stock
im sorry code did not work, i have a product attribute in cart with 0 Quantity, but product has 10000 quantity and it istrying to ship it as stock, should ship as a special order,(from Vendor)
Product in question https://jnsflooringandsupplies.com/i...860adc5a9a58d1
i disabled nonstock method from showing in shopping cart, i put a #1 in front of stock method title to know the different methods, there is a third shipping called stock an nonstock, when stock and nonstock are in cart.
I just was able to add a "special order" product to the cart and was provided a notification that there was special ordering required (when viewing shipping options from the shopping cart page), I added an instock product and had the same options overall, then removed the special order product and was provided a different series of shipping options. Don't recall which "special order" product I selected, but from my perspective and limited knowledge of the site, it seemed like *something* was handled correctly.
Regarding this "message", for some reason I'm not seeing where/what generates the one for the base product... seems like for me to recreate it in one of my test sites that I may need to know what the settings for the site are regarding stock control... I can recall that there were at one time some different "messages" made available on the shopping cart page, but then in later versions some things changed... I still have some older carts setup and could recreate the message for sba product if I could find out what created it for the base product.Quote:
Originally Posted by jimmie
this is the define file /var/www/clients/client1/web4/web/includes/languages/english/shopping_cart.php
Line #43 : define('OUT_OF_STOCK_CAN_CHECKOUT', 'Products marked with ' . STOCK_MARK_PRODUCT_OUT_OF_STOCK . ' Can be DropShipped.<br />Items in your Cart that are Special Ordered can be DropShipped from are Distributor to you.(Guaranteed Delivery 1-7 Business Days)<br />(Please Note, if you choose Our Standard Shipping Methods and your cart contains Stock and Non-Stock items we will wait until all Items become Available. Usually within 2-14 Days)<br />If there is an exception with your Order you are Guaranteed Notification Within (1) Business Day.');
i have to two shipping modules activated standard shipping and vendor shipping, you should not see same method, stock vs nonstock. stock 1-2 days shipping, nonstock 7 - 14 days, i put a #1 in title of vendor shipping when all stock in cart, and a # 2 in nonstock when all nonstock in cart, #2 nevers shows, also when looking at sono product, hit listing goto sono tile, has a Red light (NonStock item), i didnt add attributes to that yetQuote:
Originally Posted by mc12345678
So I removed everything and installed it all back for a clean slate.
Anytime I add a quantity on the SBA page I get a msg at the top I get "Update failed" but looks like it took it.
I added two attributes, one to pick type of vinyl and the second to pick color.
I feel it is working backwards now. If I list a product in the zc_products_with_attributes_stock_attributes_non_stock` it shows that it is in stock. The items that are out of stock no longer show in the drop down as out of stock.
In the update failed message there should be some information related to what failed or how it failed. It is likely something simple, but there isn't a "update kind of completed" setting. :)Quote:
Originally Posted by cubmanky
As for the display being different, that's back to individual settings of what should be displayed related to stock items. Not everyone wants to have their "out-of-stock" items displayed.
Ohhh. Wait, the update failed message on modifying product, yes, there were some changes made to processing which is causing that message to appear. I've been working on the background code to provide the proper display. No its not as simple as just "always" forcing the message. It currently is likely to identify it failed when it actually succeeded. I haven't seen it identify success when it actually failed.
In otherwords it's more likely a false failure.
Attachment 18083
My biggest question now is why is the non stock working backwards. Items I place in non stock is only showing as the only items that are in stock
Two things. Since you are using two attributes for one product, now also need to consider the setting for dynamic dropdowns (separate configuration menu). The other thing regarding display of quantities depends on how the variants are defined. If you are using two attributes on a product then either the two attributes need to be defined as a pair and an individual quantity assigned to that pair or each attribute individually with quantity assigned to the individual attributes. The availability will be determined by the lowest number of the combination attempting to identify a combination by mixing the attributes together first and if none found then by individual attribute.Quote:
Originally Posted by cubmanky
As to the non-stock items, that table and it's usage is to allow items to be considered against a product that is tracked by stock where those items may not necessarily be a stock related item. Ie. A gift bag, to include a receipt or not, to be contacted about the product in the future, to put a cherry on top, etc... it's different than how it is desired to work here, but that's no matter, it is intended to follow the same thought: allow the purchase of the product with this/these attributes selected even though there is not a specific stock quantity assigned.
Hi all. I have an issue with the SBA add-on after upgrade to MySQL 5.7.24.
PHP Fatal error: 1140:In aggregated query without GROUP BY, expression #1 of SELECT list contains nonaggregated column 'freedomh_zencart.pwas.quantity'; this is incompatible with sql_mode=only_full_group_by :: select distinct pwas.quantity as quantity, count(distinct pwasans.attribute_type) as pwasans_quantity from products_with_attributes_stock pwas, products_with_attributes_stock_attributes_non_stock pwasans
This SELECT is in file /public_html/includes/classes/pad_sba_sequenced_dropdowns.php. It is quite a complicated looking SQL statement (for me anyway) with a number of OR statements. I'm assuming I need to add a GROUP BY statement in this SQL Statement, but not sure where. The other option would be to update SQL_MODE and remove the ONLY_FULL_GROUP_BY setting, but doesn't look like the correct thing to do here.
Any ideas how to correct or make this SELECT statement work with MySQL 5.7.24?
I'm running Zen Cart 1.5.5f, Database Patch Level: 1.5.5. Everything else seems find except when you hit the product Detail Screen and it hits this code.
Thanks for any pointers.
Chris
SQL as follows:
From file /public_html/includes/classes/pad_sba_sequenced_dropdowns.php
PHP Code:$attribute_stock_query = "select distinct pwas.quantity as quantity, count(distinct pwasans.attribute_type) as pwasans_quantity from " . TABLE_PRODUCTS_WITH_ATTRIBUTES_STOCK . " pwas, " . TABLE_PRODUCTS_WITH_ATTRIBUTES_STOCK_ATTRIBUTES_NON_STOCK . " pwasans
where pwasans.attribute_type = :products_options:
and pwasans.attribute_type_source_id = :products_id:
AND pwasans.attribute_type_id = (
SELECT pa.options_id FROM " . TABLE_PRODUCTS_ATTRIBUTES . " pa
WHERE pa.products_id = :products_id:
AND pa.options_values_id = :options_values_id:)
OR (
pwasans.attribute_type = :products_values:
AND pwasans.attribute_type_source_id = :products_id:
AND pwasans.attribute_type_id = :options_values_id:
" . /*(SELECT pa.options_values_id FROM " . TABLE_PRODUCTS_ATTRIBUTES . " pa
WHERE pa.products_attributes_id = :check_attribute_id:) */ "
)
OR (
pwasans.attribute_type = :values:
AND pwasans.attribute_type_source_id = 0
AND pwasans.attribute_type_id = :options_values_id:
AND pwasans.attribute_type_id = (SELECT pa.options_values_id FROM " . TABLE_PRODUCTS_ATTRIBUTES . " pa
WHERE pa.products_id = :products_id:
AND pa.options_values_id = :options_values_id:)
" . /*(SELECT pa.options_values_id FROM " . TABLE_PRODUCTS_ATTRIBUTES . " pa
WHERE pa.products_attributes_id = :check_attribute_id:) */ "
)
OR (
pwasans.attribute_type = :options:
AND pwasans.attribute_type_source_id = 0
AND pwasans.attribute_type_id = :options_values_id:
AND pwasans.attribute_type_id = (SELECT pa.options_id FROM " . TABLE_PRODUCTS_ATTRIBUTES . " pa
WHERE pa.products_id = :products_id:
AND pa.options_values_id = :options_values_id:)
" . /*(SELECT pa.options_values_id FROM " . TABLE_PRODUCTS_ATTRIBUTES . " pa
WHERE pa.products_attributes_id = :check_attribute_id:) */ "
)
OR pwas.products_id = :products_id:
" . (STOCK_ALLOW_CHECKOUT !== 'false'
? ""
: "AND pwas.quantity > 0 ") . "
AND pwas.stock_attributes
like (SELECT products_attributes_id from " . TABLE_PRODUCTS_ATTRIBUTES . "
WHERE products_id = :products_id:
and options_values_id = :options_values_id:)
OR pwas.products_id = :products_id: AND pwas.stock_attributes
like CONCAT((SELECT products_attributes_id from " . TABLE_PRODUCTS_ATTRIBUTES . "
WHERE products_id = :products_id:
and options_values_id = :options_values_id:),',%')
" . (STOCK_ALLOW_CHECKOUT !== 'false'
? ""
: "AND pwas.quantity > 0 ") . "
or pwas.products_id = :products_id:
AND pwas.stock_attributes
like CONCAT('%,',(SELECT products_attributes_id from " . TABLE_PRODUCTS_ATTRIBUTES . "
WHERE products_id = :products_id:
and options_values_id = :options_values_id:),',%')
" . (STOCK_ALLOW_CHECKOUT !== 'false'
? ""
: "AND pwas.quantity > 0 ") . "
or pwas.products_id = :products_id:
AND pwas.stock_attributes
like CONCAT('%,',(SELECT products_attributes_id from " . TABLE_PRODUCTS_ATTRIBUTES . "
WHERE products_id = :products_id:
and options_values_id = :options_values_id:))
" . (STOCK_ALLOW_CHECKOUT !== 'false'
? ""
: "AND pwas.quantity > 0 ");
While I don't have mysql 5.7 currently installed to test and haven't yet forced the same requirement as what set off this error, my initial test under 5.6.xx worked by changing line 267 from:Quote:
Originally Posted by gohealth
To:Code:: "AND pwas.quantity > 0 ");
I'll see about changing the server's settings, but wanted to report what looked like would work.Code:: "AND pwas.quantity > 0 ") . "
GROUP BY pwas.quantity";
I can confirm that setting the db mode to ONLY_FULL_GROUP_BY and incorporating the above modification fixes that issue. Please let me know if other such issues arise so that they may be addressed.Quote:
Originally Posted by mc12345678
As to the complexity of the query, well, some of that is because of how the SBA table has more information in a field than it should for trying to have a normalized database. There is a plan to split the data out a little more but is a bit of an overhaul of the underlying system.
Excellent! Yes, the above worked. There were also some problems when doing Admin creations of products and I'll need to test that as well. But thanks very much for the below. Really looking forward to this module becoming more permanent in future ZenCart releases... it always makes me nervous at upgrade and patching time!
Quote:
Originally Posted by mc12345678
So a new puzzle. I have some of my decals that are family. SO I need to use SBA for picking the vinyl color, but then non SBA attributes for picking family members. When I add that attribute they are coming in as SBA How do I keep them out of SBA.
I think I somewhat understand what is desired, but I don't understand what problem is being seen.Quote:
Originally Posted by cubmanky
What I understand is that there are two attributes with the product:
Stock dependent color
Non-stock dependent "person"
The attributes associated with the person should be added to the non-stock table.
The colors should be assigned stock quantities.
If not mistaken that is all that is needed to then support selecting each of the options and stock getting reduced for the vinyl/color. Right now, I very well could be mistaken.
Has this module been correctly updated for 1.5.6?
I downloaded it from github last week and the 1.5.6 folder contained files which whilst showing as 1.5.6, when running a 3 file comparison between stock 1.5.5, 1.5.6, and the SBA 1.5.6 file, some appeared to be 1.5.6 files with the 1.5.5 edits for SBA, completely removing changes made by the zc devs when creating 1.5.6.
Whislt I expect this will work, I don't know whether to use these files, or manually merge in the SBA edits to stock 1.5.6 files instead
When previously checked had been looking at the original incorporation of ZC 1.5.6 files. A lot had changed since then. Last week a separate branch was created to specifically incorporate the ZC 1.5.6 changes. That branch has been incorporated into the master fileset. There are far fewer merges necessary with the ZC 1.5.6 fileset. There may even be a few fewer merges necessary to the files.Quote:
Originally Posted by strelitzia
I still haven't checked through the installer program to validate that it will report a full successful install, but by that point in the code, the database should be up-to-date and should function. (famous last words, right?)
There have been some code updates as well to align more with the current ZC coding expectations (early return when a data condition is known, reduction of use of else statements where possible and it makes sense, additional strict control handling, etc...)
Thanks for the reply mc12345678. I'll grab the latest from your github account and take another look.
Doubt this will be a short story, but will try to keep it as short as possible.
When working in ZC versions 1.5.6 or 1.5.6a (so far), it is possible that there is a problem from the admin where a warning is thrown aboutAnother zenner and I were trying to track down the issue. Specifically it had been experienced when working with the attributes controller and I had come across it from another admin page. We each came up with a different solution. So I wanted to test both solutions as it applied to the attributes controller and specifically a product that had attribute images. On the demo site tested, I had SBA installed and ZC 1.5.6a (plus other currently proposed changes for revision b). Problem was that once I found a demo product that had attribute images (products_id=54), they were not displaying. Come to find out, although I had at one time corrected the issue, I had reintroduced it. I haven't gone through the detailed history to discover when it occurred, but I can say that before the below fix, if the option name's manager setting of displaying the option's image is set to other than 1 or 2 that there is a problem for product not controlled by SBA.Code:trim() expects parameter 1 to be string, object given in YOUR_ADMIN/includes/functions/general.php on line 441
I have updated the observer class with the following git commit to allow attribute images to be displayed for all option name settings of all product and controlled as "hidden" with main image swap for just SBA product. The hidden aspect is not limited to just the SBA options that are set to: 'SBA Select List (Dropdown) Basic' where the swap feature is made available.
Anyways, the patch for this issue is available at: https://github.com/mc12345678/Stock_...fc2e56a863263c
i have been trying to install this on a new website (7 times now) and it always end the same, products attributes names turns out like this
i am using a demo product
2 attributes
suppose to be
premium
deluxe
instead i get this
Out of Stock :
Out of Stock: Out of Stock
if i add another attribute name then it turns out like this[
Out of Stock :
Out of Stock: Out of Stock
Out of Stock: Out of Stock: Out of Stock
Could you please provide more detail?Quote:
Originally Posted by jimmie
For starters, from where/what download link was the software obtained?
What version of Zen Cart?
Once installed, what are the settings for: configuration->Dynamic Dropdowns?
What are the settings for: configuration->Stock in particular those towards the end of the list.
what has been done to populate a product or does this issue occur without trying to do anything to populate it?
im using Stock_By_Attributes_Combined-master in zen version 1.51 from the github link, dynamic dropdown setting are defaulted to whatever they r set in installation.
i setup database with demo products,
stock settings
Attachment 18359
dynamic dropdowns
Attachment 18360
i am using the this product for testing
http://jnsflooringandsupplies.com/WO...&products_id=2
Ok, so there are a few settings in both areas that are not defaulted, but they don't appear as if they would cause a stock availability issue.
In mentioning the link above, I went to it just a few minutes ago where I only saw one attribute assigned to it. By having only one attribute, then the display option name type assigned to the attribute would be the one used to attempt to display the availability of stock. The attribute (model) appears to be of the default dropdown or select option name type. Type add-to-cart button at the top of the screen doesn't seem to complete the add-to-cart action where it tries to add the 200 square feet that I have estimated needing to complete the "whatever" it is calculating.
One thing of importance in this, javascript is likely being used to display information about availability of product. To properly respond/access the information the page should pass html validation. While in this case the 29 problems identified at the time of review at this link: https://validator.w3.org/check?uri=http%3A%2F%2Fjnsflooringandsupplies.com%2FWORKINPROGRESS%2Findex.php%3 Fmain_page%3Dproduct_info%26cPath%3D1_4%26products_id%3D2&charset=(detect+automa tically)&doctype=Inline&group=0 don't appear to directly affect the availability area of the plugin, they well could affect javascript operation and therefore cause an out-of-stock condition just because.
So I'm not sure what is going on or how the issue is being caused.
sorry been working on site but can change back so u can see
changed back and deactivated calculator, i believe some of the errors of from attributes not having a name
Umm. Okay, so before I saw this message I was going to say that it seems like there may be something with the added dropdown menu and perhaps either a recent change or something related to using single attributes. But then there is the statement about the option name being empty... could you further elaborate? Also, are you also seeing an issue if there are two or more option names assigned to a product and the product populated with stock?Quote:
Originally Posted by jimmie
What does the stock screen look like for the product sample identified above? Ie. The variant(s) and quantities assigned?
some of the errors from w3c i believe are from the Out of stock name instead of name set in option value manager, the other version designed for 1.51 works, wanted this 1 for the picture changing and to show custom id on product page
Attachment 18361Attachment 18362
this should be my last mod b4 doing front end
I'm really confused.Quote:
Originally Posted by jimmie
The last mod to a ZC 1.5.1 site before doing what to the front end? Why is a site that is operating on 7+ year old software being worked on in this way?
As to the validation errors? As you may have noticed, those were identified before changing the site to support showing what was going on with everything being identified as out-of-stock...
I do see that there is some other software that has modified the admin configuration layout, I believe it is a numinix product though I temporarily have forgotten what it's called. I don't (yet) know if it possibly has something to do with what is being seen, though I know I made a change recently to try to ensure that attribute images were properly displayed for all situations that may have caused part of this. Still reviewing some other things.
@Jimmie,
Found and fixed the issue...
In earlier versions of ZC, notifiers could only pass an array that could not be modified. Fortunately there was enough data otherwise
made available for the most part that a global variable could then also be used to pull/handle the necessary data.
Unfortunately at some point when the SBA simple select list was incorporated for use on pre ZC 1.5.3 versions, the incorrect global variable was used/entered (one that technically didn't exist). This caused the "empty" names to be present and the lack of stock to be considered as well as a number of other issues.
Anyways, this commit: https://github.com/mc12345678/Stock_...8764aa804cde20
fixes the issue for pre-ZC 1.5.3 users and has been incorporated into the master thread.
Thank you for reporting the issue, it was not easy to find someone that still had ZC 1.5.1 running to where the issue could be troubleshot, but I was able to do so.
havent looked at this thread for an answer in a while , but i reinstalled this module and it is working, picture changing on select too. but when add an attribute to cart i do not see a customid, nor when on product page do i see any message that is is not in stock
also i stayed with 1.51 because i know all these mods worked on this version.
Well I'm approaching this bass ackwards, but staying with 1.5.1 because of what a plugin seems to do is (and forgive me) a completely wrong reason... as always when attempting to obtain help, information is needed to be provided. Starters: source of the code installed (uri)?Quote:
Originally Posted by jimmie
Depending on that answer, would follow up with are you using default settings? What is the type of selector for the option name(s) where this is expected to show stock related information? What are the variant quantities and what quantity of stock is applied to the base product?
What are the settings related to sales of product when the product is out of stock? (configuration->stock)
If you look at the installation screen that is created in the configuration menu, what script option may appear to provide the desired visualization?
i didnt want to install newest zen version to find out not all my mods will work in the newer version.
anyway here is a product
https://jnsflooringandsupplies.com/W...9848c951be1939
when i change from on for multiple attribute only to any other setting the message shows up on screen but no popup1
only thing i did was install go to option name manage and put in on sba tracked and add variant to product. stock settings. same as previous pictures
Have seen the images above and gone back to try to review previous images. A few questions asked don't seem to be answered. If I missed the answer, I apologize.Quote:
Originally Posted by jimmie
Settings in configuration->stock
Quantity applicable to the variant(s) in question and separately the quantity of the base product (ie. Quantity in the product information page in admin which is also reflected in the products with attributes screen. That is found on the row that provides the product name and products_model.)
Then another question that doesn't seem to be answered (again, I likely could be wrong) is how many option names are being used with the product in question? (though having asked that, I went to the link which for those interested indicates one option name. This means that considering the settings provided for dynamic dropdowns in the images above that the SBA simple dropdown is the code area to be applied and responsible for display of information.) from there I collected this image, so trying now to determine what specific issue is in question right now?
Well, sorry, appears I would exceed my image quota by attaching. At any rate, it was an example of a selection stating that the selection was out-of-stock and showed the customid in parentheses.
sorry had to run off this morning didnt finish uploading
Attachment 18375Attachment 18376Attachment 18377
when product is added to cart and you view cart i do not see custom id nor do i see regular model number
same product on live site with sba 1.53, https://jnsflooringandsupplies.com/i...ducts_id=22164 add to cart, view cart and custom id shows.
need to try and add custom id also to ajax add to cart
Another set of code missing in the update section of the observer class (includes/classes/observers/class.products_with_attributes_stock.php) needed to fully support ZC 1.5.1 without modifying other files. (in the past includes/modules/pages/shopping_cart/header_php.php had been modified to support the plugin. Apparently the modifications were removed without enabling the method for ZC 1.5.1 that is operational in ZC 1.5.3 and above.)
Will be uploading the modification to GitHub as soon as I can.Code:if ($notifier == 'NOTIFY_HEADER_END_SHOPPING_CART') {
$this->updateNotifyHeaderEndShoppingCart($callingClass, $notifier, $paramsArray);
} //endif NOTIFY_HEADER_END_SHOPPING_CART
this fixed the shopping cart page but not the checkout shipping still cant see custom id nor model # on checkout comfirmation
does not show in customers invoice or customer account info
Quote:
Originally Posted by jimmie
Does that cover all of the areas in ZC 1.5.1 where you expected to see the customid, but didn't see it? It is difficult these days to test for such old software where the program works in the newer versions taking advantage of the capability of the newer versions that didn't exist back then.Quote:
Originally Posted by jimmie
Quote:
Originally Posted by jimmie
Does that cover all of the areas in ZC 1.5.1 where you expected to see the customid, but didn't see it? It is difficult these days to test for such old software where the program works in the newer versions taking advantage of the capability of the newer versions that didn't exist back then.Quote:
Originally Posted by jimmie
yes, but customer doesnt see it in their order or checkout shipping and no popup when out of stock, also what about sending custom id to payment module like paypal.
Attachment 18384
I have a product with two attribute options and each option has two values. I have a different custom id for each of the four option-value pairs. I expect one of these four custom id's will be displayed in the various places that custom id is displayed, but I'm seeing two custom ids separated by a comma. Should there be only one custom id displayed? Examining $order->products[$i][attributes][0][customid] in admin/packingslip.php shows two custom ids for the selected option, separated by a comma. $order->products[$i][attributes][1][customid] is the same. $order->products[$i][customid] shows [type] is "single", and [value] is the same two custom ids as before. Seems to me that [type] should be "multi". Should it be "multi" and is it set during attribute entry? If so, where and how? Should [attributes][0][customid] be the single customid corresponding to first option-value pair? Same for [attributes][1][customid] except for the second option-value pair? Finally, what should be entered in the Unique Combo box on the Admin Products with Attributes Stock page? It is currently blank. I have recently upgraded SBA from v1.5.3 to SBA-Combined master from GitHub, downloaded Feb 1, 2019. Products with a single option and multiple values displays custom id's as expected.
Thanks for a great add-on and your support in the past.
ZCv1.5.6a, PHP 7.1
@Dave224,
Good questions and thank you for much of the information provided. The key to the single vs. multiple customid aspect is how are the variants setup? From what has been provided both in the "configuration" and the results appears to indicate that every option value is listed on its own. Meaning that there is not a grouping such as option name 1's option value 1 with option name 2's option value 3 (really the first option value of option name 2, but calling it 3 for clarity).
I say this, because, 1) the same customid is not duplicated (x, x) and that there are two customid's provided (one for each option value selected which is two based on two option names with the product.)
Now why are there two array values? Well, each attribute of the product is stored in its own record. There are two attributes to the product, so two records. Further, the customid associated with the purchase, if I remember correctly, is stored with each attribute. Now I thought I stored each uniquely but then based on the previous determination output the customid as combined and did it this way so that the display could be modified if so desired (combine into one long customid if desired, separate out into individual, etc...), but unfortunately at the moment I'd have to review the code again more to accurately report that aspect. That review also depends on the answer to my previous posed question about the variant arrangement.
mc12345678,
On the Admin Products with Attributes Stock page, each row in the variant column consists of two lines.
Variant 1:
line 1: "option name 1: option 1 - value 1"
line 2: "option name 2: option 2 - value 1"
Variant 2:
line 1: "option name 1: option 1 - value 1"
line 2: "option name 2: option 2 - value 2"
Variant 3:
line 1: "option name 1: option 1 - value 2"
line 2: "option name 2: option 2 - value 1"
Variant 4:
line 1: "option name 1: option 1 - value 2"
line 2: "option name 2: option 2 - value 2"
So I think they are grouped. Does that answer your question on how the variants are set up?
Also, please note that the customid data reported in the last post in the three locations are identical, consisting of the custom ids for variant 1 and variant 2 separated by a comma. The purchased product was variant 1.
Dave
Ok, yeah, that gives me enough to narrow it down. I do see that there is a minor difference in the function code between the admin and catalog sides that might account for this result. I also want to take a look at the added database table related to the transaction to see if the code should be using that instead of the current process.
I also understand much clearer now about the setup, the expectations, and the results. (I have/had the same expectation but apparently didn't get the result(s)).
Your note about differences in function code between catalog and admin prompted me to look at customid on the catalog side. I've been working primarily on the admin side. First let me explain that the product attribute option 1 has three values, not two. I used only two in my posts to make it simpler to explain. With that in mind, there are now four customids displayed on the catalog side and admin side. One corresponds to the purchased item (both option-value pairs match what is purchased). For the other three, only one of the two option-value pairs match what was purchased.
To explain a little better, I introduce the following notation involving two characters, say "ax". The first character represents the value of the first option which can have one of three values. So the first letter can be a, b, or c. The second character represents the value of the second option which can have one of two values. So the second character can be x or y. What was purchased was ax. The customids displayed are ax, bx, cx, and ay. Note that the first customid corresponds to what was purchased, and other three have one letter that is present in the purchased item.
This behavior was for a new purchase made today. Four customids were displayed on the catalog and admin side. An order made several days ago only shows two customids. I'm not sure why the difference, but must be related to final code changes I made during the upgrade to zc156a.
I assume that only the customid of the purchased item should be displayed; at least that is what I want.
Hope this post provides more clues.
Dave
mc12345678,
It seems to me that the code is designed to display multiple custom ids for some reason, and at least in the admin, display them next to the attributes. I need the customid on only the packing slip to assist the packer find the correct item to pack. It's really not for the customer, so I normally have the customid display turned off. I also want the single customid displayed next to the product name, not down with the attributes. So I think I'll go with direct queries of the database. I don't want to change what works for other people. I'll let you know how I make out with this approach.
Thanks again for a great add-on and your terrific support.
Dave
Looking at the differences in the code, how/where the code is used, and the report that the catalog side works correctly but the admin side does not, the admin/includes/classes/observers/class.products_with_attributes_stock.php needs a little modification:
Lines 410-411 need to be modified from:
to:Code:if (/*$value['option'] == $orders_products_sba_customid->fields['products_options_id'] &&*/ $value['value_id'] == $orders_products_sba_customid->fields['products_options_values_id']) {
(hopefully there are not a bunch of hashtags in the above pasted content. Apologies if there is.)Code:if ($value['option_id'] == $orders_products_sba_customid->fields['products_options_id']
&& $value['value_id'] == $orders_products_sba_customid->fields['products_options_values_id']) {
To explain a little about the various placement of the customid and possibilities, each attribute could have its own customid if listed independently like if a specific product was an option from a dropdown, or like used as described, the combination of attributes identifies a specific product where that has its own customid. The code supports creating variations of this.
As to the "final" placement, well that's up to where you want it. I went with placing it near the model_number if it is its own content, or I believe also included the ability to replace the model_number if that is so desired. (If that feature isn't present, it was a design consideration at least.)
Move the "echo" to where you want it, doesn't hurt anything. Remove it from the other "modified" files, it doesn't hurt anything there either. :) May add a feature to enable/disable from known files, but at the same time, absence of the template related code doesn't hurt operation...
Oh, and yes, the change described above was based on looking at the code and the reported issue of "crossing" over to a different variant.
Ugh...
Here's a screen shot of the shopping cart page where I ordered some items, most with the product that has multiple options and one with a single option, and one with no options. Of the three items with multiple options, one customid was correct, one item had 4 customids, and one had 2 customids. So the catalog side is not always correct.
And each of those product's with attributes have variants that are combined so that a pair or combination of 3 attributes has one customid?
If so, the source of that issue starts in the method zen_get_customid in includes/classes/class.products_with_attributes_class_stock.php
I think I found the issue in line 284, still need to test the other methods of working with product, but when I changed the line from:
To:Code:if ($customid->RecordCount() > 0) {
Then only one appropriate customid was displayed on the shopping cart page...Code:if ($customid->RecordCount() > 1) {
Although, the customid didn't replace the model number when that was set that way. Instead should be == 0 instead of > 1.Quote:
Originally Posted by mc12345678
Yes, the result puts the customid in two places on the catalog side then, but that still is customizable on the template and perhaps more so in the software with further input. Trying not to make a mess of settings though. :P
Yes, each variant consists of two attributes with a single customid. Option 1 (Scale) has three possible values; option 2 has two possible values. That's a total of six possible variants and each variant has a customid. What is perplexing to me is the different number of customid's displayed. That is, I ordered three of the six possible variants. One had the correct customid, another had two customids displayed, and another had four ids displayed.
I'll try your fix next.
With your two changes described in posts 3089 and 3091 incorporated in the code, the correct customid is displayed on the catalog side on the shopping cart page, checkout confirmation page and orders history page. :smile: But the correct customid is displayed twice on the orders history page. :(
The correct customid is displayed in the admin on the orders page (edit or details) and on the packing slip. No repeats like on the catalog side/orders history page. :D
I tried it for each of the six variants of the product with two options, and on products with single options.
On the orders history page, with the doubling of the customid. Am I correct that in the stock configuration settings that customid is set to replace the model number?Quote:
Originally Posted by Dave224
One thing I hadn't yet worked on was a consistent way of presenting the customid. In some cases it is shown separate from the attribute's, some places along with, etc... in the account history it is both the customid and the products model which when replaced means that it shows twice... I can't use the current settings to identify whether both should be shown or not because that could change, I'm a smidge reluctant to add a field in the database to capture the condition at the time of recording, but guess that may need to be the way to go for appropriate handling. Alternatively could check to see if the two are the same and if so, only present one, but perhaps someone has a reason for both customid and model number to be the same and want both to be displayed/available...
Or perhaps modify how the products_model is "replaced" by the customid...
Regardless, thank you for the feedback and identification that when I changed the method verification of a variable's state in this area that I made a mistake.
Yes, I had that setting set to "1". Both customids were the correct SBA ids. Rerunning with the setting set to "false", I still got a double customid, one is the correct SBA customid. The other is the model.Quote:
Originally Posted by mc12345678
BTW, I think you need to check the value of STOCK_SBA_DISPLAY_CUSTOM_ID in tpl_account_history_info_default.php. I changed line 44 to:
As I mentioned in an earlier post, I normally run with customid turned off. My intention is not display custom id on the catalog side or in the admin with the attributes, but use the replace model with customid feature for admin orders-edit, invoice and packing slip pages to assist the packer. Also, I don't display model anywhere on the catalog side.Code:<td class="accountProductDisplay"><?php echo $order->products[$i]['name'] . ' ' . ((STOCK_SBA_DISPLAY_CUSTOMID == 'true') ? $customid[$i] : ''); // MOD for "Stock by Attributes" 1 of 1
Can anyone explain why some of my Product_Attribute_Combo field records in Products_With_Attributes_Stock is Null on some records and Product_Id-Stock_Attributes ea 1025-2618,2622 on others?
Just want to understand if the field should be consistent for all records?
It is my understanding that at one point, that field was going to be used for some sort of cross reference/lookup operation; however, there does not appear to be anywhere in the code that retrieves that information. It just builds it on some initial variant insertion. The field doesn't appear to be needed; however, that aspect as introduced I believe by potteryhouse was not significantly discussed to explain the reasoning behind it. Mind you, its presence did help identify how to manage some of the data to further expand on the work done, but unless a functional need is identified, then might expect that this field and the code that accesses it will be removed in the future.Quote:
Originally Posted by jodean
Hello All,
Just wondering if there are plans to adapt this module to work in 1.5.6, or has that already happened and I just can't find the new version?
Thank You,
John
Have you looked at: https://github.com/mc12345678/Stock_...butes_CombinedQuote:
Originally Posted by bumba000
I haven't received any negative reports of its operation in ZC 1.5.6, though note that where a file is being merged with core files, that it is the changes supporting the plugin that are important and that the provided file may not be 100% up-to-date with the associated 1.5.6 version. That said, nothing has been seen that would directly affect the SBA code within that/those files.