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

jimmie:

how to add customid to advanced search result
jimmie
For a default ZC store, be sure to have the file provided in the main fileset: includes/classes/observers/auto.advanced_search_categories_custom_id.php

Works for ZC 1.5.6 and expected to work for ZC 1.5.7. Otherwise will need to identify the version of ZC and changes that have been made to the search feature...

Hello there,
I am just wondering if I am able to make the following code excerpts changed somehow (using 1.57 zencart, php 7.3.22) as I get the following error logs:-

PHP Warning: count(): Parameter must be an array or an object that implements Countable in /chroot/home/gemtree/thegemtree.com/html/includes/templates/goodwin/templates/tpl_modules_attributes.php

for ($k = 0, $m = count($options_name); $k < $m; $k++) {
for($i=0, $j=count($options_name); $i<$j; $i++) {

they come at line 109 and 138. I have been looking up example codes to add to the line above, but they mention 'row' and think this might not be zencart compliant. Not sure if anybody has had any success?

HeathenMagic:

Hello there,
I am just wondering if I am able to make the following code excerpts changed somehow (using 1.57 zencart, php 7.3.22) as I get the following error logs:-

they come at line 109 and 138. I have been looking up example codes to add to the line above, but they mention 'row' and think this might not be zencart compliant. Not sure if anybody has had any success?
It would appear that the ZC 1.5.7 version of includes/modules/attributes.php is not being used in this environment or there is something that is modifying $options_name away from an empty array when a product with attributes is provided that doesn't have an $options_name value...

SBA has been modified to support ZC 1.5.7 by not requiring an associated includes/modules/YOUR_TEMPLATE/attributes.php override file allowing the use of the now "default" version of the attributes.php file (though there was a modification that was incorporated to the originally provided ZC 1.5.7 version here: https://github.com/zencart/zencart/pull/3738/files). Hmmm, thought it was also identified in the 1.5.7 bugs list, but I don't see it.

mc12345678:

It would appear that the ZC 1.5.7 version of includes/modules/attributes.php is not being used in this environment or there is something that is modifying $options_name away from an empty array when a product with attributes is provided that doesn't have an $options_name value...

SBA has been modified to support ZC 1.5.7 by not requiring an associated includes/modules/YOUR_TEMPLATE/attributes.php override file allowing the use of the now "default" version of the attributes.php file (though there was a modification that was incorporated to the originally provided ZC 1.5.7 version here: https://github.com/zencart/zencart/pull/3738/files). Hmmm, thought it was also identified in the 1.5.7 bugs list, but I don't see it.

I beg your pardon, I think during merge upgrade I assumed it was still part of the code for SBA and overlooked that it needed removing. I have put the 1.57 attributes.php file as you suggested. Sorry about that! I was looking to see how to remove my post or edit as it is my oversight, happy for the moderators to remove as necessary. Thanks for your help! Going through the debug logs to tidy up deprecated / php warnings is hard work! For me anyway ha

HeathenMagic:

I beg your pardon, I think during merge upgrade I assumed it was still part of the code for SBA and overlooked that it needed removing. I have put the 1.57 attributes.php file as you suggested. Sorry about that! I was looking to see how to remove my post or edit as it is my oversight, happy for the moderators to remove as necessary. Thanks for your help! Going through the debug logs to tidy up deprecated / php warnings is hard work! For me anyway ha

No worries. Also, I would imagine that the discussion would likely help others that go the same route. Instructions on how to install and/or upgrade would help prevent that type issue. Personally I find that the new attributes.php file covers a lot of new ground and offers a great deal of flexibility in responding to attribute type demands. DrByte did a lot of work to come up with the new revision.

Just an FYI, again, there is no longer a need for there to be an includes/modules/YOUR_TEMPLATE/attributes.php file at least for SBA.

That of course also depends on incorporating the other software associated with the plugin that has been updated to use that attributes.php as well as to still "work" with the older version. The issue raised though is inherent with the attributes.php file and more stringent "requirements" of php. Ie a lower version of php (without strict enforcement) would not have generated that type of warning which is one reason that the file was "ok" in the past. :)

Anyways, please be sure to evaluate the latest files for the module in relation to your upgrade/rebuild. Again, the includes and admin base directories support the basic operation of the software and then the folder for the associated Zen Cart version is setup to provide the file(s) necessary for that version of ZC. Because those files are effectively template override files, blank versions of removed files are not provided. Basically in an "upgrade" situation, if a file existed in a previous ZC version(s) folder and does not exist in the current/upgraded folder, then any modifications in the previous version do not need to be carried over to the new version... In some cases changes should be removed, in others a file could be removed. In all though as ZC versions go up, less template and/or core files have needed to be touched. More than likely jQuery could be used to remove many of the other file edits in support of adding items to "lists" of things. I'm not there yet though. :) I already have one (probably unnecessary) "trick" I have to undo in support of php 8... :/

mc12345678:

No worries. Also, I would imagine that the discussion would likely help others that go the same route. Instructions on how to install and/or upgrade would help prevent that type issue. Personally I find that the new attributes.php file covers a lot of new ground and offers a great deal of flexibility in responding to attribute type demands. DrByte did a lot of work to come up with the new revision.

Just an FYI, again, there is no longer a need for there to be an includes/modules/YOUR_TEMPLATE/attributes.php file at least for SBA.

That of course also depends on incorporating the other software associated with the plugin that has been updated to use that attributes.php as well as to still "work" with the older version. The issue raised though is inherent with the attributes.php file and more stringent "requirements" of php. Ie a lower version of php (without strict enforcement) would not have generated that type of warning which is one reason that the file was "ok" in the past. :)

Anyways, please be sure to evaluate the latest files for the module in relation to your upgrade/rebuild. Again, the includes and admin base directories support the basic operation of the software and then the folder for the associated Zen Cart version is setup to provide the file(s) necessary for that version of ZC. Because those files are effectively template override files, blank versions of removed files are not provided. Basically in an "upgrade" situation, if a file existed in a previous ZC version(s) folder and does not exist in the current/upgraded folder, then any modifications in the previous version do not need to be carried over to the new version... In some cases changes should be removed, in others a file could be removed. In all though as ZC versions go up, less template and/or core files have needed to be touched. More than likely jQuery could be used to remove many of the other file edits in support of adding items to "lists" of things. I'm not there yet though. :) I already have one (probably unnecessary) "trick" I have to undo in support of php 8... :/

Thanks for your reply. Yes I thought possibly it might help somebody else. I will remember that, and I will be a bit more thorough when updating in future.

Its sage advice you have given with to that regards. Gosh PHP 8 no doubt another lot of php warnings to come then haha :-)

HeathenMagic:

Thanks for your reply. Yes I thought possibly it might help somebody else. I will remember that, and I will be a bit more thorough when updating in future.

Its sage advice you have given with to that regards. Gosh PHP 8 no doubt another lot of php warnings to come then haha :-)
You're welcome, it is because of reports like this that either things can be made better or others can solve their similar problem or realize that they too can contribute to the solution(s). Thank you again for bringing it up and being patient/understanding with my replies.

Hello everyone.
I have a question.
I'm working on an art website, and I'm looking at replacing the SOLD OUT that appears next to the attribute, with a red dot instead.
I've tried adding an image in the defines, but it won't work.
I've tried changing the text SOLD OUT for just a simple '.' styling it as a class using CSS, but it won't work either.
Is there a way to do what I'm trying to accomplish without going above my very limited php knowledge?

Thank you in advance for any help you could provide.

mvstudio:

Hello everyone.
I have a question.
I'm working on an art website, and I'm looking at replacing the SOLD OUT that appears next to the attribute, with a red dot instead.
I've tried adding an image in the defines, but it won't work.
I've tried changing the text SOLD OUT for just a simple '.' styling it as a class using CSS, but it won't work either.
Is there a way to do what I'm trying to accomplish without going above my very limited php knowledge?

Thank you in advance for any help you could provide.
The ability to "style" the content adjacent to the attribute depends most on the type of attribute being used. For example, if the attribute type (controllable by admin->products->options name manager) is a dropdown or select type attribute, then unfortunately html prevents doing styling in that "simple" type selector. That would require a javascript type application to handle. If it is a radio button or checkbox, then things are different as those are more html friendly.

That said, a link always helps to see what is going on and possibly how to help. Can PM if not able to post in some cryptic way. :)

mc12345678:

The ability to "style" the content adjacent to the attribute depends most on the type of attribute being used. For example, if the attribute type (controllable by admin->products->options name manager) is a dropdown or select type attribute, then unfortunately html prevents doing styling in that "simple" type selector. That would require a javascript type application to handle. If it is a radio button or checkbox, then things are different as those are more html friendly.

That said, a link always helps to see what is going on and possibly how to help. Can PM if not able to post in some cryptic way. :)

Thank you for the reply! Forgot to mention the attribute in question is a dropdown menu. It's a shame that cannot be done with just simple CSS =(
The website is https://www.manuelavalenti.com. If you register an account I'll approve you right away. I just have it private for now as I'm working on it, and don't want to display the "we're working" page.

Question, if I decide to go the javascript route, would that entire dropdown be affected by say someone who has disabled java? Would it still be functional and perhaps instead display a "sold" text in place of a red dot?

Trying some other options, rather than complicating matters, I switched from dropdown attributes to checkboxes, which actually worked out better than I thought for my theme.

However the price is out of place in my design (mild OCDish) and I would like instead the red dot (sold) to be at the end on the other side of the price.

I tried moving things around on includes/classes/observers/class.products_with_attributes_stock.php which is the file I determined controlled the elements, but nothing I tried worked as I was expecting, so my question is, how/where/what would I need to edit on that file to accomplish this? And if not that file, which file would it be?

Thank you!!

mvstudio:

Thank you for the reply! Forgot to mention the attribute in question is a dropdown menu. It's a shame that cannot be done with just simple CSS =(
The website is https://www.manuelavalenti.com. If you register an account I'll approve you right away. I just have it private for now as I'm working on it, and don't want to display the "we're working" page.

Question, if I decide to go the javascript route, would that entire dropdown be affected by say someone who has disabled java? Would it still be functional and perhaps instead display a "sold" text in place of a red dot?

Good, that's the developer mindset to consider the effects of the change desired. The goal would be yes, present the desired information to support those that don't allow javascript and how it would look if it was supported. As of I think ZC 1.5.4 maybe 1.5.3, the attributes.php file included an html tag to encompass the entirety of the attribute option being displayed. This allows javascript to "takeover" that option name which allows the attribute to be displayed as desired.

Now as to the latest question, first one back... is this product truly available without selecting either of the two checkboxes? If it is not possible for the product to "exist" without selecting a checkbox, then a checkbox is not likely the correct method of making a selection. Further, could the product ever exist if two or all checkboxes are marked? Again, if the answer to that is a no, then checkboxes are likely also not the type of selection to offer.

My recommendation in those two cases would be to use a radio button option. Further, based on the information presented in the image of two options being provided with no default preselected would recommend adding a third option value that is marked as default and display only. Having this configuration would require the customer to actively make a selection to support giving notification to the customer when attempting to add the product to the cart that they... well, make a selection.

Whether that default selection be shown on screen or not is up to css control.

Now, to the topic of the OCD of display "style", what about what is presented is desired to be changed? If it is for the two (or more) options to be displayed more in a list than a horizontal grouping, that is controlled by css more than it is through the file referenced, but more information is needed to be able to advise. Some of that additional information may include the settings for dynamic dropdowns (admin->configuration->dynamic dropdowns) as those settings could have an effect that I am not expecting.

mc12345678:

Good, that's the developer mindset to consider the effects of the change desired. The goal would be yes, present the desired information to support those that don't allow javascript and how it would look if it was supported. As of I think ZC 1.5.4 maybe 1.5.3, the attributes.php file included an html tag to encompass the entirety of the attribute option being displayed. This allows javascript to "takeover" that option name which allows the attribute to be displayed as desired.

Now as to the latest question, first one back... is this product truly available without selecting either of the two checkboxes? If it is not possible for the product to "exist" without selecting a checkbox, then a checkbox is not likely the correct method of making a selection. Further, could the product ever exist if two or all checkboxes are marked? Again, if the answer to that is a no, then checkboxes are likely also not the type of selection to offer.

My recommendation in those two cases would be to use a radio button option. Further, based on the information presented in the image of two options being provided with no default preselected would recommend adding a third option value that is marked as default and display only. Having this configuration would require the customer to actively make a selection to support giving notification to the customer when attempting to add the product to the cart that they... well, make a selection.

Whether that default selection be shown on screen or not is up to css control.

Now, to the topic of the OCD of display "style", what about what is presented is desired to be changed? If it is for the two (or more) options to be displayed more in a list than a horizontal grouping, that is controlled by css more than it is through the file referenced, but more information is needed to be able to advise. Some of that additional information may include the settings for dynamic dropdowns (admin->configuration->dynamic dropdowns) as those settings could have an effect that I am not expecting.

Thank you much for the reply!

Good questions!

The product in question is just a sample and I forgot to add the preselected option when I created the attributes. But the final products will have the "original painting" option as pre-selected as the first option (if available) or the limited edition prints pre-selected in those instances where the original painting is sold.

In short, yes the product, which will be offered as original painting (1 unit) and limited edition print (several units typical 25-50 or more), can be purchased together in one go, if the customer desires, the reason why I decided to go for checkboxes instead of radio buttons. If I choose dropdown menus or radio buttons, customers wanting to add both options to the cart, would need to add them as two separate items in the cart, which isn't that big of a deal, but I thought checkboxes might give some flexibility. Perhaps I'm seeing this with the wrong pair of glasses? I have the tendency to use tools differently than the way they were intended to be used.

What I'm trying to accomplish in this case of the checkboxes, assuming I picked the right option, is move the "red dot" which marks the piece as sold, to the end or the right side of the price, as shown in the picture below.

I was able to pinpoint the line of code that displays the "sold" message which is controlled by the define PWA_OUT_OF_STOCK located on includes/classes/observers/class.products_with_attributes_stock.php at around line 368

        if (empty($products_options_DISPLAYONLY->fields['attributes_display_only'])) {
          $products_options_fields['products_options_values_name'] = $products_options_fields['products_options_values_name'] . PWA_OUT_OF_STOCK;

However I was unsuccessful at moving elements around to position the "sold" message, now displayed as a red dot, to the end. Again, I'm not good with php at all, I just play it by ear and through trial an error, tons of them. I'm only good at the design part and somehow manage for the most part to make things work the way I want them to.

These are the setting for the dynamic dropdowns as requested:

Thanks again for taking the time =)

mvstudio:

Thank you much for the reply!

Good questions!

The product in question is just a sample and I forgot to add the preselected option when I created the attributes. But the final products will have the "original painting" option as pre-selected as the first option (if available) or the limited edition prints pre-selected in those instances where the original painting is sold.

In short, yes the product, which will be offered as original painting (1 unit) and limited edition print (several units typical 25-50 or more), can be purchased together in one go, if the customer desires, the reason why I decided to go for checkboxes instead of radio buttons. If I choose dropdown menus or radio buttons, customers wanting to add both options to the cart, would need to add them as two separate items in the cart, which isn't that big of a deal, but I thought checkboxes might give some flexibility. Perhaps I'm seeing this with the wrong pair of glasses? I have the tendency to use tools differently than the way they were intended to be used.

What I'm trying to accomplish in this case of the checkboxes, assuming I picked the right option, is move the "red dot" which marks the piece as sold, to the end or the right side of the price, as shown in the picture below.

I was able to pinpoint the line of code that displays the "sold" message which is controlled by the define PWA_OUT_OF_STOCK located on includes/classes/observers/class.products_with_attributes_stock.php at around line 368

    if (empty($products_options_DISPLAYONLY->fields['attributes_display_only'])) {
      $products_options_fields['products_options_values_name'] = $products_options_fields['products_options_values_name'] . PWA_OUT_OF_STOCK;

> 
> However I was unsuccessful at moving elements around to position the "sold" message, now displayed as a red dot, to the end. Again, I'm not good with php at all, I just play it by ear and through trial an error, tons of them. I'm only good at the design part and somehow manage for the most part to make things work the way I want them to.
> 
> These are the setting for the dynamic dropdowns as requested:
> 
> 
> Thanks again for taking the time =)
I believe that after I posted my response I took a closer look at the original picture and realized that the change desired was as also just described above: text about option, price of option and then "marker"...

So, the content of each of the attribute text listings is built "in time" with a standard everyday product's attribute with the additional text being applied to the option value "description" later on in the attributes.php file where the "price" is added. It is now after this addition that the SBA additional text is desired.

So, in chasing down the sequence of addition within the ZC 1.5.7 version of the attributes.php (note as discussed above, SBA no longer needs to modify the attributes.php file in a template override directory, the default version works great!), the price is "added on" at/around the notifier: NOTIFY_ATTRIBUTES_MODULE_ORIGINAL_PRICE. Additionally, in the above referenced file (includes/classes/observers/class.products_with_attributes_stock.php) there is a define that is used to "position" the customid. That define is PWA_DISPLAY_CUSTOMID. Where you see its "use" is well, where content revision could be done to position your "dot". The explanation of the "positioning" associated with that constant is provided near the beginning of the file and should help with templating the content location.

Hmmm. Getting me thinking about the use of replaceable text instead of specific detailed information to increase sequence capability and such... I have other things to work on, but will see about making a note of it so that future changes can be made "smartly".

mc12345678:

I believe that after I posted my response I took a closer look at the original picture and realized that the change desired was as also just described above: text about option, price of option and then "marker"...

So, the content of each of the attribute text listings is built "in time" with a standard everyday product's attribute with the additional text being applied to the option value "description" later on in the attributes.php file where the "price" is added. It is now after this addition that the SBA additional text is desired.

So, in chasing down the sequence of addition within the ZC 1.5.7 version of the attributes.php (note as discussed above, SBA no longer needs to modify the attributes.php file in a template override directory, the default version works great!), the price is "added on" at/around the notifier: NOTIFY_ATTRIBUTES_MODULE_ORIGINAL_PRICE. Additionally, in the above referenced file (includes/classes/observers/class.products_with_attributes_stock.php) there is a define that is used to "position" the customid. That define is PWA_DISPLAY_CUSTOMID. Where you see its "use" is well, where content revision could be done to position your "dot". The explanation of the "positioning" associated with that constant is provided near the beginning of the file and should help with templating the content location.

Hmmm. Getting me thinking about the use of replaceable text instead of specific detailed information to increase sequence capability and such... I have other things to work on, but will see about making a note of it so that future changes can be made "smartly".

After spending quite a few minutes looking for the define PWA_DISPLAY_CUSTOMID you mentioned, I realized I don't have installed ZC157 but ZC156c :(
I picked up where I left before the pandemic hit, and somehow completely missed updating to ZC1.5.7! :wacko::frusty::oops::cry:
Back to the beginning :shocking:

mvstudio:

After spending quite a few minutes looking for the define PWA_DISPLAY_CUSTOMID you mentioned, I realized I don't have installed ZC157 but ZC156c :(
I picked up where I left before the pandemic hit, and somehow completely missed updating to ZC1.5.7! :wacko::frusty::oops::cry:
Back to the beginning :shocking:
Well, while I commend you on ensuring that the store is up-to-date, the features I described are within the current github distribution and apply and/or are available without the ZC upgrade... Further, the ZC upgrade itself will not add the described additional code. That would still require download of the latest version from github...

mc12345678:

Well, while I commend you on ensuring that the store is up-to-date, the features I described are within the current github distribution and apply and/or are available without the ZC upgrade... Further, the ZC upgrade itself will not add the described additional code. That would still require download of the latest version from github...

I had thought about updating just the plugin to the latest version, but wasn't sure if it would work. Since I'm too close to the holiday season and need to have this up and running, I didn't want to risk making a bigger mess. On my way to install the latest version and implement the changes! Thank you! =)

mvstudio:

I had thought about updating just the plugin to the latest version, but wasn't sure if it would work. Since I'm too close to the holiday season and need to have this up and running, I didn't want to risk making a bigger mess. On my way to install the latest version and implement the changes! Thank you! =)

I'd make attempts to "fix" it if there were trouble at lowere ZC versions. :) Don't know "it's broke" sometimes though without someone throwing it out there...

mc12345678:

I'd make attempts to "fix" it if there were trouble at lowere ZC versions. :) Don't know "it's broke" sometimes though without someone throwing it out there...

I tried and boy did I try to reposition that little "red dot" within the file, and I just couldn't figure out what should have been placed where.
So I cheated.
I added a class to the image, and with CSS I made it float at the end.
It works, at least for now.
I will however when I have more time, figure out what needs to be edited, how and where, as I'm determined to learn and do things the right way.

Thank you for the help! =)

In ZC v1.57a (compared to v1.57) there are changes to

admin/packingslip.php
admin/invoice.php

that make it difficult for me to incorporate the SBA edits - bit of a guessing game. Would it be possible to update the Github code at some point?