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

mc12345678,

I have been following that guide, but I think I've made some errors along the way that will require starting over. Thanks for your insight. Here I go again....

fbroz:

mc12345678,

I have been following that guide, but I think I've made some errors along the way that will require starting over. Thanks for your insight. Here I go again....

Not sure which guide has been followed, but if it is just database related things to be "restarted" if you run the install/upgrade script again, the table of variants will remain but the settings added by SBA will be restored to their default. If it is further desired to clear the variants table, then there is a script for that as well..

Hi mc12345678,

I started with a fresh copy of zc 1.5.5e and started applying my modifications and it is going a little better this time. I wonder if you have any thoughts on a performance issue I am seeing when loading pages with fairly complicated attributes. This product for example seems to stall for about 10 seconds when creating the dynamic dropdowns:

https://www.tokyopenshop.com/shop2/index.php?main_page=product_info&cPath=11&products_id=18

Products with less complicated attributes load much more quickly:

https://www.tokyopenshop.com/shop2/index.php?main_page=product_info&cPath=11&products_id=1278

Does this seem expected to you with complicated products? Maybe this is something I can improve on my web host with different MySQL tuning of some kind? Thanks in advance!

One thought I had on this... I am currently using a very old PHP version (5.2.17) for the benefit of the 1.3.8a installation on this server. Maybe when I can migrate to the 1.5.5e site and upgrade my PHP version that could have an effect?

Also when I look in Tools -> Server/Version Info I do see: "MySQL Slow Query Log Status: On" and "MySQL Slow Query Log File: web-slow.log" but I can't seem to find that web-slow.log file anywhere.

Well, for one thing, though the fileset has now been updated to set $backorder = false; as described a few posts back, the fileset on your server still has it as true.

You mentioned that when changing that setting there was a difference in operation.

Otherwise since these last couple of posts I haven't been able to get to a computer to observe what is available to identify any slowdowns. I do see that part of the "price" area is affected for the one example, but I don't know what all else is going on during that period especially as I have also been presented with a mixed content message when accessing the pages. It appears that there is one script that has a src="http://...." instead of beginning with just a double forward slash.

Otherwise, there may be a way to split the single query up and make things faster, though haven't really looked into that as still have not had feedback on the feature's functionality to then warrant further review/investigation into improvement. Ie. If it doesn't provide what is sought, why spend time making changes? If it does and it's slow, then ok, fine improvement needed...

As to the log file, it seems as if it should be logged into your directory structure, but I would suggest speaking to your Web host about either where it is currently being stored, how the path should be modified to make it accessible/easier to access, and/or how to access it.

Thanks mc12345678,

mc12345678:

Well, for one thing, though the fileset has now been updated to set $backorder = false; as described a few posts back, the fileset on your server still has it as true.

You mentioned that when changing that setting there was a difference in operation.

Thanks for the reminder, I have re-applied that change, and there may be a minor improvement there, hard to tell.

mc12345678:

Otherwise since these last couple of posts I haven't been able to get to a computer to observe what is available to identify any slowdowns. I do see that part of the "price" area is affected for the one example, but I don't know what all else is going on during that period especially as I have also been presented with a mixed content message when accessing the pages. It appears that there is one script that has a src="http://...." instead of beginning with just a double forward slash.

Thanks for that comment on the error, my template was calling that minimized jquery file and it seems to work just as well with an https:// call, so that seems to be corrected for the moment.

mc12345678:

Otherwise, there may be a way to split the single query up and make things faster, though haven't really looked into that as still have not had feedback on the feature's functionality to then warrant further review/investigation into improvement. Ie. If it doesn't provide what is sought, why spend time making changes? If it does and it's slow, then ok, fine improvement needed...

Regarding this feedback, I can share my personal thoughts at this point: I do see that it works correctly to populate the dropdowns with the correct attribute option names and values and allows customers to add the correct products to the cart. That is obviously the most important thing, and for me, the older sequenced_dropdowns in zc1.5.5e does not do this (no option values appear in the list, although the list seems to be the correct length). The "out of stock" or "backordered" functionality doesn't quite fit my purposes. In a sequenced list like mine, the option values from the first list in the sequence should not say "out of stock" unless all of the corresponding option values in the second list are out of stock. As it is now, all the option values from the first list (.25mm, .3mm, etc.) say they are out of stock. For my uses, only the second list needs to show out of stock notifications, really.

mc12345678:

As to the log file, it seems as if it should be logged into your directory structure, but I would suggest speaking to your Web host about either where it is currently being stored, how the path should be modified to make it accessible/easier to access, and/or how to access it.

I did some more digging into this, and I think the log file does not exist because the slow query is not being triggered at the current threshold. I can look into this more in the future possibly.

mc12345678,

I'm not sure if this thread is the right place for this, if not I can remove the post.

As a long time user or SBA, I modified the "Products Purchased" report to allow store owners to find out which attributes of a product (or combination of attributes) is selling well or needs to be restocked. I have attached the file here for your consideration and possible inclusion into the SBA project if you think it is useful. I am not a professional programmer and there are likely many improvements that can be made to this report, but here it is in a state that works with my zc 1.5.5e.

Attachment #17212

fbroz:

mc12345678,

I'm not sure if this thread is the right place for this, if not I can remove the post.

As a long time user or SBA, I modified the "Products Purchased" report to allow store owners to find out which attributes of a product (or combination of attributes) is selling well or needs to be restocked. I have attached the file here for your consideration and possible inclusion into the SBA project if you think it is useful. I am not a professional programmer and there are likely many improvements that can be made to this report, but here it is in a state that works with my zc 1.5.5e.

Attachment #17212

Haven't looked at it yet, but that concept is one additional thing to be added to this. That information will be useful to users of the software. Thank you, whether incorporated as is or with other modifications, let me know if credit should be given to not only you but whom else for its inclusion.

fbroz:

Thanks mc12345678,

Thanks for the reminder, I have re-applied that change, and there may be a minor improvement there, hard to tell.

Thanks for that comment on the error, my template was calling that minimized jquery file and it seems to work just as well with an https:// call, so that seems to be corrected for the moment.

Regarding this feedback, I can share my personal thoughts at this point: I do see that it works correctly to populate the dropdowns with the correct attribute option names and values and allows customers to add the correct products to the cart. That is obviously the most important thing, and for me, the older sequenced_dropdowns in zc1.5.5e does not do this (no option values appear in the list, although the list seems to be the correct length). The "out of stock" or "backordered" functionality doesn't quite fit my purposes. In a sequenced list like mine, the option values from the first list in the sequence should not say "out of stock" unless all of the corresponding option values in the second list are out of stock. As it is now, all the option values from the first list (.25mm, .3mm, etc.) say they are out of stock. For my uses, only the second list needs to show out of stock notifications, really.

I did some more digging into this, and I think the log file does not exist because the slow query is not being triggered at the current threshold. I can look into this more in the future possibly.

It is intended that out-of-stock (when displayed) be shown at the earliest selection point where such selection would result in any further selection to also be out-of-stock.

That said and seeing the indication of out-of-stock being displayed in the first dropdown, this would be a factor of the entry of data for the variants associated. Could you please identify the variant "arrangement" and quantity for each selection combination as well as the total quantity of stock identified to the main product?

Then may discuss settings, but let's start there first.

mc12345678:

Haven't looked at it yet, but that concept is one additional thing to be added to this. That information will be useful to users of the software. Thank you, whether incorporated as is or with other modifications, let me know if credit should be given to not only you but whom else for its inclusion.

Thanks mc12345678,

This is my work, but I can already thing of some things that should be generalized (hardcoded order numbers, etc.) before it will be robust for others.

mc12345678:

It is intended that out-of-stock (when displayed) be shown at the earliest selection point where such selection would result in any further selection to also be out-of-stock.

That said and seeing the indication of out-of-stock being displayed in the first dropdown, this would be a factor of the entry of data for the variants associated. Could you please identify the variant "arrangement" and quantity for each selection combination as well as the total quantity of stock identified to the main product?

Then may discuss settings, but let's start there first.

I believe this report from SBA will have the info you are thinking of, if not, please let me know what I can clarify:
Attachment #17214

Hmmm. Those setting look correct to support.
What about the dynamic dropdown settings and stock configuration settings?
(please continue to remember to not include the admin directory path)

fbroz:

Thanks mc12345678,

Thanks for the reminder, I have re-applied that change, and there may be a minor improvement there, hard to tell.

Thanks for that comment on the error, my template was calling that minimized jquery file and it seems to work just as well with an https:// call, so that seems to be corrected for the moment.

Regarding this feedback, I can share my personal thoughts at this point: I do see that it works correctly to populate the dropdowns with the correct attribute option names and values and allows customers to add the correct products to the cart. That is obviously the most important thing, and for me, the older sequenced_dropdowns in zc1.5.5e does not do this (no option values appear in the list, although the list seems to be the correct length). The "out of stock" or "backordered" functionality doesn't quite fit my purposes. In a sequenced list like mine, the option values from the first list in the sequence should not say "out of stock" unless all of the corresponding option values in the second list are out of stock. As it is now, all the option values from the first list (.25mm, .3mm, etc.) say they are out of stock. For my uses, only the second list needs to show out of stock notifications, really.

I did some more digging into this, and I think the log file does not exist because the slow query is not being triggered at the current threshold. I can look into this more in the future possibly.
Something else about this "current" result doesn't seem right. As far as could tell from the previous install, after the $backorder variable was set to false, out-of-stock notifications were not improperly presented...

I had been able to duplicate the problem of incorrect display of backorder on my test site and when $backorder was set to false, all other display appeared to work properly. I expected the same with the install performed there. If that wasn't the case, then some other recent change (for improvement) needs to be undone or corrected. Would appreciate notification of such issue.

mc12345678:

Hmmm. Those setting look correct to support.
What about the dynamic dropdown settings and stock configuration settings?
(please continue to remember to not include the admin directory path)

Here are those configurations for your consideration.

mc12345678:

Something else about this "current" result doesn't seem right. As far as could tell from the previous install, after the $backorder variable was set to false, out-of-stock notifications were not improperly presented...

I had been able to duplicate the problem of incorrect display of backorder on my test site and when $backorder was set to false, all other display appeared to work properly. I expected the same with the install performed there. If that wasn't the case, then some other recent change (for improvement) needs to be undone or corrected. Would appreciate notification of such issue.

I double checked that I made the correct modification based on your previous instructions, and I think this was the same behavior I was seeing before. If you think it would be worth trying a fresh install with just SBA merged, I could give that a try.

Those look correct. Ok. I'm going to have to take a step back and see if not having something in the new table is causing the issue observed, and if so then I have a way forward. My test site has at least one attribute identified as not stock dependent. That may be enough to cause a difference in operation. I'll have to see and correct that one way or another.

fbroz:

I double checked that I made the correct modification based on your previous instructions, and I think this was the same behavior I was seeing before. If you think it would be worth trying a fresh install with just SBA merged, I could give that a try.

Actually, could you try this to see if it works?

In tools->install sql patches

Enter the following:

INSERT  INTO products_with_attributes_stock_attributes_non_stock  (attribute_type, attribute_type_id, attribute_type_source_id) VALUES  ('PV', 3, 1278);

This will make the option value 3 (pink) a non-stocked dependent option for product 1278. Suggest then looking at 1278 and another SBA product to see if "issue" "resolved".

mc12345678:

Actually, could you try this to see if it works?

In tools->install sql patches

Enter the following:

INSERT INTO products_with_attributes_stock_attributes_non_stock (attribute_type, attribute_type_id, attribute_type_source_id) VALUES ('PV', 3, 1278);

> 
> This will make the option value 3 (pink) a non-stocked dependent option for product 1278. Suggest then looking at 1278 and another SBA product to see if "issue" "resolved".

WOW!  I feel like I just watched david blaine make the statue of liberty disappear!

This resolves the issue, even for SBA products that don't have pink as an option value!  I don't understand how that works, but it does work in my use case.

fbroz:

WOW! I feel like I just watched david blaine make the statue of liberty disappear!

This resolves the issue, even for SBA products that don't have pink as an option value! I don't understand how that works, but it does work in my use case.

It's all because of how I mashed so much into the associated query. So either a "default" value will need to be added that has no stock effect on product, the query revised, or some additional logic to be sure that it all comes out like it should whether an option is stock dependent or not within the store.

Alright, could you try this to not affect your pink product but maybe offer continued operation like it is supposed to work?

update products_with_attributes_stock_attributes_non_stock  set attribute_type = 'TEST';

This should result in any/all entries in that table to be of a type outside the expected value(s) and help identify if it is a potential temporary fix or not and prevent overselling of product that are pink in that specific product. :)

mc12345678:

It's all because of how I mashed so much into the associated query. So either a "default" value will need to be added that has no stock effect on product, the query revised, or some additional logic to be sure that it all comes out like it should whether an option is stock dependent or not within the store.

Alright, could you try this to not affect your pink product but maybe offer continued operation like it is supposed to work?

update products_with_attributes_stock_attributes_non_stock set attribute_type = 'TEST';

> This should result in any/all entries in that table to be of a type outside the expected value(s) and help identify if it is a potential temporary fix or not and prevent overselling of product that are pink in that specific product. :)

I submitted this statement in the SQL Query Executor, and the products look good:

<https://www.tokyopenshop.com/shop2/gel-ink-pens-c-11/hitec-c-p-18.html>

Do I need to reverse the assignment of the pink option value to be a stock-dependent option for this test to be valid?