Hey MC,
No I had not. I try to get all mods from ZC plugins area. I do see it now though! Thank you.
Best,
John
Printable View
Hey MC,
No I had not. I try to get all mods from ZC plugins area. I do see it now though! Thank you.
Best,
John
Welcome. Yeah, I still haven't finished instructions to document the capability that is now available and there are still some interface things I want to do to help a store operator better understand what is available and perhaps make it easier to provide assistance. Certainly would like to get rid of a lot of the existing javascript, but it takes time.Quote:
Originally Posted by bumba000
i am getting this error, on zen version 1.51
Call to a member function zen_product_is_sba() on a non-object in /xxx/xxx/xxxx/xxxxxx/xx/xx/xxx/extra_cart_actions/stock_by_attributes.php on line 405
Are you using ZC 1.5.1 or SBA version 1.5.1 on some other Zen Cart version? I don't understand the current condition.Quote:
Originally Posted by jimmie
The github version of SBA for that file does match up with the report and would occur if the session wasn't started; however, I wonder how the cart could be interfaced without the session variable being loaded and without a similar problem before getting to the add-to-cart operation.
im using ZC 1.5.1
Im not really sure if im using the github version or only the 1 for 1.51
could google bots, access site and create these errors, i have google analytics installed and it says 0 users online, but getting these errors
Well the github version includes the changes needed to operate on Zen Cart 1.5.1 and as described over the last several pages would be installed by first uploading the includes and admin folders (template overrides appropriately merged/included to the appropriate template) and then merging the files associated with the applicable Zen Cart version's sub-folder.Quote:
Originally Posted by jimmie
The session variable is expected to be declared as part of the load process of includes/application_top.php at load point 199. If there is some other code that is loaded before load point 199 that is also processing the includes/extra_cart_actions folder before the session has been initiated/loaded, then that issue could occur. Would only know that by knowing what else is installed to this Zen Cart 1.5.1 system, how it has been modified from a vanilla install and how to reproduce the issue.
Otherwise you get the guess of above. :)
ok i uninstalled and redownloaded from github as of 8/19/2019 and reinstalled, same error, this is on v 1.51 with many mods. here is a list
Page Name Menu Key
Display
Link
TM Megamenu configuration Y TM Megamenu
ZX Slideshow configuration Y ZX Slideshow
TM Customblock configuration Y TM Customblock
TM Social Block configuration Y TM Social Block
BackUp ZenCart tools Y BackUp ZenCart
Mod List tools Y Mod List
CSS/JS Loader Configuration configuration Y CSS/JS Loader Configuration
Default Configuration Template configuration N Default Configuration Template
Fast and Easy Checkout Configuration configuration Y Fast and Easy Checkout Configuration
Store Credit customers Y Store Credit
Edit Orders customers N Edit Orders
Edit Orders configuration Y Edit Orders
Super Orders configuration Y Super Orders
Batch Status Update customers Y Batch Status Update
Batch Form Print customers Y Batch Form Print
Super Orders Batch Pages customers N Super Orders Batch Pages
Super Orders Data Sheet customers N Super Orders Data Sheet
Super Orders Shipping Label customers N Super Orders Shipping Label
Super Orders Edit Pop-Up customers N Super Orders Edit Pop-Up
Manage Payment Types localization Y Manage Payment Types
Orders Awaiting Payment reports Y Orders Awaiting Payment
Cash Report reports Y Cash Report
Ty Package Tracker configuration Y Ty Package Tracker
Super Tracker Configuration configuration Y Super Tracker Configuration
SuperTracker reports Y SuperTracker
Monthly Sales reports Y Monthly Sales
Sales Report with Graphs reports Y Sales Report with Graphs
Sitemap XML tools Y Sitemap XML
Sitemap XML configuration Y Sitemap XML
New Order modules N New Order
New Order customers Y New Order
Add Customer customers Y Add Customer
ZX Point of Sale configuration Y ZX Point of Sale
Numinix Product Fields catalog Y Numinix Product Fields
Numinix Product Fields configuration Y Numinix Product Fields
Advanced Shipper Config modules Y Advanced Shipper Config
(BOX_CEON_SOPHISTICATED_SHIPPER) modules Y Link cannot be created
Sophisticated Shipper Config modules Y Sophisticated Shipper Config
Abandoned Carts customers Y Abandoned Carts
Recovered Sales Results reports Y Recovered Sales Results
Configure RCS configuration Y Configure RCS
(BOX_CATALOG_XSELL_PRODUCTS) catalog Y Link cannot be created
(BOX_CATALOG_ADVANCED_XSELL_PRODUCTS) catalog Y Link cannot be created
Return Authorization configuration Y Return Authorization
Shipping Boxes Manager Configuration configuration Y Shipping Boxes Manager Configuration
Shipping Boxes Manager tools Y Shipping Boxes Manager
Products Nesting Manager catalog Y Link cannot be created
Printable Price-list configuration Y Printable Price-list
Price-list Profile-1 configuration Y Price-list Profile-1
Price-list Profile-2 configuration Y Price-list Profile-2
Price-list Profile-3 configuration Y Price-list Profile-3
Cross-Sell (X-Sell) Configuration configuration Y Cross-Sell (X-Sell) Configuration
Cross-Sell (X-Sell) Admin catalog Y Cross-Sell (X-Sell) Admin
Cross Sell (X-Sell) Advanced Admin catalog Y Cross Sell (X-Sell) Advanced Admin
Chatra tools Y Chatra
ZX AJAX Add to Cart configuration Y ZX AJAX Add to Cart
Sales Report reports Y Sales Report
Easy Populate 4 tools Y Easy Populate 4
Easy Populate 4 configuration Y Easy Populate 4
Dynamic Drop Downs configuration Y Dynamic Drop Downs
Products with Attributes Stock (aka SBA) Setup configuration Y Products with Attributes Stock (aka SBA) Setup
Products with Attributes Stock Ajax catalog N Products with Attributes Stock Ajax
Products with Attributes Stock (aka SBA) catalog Y Products with Attributes Stock (aka SBA)
Tabbed Products Pro - Configuration configuration Y Tabbed Products Pro - Configuration
Dynamic Filter configuration Y Dynamic Filter
Google Analytics configuration Y Google Analytics
RSS Feed configuration Y RSS Feed
Socials Login Configuration configuration Y Socials Login Configuration
OneAll Social Login configuration Y OneAll Social Login
OneAll Social Login tools Y OneAll Social Login
Simplified Social Share modules Y Simplified Social Share
Google Plus One Configuration configuration Y Google Plus One Configuration
Manufacturers Carousel configuration Y Manufacturers Carousel
(BOX_CONFIGURATION_CAROUSEL) configuration Y Link cannot be created
Flexible Footer Menu Install tools Y Flexible Footer Menu Install
Side Navi Configuration configuration Y Side Navi Configuration
Structured Data Configuration configuration Y Structured Data Configuration
Image Handler4 tools Y Link cannot be created
Side Navi Configuration configuration Y Side Navi Configuration
There may be a couple of the above that have the potential of attempting to access the includes/extra_cart_actions folder. Unfortunately whichever is doing it seems to not be respecting the software or observing normal load sequence. So, while this doesn't fix that issue, it should help at least allow the store to continue operating even on that old version of Zen Cart.Quote:
Originally Posted by jimmie
in includes/extra_cart_actions/stock_by_attributes.php
Between lines 11 and 13 incorporate the following highlighted code:
Really should though try to figure out why this file is being loaded outside/before application_top is executed to load the session information and/or prepare the variables as expected for a normally operational store.Code:}
if (empty($_SESSION['pwas_class2'])) {
if (!class_exists('products_with_attributes_class_stock')) {
require DIR_FS_CATALOG . DIR_WS_CLASSES . 'class.products_with_attributes_class_stock.php';
}
$_SESSION['pwas_class2'] = new products_with_attributes_class_stock();
}
//What about: 'multiple_products_add_product' (Needs to be addressed though don't see at the moment why since generally unable to select multiple products each with attributes, perhaps something to consider for later, but let's get serious here at the moment as there are more routine actions to be handled properly first.), 'update_product' (Needs to be addressed), or 'cart' (does a notify action, so may need to address?)actions?
I was referred here from the Easy Populate thread. I am looking for a plugin that will allow an attribute to be toggled on or off based on the selection of a previous attribute. Is this plugin capable of doing this? Also, I noticed that this is for versions 1.3.5 to 1.3.9. Is it safe to use with the current versions 1.5.4 to 1.5.6c?
The thread title (until this particular post) has not really been updated over the years; however, generally speaking the software seems to have originated along this path of the original postings.Quote:
Originally Posted by GoldBuckle
The version of the software available from github has not been uploaded to the ZC plugin section because the documentation to properly identify all of the capability has not been completed. It's ability exceeds any previous documentation for the use of SBA.
In relation to your question of operability, the github version does work in ZC 1.5.x. Please see previous postings about installation, but it is the main file folders (includes and admin) with associated merging/template placement and then installation of the file(s) from the ZC version associated with the store in question. (there is no need to install an older version then next version than next situation).
Once installed, you identify the combination of attributes that are considered in stock and based on the option name sequence for the attributes, selection of the first option name will identify what is in stock, if any, of the attributes in the next option name. There are postings not so long ago about populating attributes that are not stock based such as a gift wrap option or other uses as otherwise described. The default settings for installation support the maximum flexibility of usage. There are other configuration changes that can be made, but those have remained available because of the history of the overall software and some of the flexibility that is available when using those features.
Anyways, yes this software can offer/show the availability of an option value within an option name based on the selection of a previous option value within an option name. This is done through javascript primarily, so please be sure that your associated page(s) html validate before going to install this and troubleshoot why something may not work as expected.
Zencart 1.5.1
Stock By Attributes 1.5.2
I haven't used Zencart in Years but a client has sold a site and the new owner wants help
Existing Products with attributes are working and adding to the cart ok
However I cannot for the life of me seem to get a new product with attributes to add to the cart and not be out of stock, I have set stock quantities for the various variants but they are being marked as out of stock when added to the cart, and yes each variant has 100 units sets
Although I would still recommend upgrading (both the Zen Cart version and the supporting software) I would at least recommend upgrading the SBA software.Quote:
Originally Posted by nigelt74
While I believe the "time" since making changes issue brought this to mind, may I suggest taking a look at the sequence of the option values and corresponding option name's attribute value for variants known to work against those found to be out-of-stock.
Previously the sequence of those attributes had to be set/reset after generation so that they would work properly. The more recent version doesn't get hung up with that and offers some additional options. Available: https://github.com/mc12345678/Stock_...butes_Combined
Can you elaborate or point me to a post that explains the set/reset after generation bit, as for the life of me, no matter what i do it doesn't seem to work, and i have looked at the existing working ones and new ones and I cannot see a difference.Quote:
Originally Posted by mc12345678
I will see if I can get them to upgrade these bits,
Sorry to sound like (and possibly be) a jerk, but that in a way is like asking you what color of shoe string your shoes had when you were 8 years old on the first Saturday of the 3rd month of the year. :P I say that because it was this "criteria" that I rewrote the storage/retrieval code to have a consistency rather than to depend on "luck". As I seem to recall, the older system (well older than a year ago and considering reference to 1.5.2 which was also I believe before I got involved specifically.) generated the comma separated list of attribute_ids numerically sorted, but only "respected" or displayed the information if the option name/value pair was also in some sort of numerical order relative to other characteristics. It was some "twisted" not considered condition that most worked around by adding attributes to product in a very specific order or after generating a variant had to swap values around in the database.Quote:
Originally Posted by nigelt74
It was a lot of unnecessary work and nonsense. Further as far as pointing to a specific post, well this software has had something like 4 other variants generated not to include commercial offshoots. I've been doing Zen Cart work for about 7 years now and this particular module is something I felt like needed development from day one. It's still a work in progress in my opinion, but has come a long ways from its early days. I want to get rid of a few file merges, improve on the information display in the admin manager controller, complete instructions that at least hint at what is really possible, and even add an additional stock feature that would allow an attribute to have stock shared among all product that use that attribute (structure is there, just have to adopt it).
Finally a Question i can actually answer, they were white, as I had the coolest shoes around "Bata Bullets".Quote:
Originally Posted by mc12345678
Anyway i figured it out, and it is a convoluted way of doing it, (not logical to my way of thinking)and i will see if i can get them to upgrade at least that part
I'm getting the following Warning when I use this module with PHP7.3
Use of undefined constant PRODUCTS_OPTIONS_TYPE_SELECT_SBA
The warning relates to /includes/classes/observers/class.products_with_attributes_stock.php on line 264
On a standard define, i would have done something like
if (!defined('PRODUCTS_OPTIONS_TYPE_SELECT_SBA')) {
define('PRODUCTS_OPTIONS_TYPE_SELECT_SBA', '6');
}
but, PRODUCTS_OPTIONS_TYPE_SELECT_SBA is a database stored configuration value, so how do I add a !defined line to cover this?
I'm also getting the same warning for PRODINFO_ATTRIBUTE_DYNAMIC_STATUS on line 439
Questions I have are during what operation is this occurring? What plugins are installed? Why is the includes/modules/YOUR_TEMPLATE/attributes.php file and/or the observer loaded before the database is loaded? Has the installation process been performed or is the software in place without executing the database install?Quote:
Originally Posted by strelitzia
I have php 7.3 and this module loaded and not receiving any notices.
For what it's worth, it looks like need to add into the observer functions an "escape" to not perform the operations in the functions if the module is not installed. I don't really like the idea of having multiple functions each of which will need to evaluate the existence of a defined value. Another option I'm trying to consider is to dump the observer during execution if the necessary data is not available. I thought I remembered something that would support it, but I'm drawing a blank at the moment. I know that it wouldn't be anything in the includes/auto_loaders files as those are loaded too early, but seems like there could be something __construct function to allow loading some of the functions to ensure some items are assigned and others to not cause notices or similar messages.Quote:
Originally Posted by mc12345678
Ideally the software should be able to be present without causing mydebug logs to be generated. That at least has been a goal for some time now. Input on the questions of the previous post would help with that. :)
For those using this with Zen Cart 1.5.6 and above.
Found an issue while trying to clean up the code a little.
In Zen Cart 1.5.6 a notifier was added into the includes/functions/functions_lookup.php file that adds functionality of adjusting/determining the quantity to be returned when attempting to determine the stock available and another to determine if the product is in stock.
These two notifiers were incorporated into the plugin which means that the file no longer needs to be modified or supplied with the plugin.
Unfortunately, the as provided observer load point (again for Zen Cart 1.5.6 and above) is incorrect to properly report the quantity response during cart operations (add and update). In order for the observer to realize that the notifier has been triggered, it needs to be loaded before the notifier. The includes/extra_cart_actions file which is processed to handle SBA product manipulations gets loaded at load point 140. In order for the additional code to trigger when manipulating the cart contents, the load point of the observer needs to be moved up to at highest of 139, but am thinking that 135 would be sufficient. Of course, also need to now look to see what, if anything, uses those functions earlier.
So the change as identified so far is to modify includes/auto_loaders/config.products_with_attributes_stock.php line 45 from:
To:Code:$autoLoadConfig[199][] = array(
Now, because that code uses the class code that is also loaded at load point 199 into a session variable, that code (line 29) should also be loaded sooner (same load point) to support the first page load.Code:$autoLoadConfig[135][] = array(
A brief review of items loaded in config.core.php does identify that perhaps these items could be loaded before loading the shopping_cart class; however, review of the code there along with the notifiers present doesn't clearly identify points where the "early" use of the stock related notifiers would be of benefit. I'm not saying it's not possible to end up removing the extra_cart_actions file, but it seems like it would take a little effort to eliminate it's need. Currently to some extent it operates independent of the code in the shopping_cart class. If integrated more then there is the concern of modifications by other software affecting it's operation. Will still look into that but wanted to post these findings while working up the changes for github.
Hello.
I'm in need of installing this plugin on one of my sites. However the site uses the One Page Checkout. I looked throughout this thread but couldn't locate any info on this.
I guess my main concern is, would this work with OPC? Has anyone installed this on a site with OPC?
Any pointers are appreciated.
Yes, ZC v1.5.6c / OPC / Stock by Attributes does work. If you review the posts on page 312 of this thread you'll see the Github link to download the mod - there is also mention of an edit that may or may not have made its way to the Github files.
Can't think of any pointers at the moment.
For those that don't have the forum set to the default threads-per-page, the github link is at https://www.zen-cart.com/showthread....57#post1361857
That's awesome! I did see the link to the Github files but wasn't sure if it was compatible. Thanks so much! =)Quote:
Originally Posted by simon1066
Thanks! =)Quote:
Originally Posted by dbltoe
I've installed the plugin and everything seems to be working except for one minor issue I have no idea how to go about to fix it.
I have a product with two options, the full size and a sample on a pulldown menu. The full size accepts discounts, the sample does not.
For the full size product price appears right next to the attribute in parenthesis without a discount. The sample size product price and the discount price appear right next to the attribute both in separate parenthesis.
Shouldn't this be the other way around? full size - full price and discount, sample size - full price and no discount?
Any ideas how should I go about to fix this?
Thank you for the help.
Yes, the display should be opposing and I believe it has been an issue for a while. I've made an initial correction, though who knows what other outlier I need to consider, but I'm also trying to incorporate processing using the new Zen Cart 1.5.7 attributes file such that ideally, that file doesn't need to be touched going forwards.Quote:
Originally Posted by mvstudio
I'll try to prep a commit just for this price display issue and reference it back here.
Thanks for the reply. That makes sense.Quote:
Originally Posted by mc12345678
I don't know if this helps in any way but I was playing with the settings and when I turned off SBA Original Price Struck Through the sale price on the item that doesn't accept sales got removed. I have the feeling that setting isn't supposed to do that :huh:Quote:
Originally Posted by mc12345678
Like I said and you identified, backwards. :) I have a feeling that I was trying to find when not to apply the extra price display and then forgot to negate it so that it would show the extra price only when the item was discounted. I did discover that when I did that, that I also had to account for display only, default type attributes, otherwise it added 0.00 to the selection which is undesirable in routine use. Like said, may have missed some "outlier". Think I can have that solution in a PR soon. Then I have a lot of other changes to incorporate as I said for Zen Cart 1.5.7 and in some cases just to align the code with the way I've been corrected for standard ZC code.Quote:
Originally Posted by mvstudio
But, yes, if that feature is turned off then only the "final" price is displayed not the potential full price with the final price. Also, at the moment, dropdowns do not get the "strike-through" because standard dropdowns do not support html, have to use some sort of javascript based dropdown to do that, which is a desired feature not yet incorporated.
Quote:
Originally Posted by mvstudio
Quote:
Originally Posted by mc12345678
Quote:
Originally Posted by mvstudio
This appears to be resolved by the following Pull Request: https://github.com/mc12345678/Stock_.../pull/64/filesQuote:
Originally Posted by mc12345678
It does still apply the content to standard dropdowns which could be worked out; however, hasn't been removed (yet).
LOL! I'm always identifying things opposite to everyone else :D I just didn't know that control would remove the weird behavior. I searched to see if someone else had reported it before I dare post, but I must have used the wrong keywords or something 'cause I didn't find any reference on it.Quote:
Originally Posted by mc12345678
But of course you already knew what was happening, silly me :blush: For now at least the weird discount is out. :smile:
Is it out because of turning off the option or modifying the code as referenced above?Quote:
Originally Posted by mvstudio
It may not have been well documented, but when it was (again?) pointed out I at least remembered it was an area needing correction. I still prefer having the original price show before the discount price which would require a little more massaging to make it work out that way. May be easy through the use of some string replacements, but that's a topic of a different discussion. :P
Anyways, when I saw the code area and operation it reminded me again also of how it would be nice to implement an improved presentation for dropdown like attributes and I think that was something of the last straw that drove me to look for a couple (found two where one seemed a little better than the other) that supported html style code in the dropdown feature. Unfortunately they use javascript so still wanted to have a "plain text" offering for when javascript wasn't made available for one reason or another. Anyways, that meant that the issue didn't get resolved, though it at least should be better now.
Oh!!! I didn't see your post above. Sorry! :blink:
Turning off the option is what removed the discount appearing in the wrong place.
I'll download the update you posted, install it and let you know what I find.
Thank you!! :smile:
Thank you for identifying the issue(s). Can't fix something that isn't identified. :) Look forwards to the feedback and any healthy discussion that may follow. :)Quote:
Originally Posted by mvstudio
I made the changes and turned on SBA Original Price Struck Through. Here is what happened:Quote:
Originally Posted by mc12345678
1) Items for which discounts do not apply show their regular price and no other price is displayed.
2) Items for which discounts do apply show their regular price and a (+$0.00) is displayed right next to it. No discounts displayed at all.
OK. Going to need to do a little sleuthing.Quote:
Originally Posted by mvstudio
1) good. That is/was expected.
2) curious. Do you mind identifying the discount? Along with that the version of ZC (including sub-version as applicable)? I ask, because I did my test using a sale and the sale price showed along side the original price. I also thought this point in the code was where the final price was identified. Unfortunately, the final price as displayed at the product page is calculated a different way than when calculated on the shopping cart page and beyond.
Not at all! You can see the behavior following this link https://www.byvalenti.com/index.php?...&products_id=4Quote:
Originally Posted by mc12345678
I'm running ZC1.5.6c. I'm going to double check all the files just to make sure I didn't miss anything when I installed the pluggin that could possibly be the problem. I don't think, but just to make sure.
Is there a reason the "default" option (select Size) Isn't set as display only, default, and have a sort order of 0?Quote:
Originally Posted by mvstudio
I'm guessing that the product is priced by attribute, that the product's price is 0 and that each of the attributes have a price applied to them, though if that were the case, then I would expect something other than 0 to be displayed in the second value field, So perhaps a price factor is being used and there is a base price applied to the product? That type of information would help to address/narrow down how to try to make the value(s) properly display if at all possible without JavaScript type code.
zc 155e
Installed SBA 1.5.4 (github)
Weird problem surfaced
Three Attributes for (Product A)
1) style: radio button list
2) color: drop down
3) size: drop down
ISSUES
a)Using these attributes the first style attribute appears as a drop down not a radio button list?
b) If an additional attribute is added ( 4 attributes now) such as a text input the 1st style radio button list appears correct?
Configuration:
Dynamic drop downs
The first three options:
1) 2
2) sequenced drop downs
3) SBA sequenced Drop downs
Thanx
any help would be appreciated
Took me a minute to fully understand and to remember why this result was seen.Quote:
Originally Posted by mikebr
OK, so I could try to explain any number of ways, but this is how I am trying first. Ask questions if it is not understood. For multiple attribute type product, dynamic dropdowns is used where/when it has been written to support the attributes of the product. The attribute types (identified in option names manager) are those that are like dropdowns where there a selection "must" be made. These include dropdowns, the SBA Simple Select (dropdowns) and as observed radio buttons.
Support and usage of Dynamic Dropdowns is to display the data in a dropdown format. Therefore, when a combination of radio and dropdown options are used, they are all displayed as dropdowns.
Introducing a non-supported option name type (text box, check box, file, etc) negates the use of dynamic dropdowns and the default Zen Cart oper######## is displayed. While the added benefit of identifying stock availability on the product page is lost, there is still a check upon add-to-cart done against the stock and applicable customer notification is made.
It is because of this that the radio buttons reappear when adding say a text box.
The overall fix is to incorporate a more dynamic user interface on the product page.
As far as my "confusion" about the provided settings is that the modification of the dynamic dropdown setting for single attributes away from multiple_dropdowns is not expected in the code as provided. Besides, the setting of 2 means that it doesn't affect anything. To obtain the maximum functionality of SBA for even product that have just one attribute (option name), the option name type should be set to the added SBA simple select (dropdown).
The option Select Size is set as default and read only. I just changed it to sort order 0. It has no price and I just removed the + sign from all its fields. Now it no longer displays the (+$0.000) (I should have thought about that! :blush:)Quote:
Originally Posted by mc12345678
You're correct, the product is priced by attributes. Each of the options except for the default Select Size has a price. Only the Full Size can be discounted. Sample size cannot be discounted. Full size is marked as the based price for the product.
Does this help?
Yes and no. I need to look to see if the current GitHub fileset has the attribute price in the associated query or in trying to merge the correction along with still having some of the changes to support ZC 1.5.7 in the mix if that was an aspect missed. If those check out, then it would seem that perhaps something didn't get copied over/retyped correctly which probably wouldn't have been caught unless strict php was being used.Quote:
Originally Posted by mvstudio
Ughh. Mix of both, but definitely my fault.Quote:
Originally Posted by mc12345678
On line 439 of: includes/classes/observers/class.products_with_attributes_stock.php
Change:
To:Code:$products_options_fields['options_values_price']
By changing the one underscore (_) to a dash greater than (->)Code:$products_options->fields['options_values_price']
Not to pile up, but I just noticed a (((possible))) issue when multiple attributes options are used in one single product. This is the product in question https://www.byvalenti.com/index.php?...products_id=32
This particular product had a "starting at" price that came from the calculation of all the options base price. That calculation is no longer happening so it results in a starting at $0 price.
There are 2 instances in that file where that code appears, shouldn't it be changed on both? Just asking out of curiosity and so I can learn :smile:Quote:
Originally Posted by mc12345678
Never mind! I answered myself :blush:
It works!!! :clap:
Would suggest reviewing/providing the attribute configurations for the option names. Seems that there is something identifying that when no selections are made that the price is 0. Might suggest confirming that a non-zero price is determined when Dynamic Price Updater is disabled. I have a feeling that other "initial" attributes are not set to the three part combination of default, display only and sort order of 0.Quote:
Originally Posted by mvstudio
Eesh. I thought I did a better job of removing them for the purpose of this update. Guess need to work faster to get compatible with ZC 1.5.7 as those will be back (and fully supported). :)Quote:
Originally Posted by mvstudio
Briefly as the page loads I noticed the total for the base price does appear and the goes away. So I turned off DPU and sure enough ((( hold on I have to play fetch with my cat otherwise won't let me work!!))) that was it. Now to figure out what in the world I did/changed that I shouldn't have done/changed. :blush:Quote:
Originally Posted by mc12345678
Again, welcome to post the configurations, interested in items that are flagged as base price, default (or not), display only (or not) and sort order at least as relates to attributes marked with the two previous settings. DPU will display a starting at price with the lowest calculated price possible when no attributes are selected based on those settings. Also note on one or more of the referenced product that there are some "steps" that are duplicated. Didn't make sense to me, not sure about other customers.Quote:
Originally Posted by mvstudio
Sorry! I was trying to figure out if any of the changes I had made to the classes>dynamic_price_updater.php file were the culprit, but no.Quote:
Originally Posted by mc12345678
Here are the attribute settings for that product. This is a build your own system type of product, the reason why there were duplicate items.
Attachment 18743
That image is ridiculously small. What is wrong with me today!:no:
Maybe this works better.
Both images have their "problems", but I believe I can see all that is there. So, I don't know that I have ever seen priced-by-attribute product setup this way in an operational store and perhaps there is something about the code that doesn't know how to handle it (even though it is code borrowed from the ZC equivalent. What I would expect is that all attributes at least other than the "please select..." ones to have the base price marked. Regardless of if the "lowest" priced one(s) were marked. If nothing else, future management of them is made easier in that do not need to "search" for the cheapest and make sure it is marked if say the individual prices get changed. I'll try to setup a product this way, but may I recommend taking a look at a store installation that has the demo product installed and look at the setup of products 132 and 160 (both are golf clubs set to be priced by attribute). All of the clubs are marked as base price. Unfortunately, you don't see the highly recommended "please select" option in these (nor many/all?) option names.
Leave it up to me to figure out a way to use priced-by-attributes in a whole different way that is not supposed to :blink:Quote:
Originally Posted by mc12345678
I don't have a store to play with that would have the products you suggested. However I did tes with different settings and this is what I found.
1) Marking all of the options as base price except for the "select..." with DPU on and the behavior didn't change. I turned off DPU and it works just fine. The price comes down to $135.00 Sale: $101.25 which is the calculation of all the lowest price options.
2) I removed all the "select ..." from the options and marked all options as base price with DPU on and the same behavior is present. I turned off DPU and it works fine. The price comes down to $135.00 Sale: $101.25 as in the previous test.
3) Having all the "select... " removed I marked only one option on each pull down as base price with DPU on and the same thing happened. I turned off DPU and it works fine. The price comes down to $185.00 Sale: $138.75 which is the calculation for the base price options I marked.
Another thing that I noticed the original price doesn't display in this setting, only the sale price, opposite to what was happening before.
It's quite interesting this behavior happens only with this product. The rest of the products in the entire store work fine. Granted I don't have other products with these many priced-by-attributes options to compare. I can't think of any other ways to set up this product so that DPU is ok with it.
Sorry for the headache I gave you today.
I'm hoping at least for now customers will figure out by changing the selections the price updates to reflect the sale.
I just stumbled on the issue. It isn't DPU the one causing the problem, it's the option Enable Dynamic Dropdowns on Products with Attributes Stock the one that causes the calculation error. I turned it off and the product now provides a base total.Quote:
Originally Posted by mvstudio
OK, but then product that have multiple attributes won't have stock control on the product page. Would say then the issue is the attribute tags used with the "old" dynamic dropdowns. There is a setting in DD to allow using the ZC default IDs.would suggest setting DD to 2 and that option to true. See what happens then. Although on my demo site I have this set to false and am not having the same issue with product priced by Attributes. Have you used the DPU code from: https://github.com/mc12345678/Dynami...ter/tree/3.2.1Quote:
Originally Posted by mvstudio
?
I have DPU 3.2.0. I don't know if that makes a big difference. I did have it as you've mentioned and it wasn't working. When I turned of Enable Dynamic Dropdowns the behavior stopped. No matter in which setting I place it, it doesn't work. I'll download and install the latest DPU and double check all the files for PAS one more time to make sure I didn't mess up anything. I'll play around with the settings once I verify/update everything and let you know what I find.Quote:
Originally Posted by mc12345678
Thanks so much for looking into this. I appreciate it.
I just tried again where I setup a product that had two attributes, each attribute had a "please choose" attribute, all other attributes had a price, all attributes had base price marked (even the please choose ones), the please choose were marked as default and display only (so minimum of three bullets marked). In Dynamic Dropdowns, I had Enable set to 2, use ZC default HTML attribute tags set to false, when the product was loaded the attributes showed as "First Select..." and the second one as "Next select..." and the price showed as "Starting as..." and the price associated with potentially selecting the lowest priced attributes out of each group as is expected... I haven't fully compared to be sure that nothing is on my side that is not available. I do have one feature added in the code to account for discount attribute quantities, but that doesn't affect the aspect about which we are talking.Quote:
Originally Posted by mvstudio
I just did exactly as you. The first attribute displays "First select..." and so on with all of them. No starting at, price is $0.00 discount is $0.00. I thought this would be an issue I have created by modifying the pad_ files in the included>classes, changes were cosmetic only, removed the tables and added div, so I uploaded the original files and same thing. No starting at, price $0.00 and no discount displays. I'm really puzzled by this.Quote:
Originally Posted by mc12345678
Have you checked that the page passes html validation? wondering if there is an issue with the content of the page before making the first selection.Quote:
Originally Posted by mvstudio
i want to add a field for barcode_cart or (sku). i use zen-cart as a pos system with a barcode scanner, how can i scan the product and get the attribute? When i use attributes for lets say a tube of white silicone caulk it will have the barcode for white when i want brown, once barcode scanned automatically added to cart, cant choose attribute
I'm a little confused by the question, but think that it can be easily cleared up.Quote:
Originally Posted by jimmie
As I understand, the current condition is that scanning of a product gives just the base product with whatever attribute(s) are set as default. The desire is to scan and get the specific product. Further, there appears to be a problem where once the current default product is scanned, it is not possible on the shopping cart page to modify that product selection.
So, to the last thing and depending on the site's setup, once this default product is scanned and in the cart, selection of that product should return to the product's page with those attributes selected. The change should be able to be made and again added to the cart and then the previous product removable. This is obviously not ideal. Depending on other software installed there may be a problem with that return to the product page process, but that's a separate discussion.
Outright, there currently is no default option to modify the attributes directly from within the shopping cart, that would require additional coding which is possible and may exist but at the moment I am not aware of it.
So, to the first part, what it seems like is needed is a way to perform the scan, take that information and look it up and then perform the cart addition. It sounds like a portion of that process is already in place (scan a product and lookup something, but the lookup does not include the data added for this module). If that is all that seems to be missing, then I think a relatively simple lookup can be done in the associated SBA table to identify the attribute(s) related. One issue I could see is if two different product end up having the same custom_id (which is the field that I would recommend containing your lookup field).
If this is what you are seeking, then please let me know, for some reason I can't recall if there is a function that looks up the data based on the custom_id or not, though I thought there was. It would be in the main class file if it existed and if not, I would recommend it being there. The result(s) should include the possibility of duplicate results and if there are duplicates available an option presented to select which one applies...
Ah! I didn't and didn't even consider it a possibility. On my way to validate.Quote:
Originally Posted by mc12345678
Validated, and nope. It didn't make a difference at all.Quote:
Originally Posted by mc12345678
tubes of caulk are white, grey, black, brown and almond. each 1 has a model # (custom_id) and a barcode. a customer brings to the counter a brown caulk and i scan it with a barcode scanner(I do have this working on main products but only on the Point of sale page where i can enter model or a barcode), i want it to scan the brown attribute barcode and automatically add brown to the cart. i thought about changing the description tab to say barcode but need to look up that field. to look up by barcode on catalog side just have to add to search result default i think.
Had a moment to look some things over, apparently I have locally resolved this in the 3.2.1 branch, but have not updated GitHub to reflect the capability that I thought was available to all. That said, you should see on the site that the recent issue discussed is resolved. I will be posting the fix to GitHub soon, but want to try to make it clean commits.Quote:
Originally Posted by mvstudio
Thank you for taking the time to look into it! :DQuote:
Originally Posted by mc12345678
I'll download the corrected version as soon as it's available.
I'm trying to install this addon into my existing cart running 1.5.4 and I'm stuck on what is basically the first step.
Create a new database table and a new configuration switch by running the 'stock_attribute.sql' via Admin->Tools->Install SQL Patches.
The zip from github does not include the stock_attribute.sql file. Where do I find this file?
Generally speaking, the code has advanced from those earlier instructions to where there is now an installer for the sql portion.Quote:
Originally Posted by tjetzer
The general install process is pretty much the following now:
Obtain the software from https://github.com/mc12345678/stock_...butes_combined by selecting the green button on the right and download the zip file.
Load/merge the files found in the includes and admin folders with those of your site (there are a few files in the includes/modules and includes/templates directories that need to merge with your current template.)
Access the folder for your version of ZC, there is a single folder for both 1.5.3 and 1.5.4 because of their similarities and improvements that should be maintained regardless which version.
Access the admin install file by logging into your admin and then modifying the browser path to goto: admin/stock_by_attr_install.php
Where admin is the folder name for your admin.
Then there are two configuration groups added: Dynamic Dropdowns and Products with Attributes Stock (aka SBA) Setup, configuration settings added to Stock and one to Attribute Settings.
There is some help within the above admin install file accessed through: Products with Attributes Stock (aka SBA) Setup. In particular, if you have product that you wish to have use features made available by this module such as to identify attributes that are out-of-stock, the quantity remaining, etc, then the option name type should be modified to use the SBA Simple Select (dropdown) type that is added as part of install (may require logging out and back in to see this selection). Otherwise the default is set to properly use dynamic dropdowns for product having multiple attributes (option names) and to attempt to use the above for product having only a single attribute. There are still some limitations of using the software for up front customer notification, but it is expected that product that are tracked by SBA will be rejected from being added to the cart if there is no variant defined or possible by mixing single attributes or a defined variant having all attributes. One of those limitations at least to exist only for a short period longer is related to read only attributes. Also once the ZC 1.5.7 attributes.php file is properly incorporated, then there will be some improvements seen in some of the above.
Hi All, :)
I'm guessing that the image is the issue mvstudio is experiencing?
Attachment 18774
Quote:
Originally Posted by mc12345678
Quote:
Originally Posted by webmanstudios
Please explain why this image is being considered to explain the situation described by mvstudio? To me it doesn't appear that way, though I can also see that the dropdown menu does not use the SBA Basic Select (dropdown) option name type. I'm not sure which setting is enabled, but I do see that 0.00 is displayed adjacent to the attribute option which would not normally be expected. But the issue addressed by my above attached post is related to Dynamic Price Updater and I do not see at the site referenced by that image that DPU is installed. This brings me back to the request to explain.Quote:
Originally Posted by mc12345678
Hi mc,
I was checking to see if if this was the issue before lodging a new support request.
If the image was the issue being addressed I would of not bothered you further and just awaited the update to the module. :)
I have run the ''All Dropdowns to SBA Select Basic Dropdowns'' options but i did get error:
product_attribute_combo field updated Error Message: PRODUCTS_OPTIONS_TYPE_SELECT_SBA not defined.
Thank you for any assistance you can offer.
Kind Regards,
The error message described above, was that provided in the configuration section after attempting to apply the option or was that logged in a myDebug file?Quote:
Originally Posted by webmanstudios
It is expected that the PRODUCTS_OPTIONS_TYPE_SELECT_SBA be added to the database when running the install/upgrade; however, there still remain occasions where this doesn't happen and it appears to be session related. Generally, selecting the logout option from the admin screen and then logging in again to the configuration are and rerunning at least the product type install will lead to proper installation, but it has been something difficult to reproduce on an on call basis.
There is a process that can be followed to push that constant to the database, though the preference is still to identify a way for the code to do it if able to it. Information about how to reproduce the reported issue always helps as well as how it was reported.
Thank you so much for the help. I have the addon installed but am running into an issue. I cannot update the quantity of the attribute. When I click in the Quantity box I can only highlight the existing quantity (0). If I click on Edit Quantity I am able to enter a number but when I submit it the quantity doesn't update. What am I missing?
Thank you!
Quote:
Originally Posted by mc12345678
I've seen this happen, but haven't been able to get into a good testing situation to discover wht exactly. Some things that come to mind as to what it might be (again I haven't been able to reproduce it on command in some time) relate to permissions of the Ajax related files in the admin, to the method(s) of verifying that the value(s) are numeric, at one point whether the page passes html validation.Quote:
Originally Posted by tjetzer
I wouldn't mind getting access to try to see what is going on and resolving if details can be provided by PM.
Quote:
Originally Posted by tjetzer
Credentials were provided and the opportunity to review the site in its "natural" state was given. Here's what I found:Quote:
Originally Posted by mc12345678
When attempting to modify any of the fields from the Products with Attributes (aka SBA) page, no matter on what I clicked it did not become editable (this was identified while using the browser Microsoft Edge). When I clicked F12 and looked at the Console, I saw that there was an error message about items not supporting ajaxForm. Come to find out that the template override files in the base includes/templates/YOUR_TEMPLATE and includes/modules/YOUR_TEMPLATE were not incorporated into the template's folder (e.g. /includes/templates/bobs-template and includes/modules/bobs-template). This resulted in the associated jquery.form.js not being loaded and therefore the entries not "selectable".
As to the issue of going into the edit option, attempting to enter a new value (likely a number other than 0) and then save it only to result in having a value of 0. Well, it seems that versions of Zen Cart at least as old as 1.5.4 did not (properly?) handle conversion/verification of some data to a float when using the database bindVars method. In those versions, for some reason the value was always evaluated to a 0.
For me, this issue has not been happening in my more recent testing with Zen Cart 1.5.6/1.5.7 and I don't recall it happening in 1.5.5, but perhaps it did/was. Anyways, I incorporated a test for this unusual condition occurring and if it happens then to use an alternate method to ensure the value is a float before attempting to store it in the database.
I'll be pushing this modification to GitHub soon likely as a separate issue for those experiencing this. Ideally, the store would simply be upgraded to a current version where this one issue and untold other improvements have been incorporated.
Fix to the "edit quantity always enters a quantity of 0" issue described above is found at:Quote:
Originally Posted by mc12345678
https://github.com/mc12345678/Stock_...mbined/pull/66
Ok, I just got everything uploaded, and for the most part everything is working great, except I am getting an error when I try to open the Product Description page.
Parse error: syntax error, unexpected 'elseif' (T_ELSEIF) in /home/******/public_html/****/product.php on line 140
And the logs are showing:
[13-Feb-2020 15:18:16 America/Phoenix] PHP Notice: Undefined variable: categories in /home/********/public_html/****/includes/modules/category_product_listing.php on line 96
[13-Feb-2020 15:18:16 America/Phoenix] PHP Notice: Trying to get property of non-object in /home/********/public_html/****/includes/modules/category_product_listing.php on line 96
[13-Feb-2020 15:18:16 America/Phoenix] PHP Notice: Undefined variable: order in /home/********/public_html/****/includes/modules/category_product_listing.php on line 398
[13-Feb-2020 15:18:16 America/Phoenix] PHP Notice: Trying to get property of non-object in /home/********/public_html/****/includes/modules/category_product_listing.php on line 398
[13-Feb-2020 15:18:16 America/Phoenix] PHP Notice: Undefined index: customer_id in /home/********/public_html/****/includes/functions/general.php on line 1770
Don't want to make too many assumptions, but based on the first file identified, is this in the admin then? Also, what version of ZC is involved?Quote:
Originally Posted by Lordzoabar
Partially I ask because there isn't anything in the admin for this code to touch/address the product.php file in the admin which makes me think that the problem existed before adding this code or perhaps was revealed by adding SBA as a result of possibly having some other plugin installed...
Running 1.5.5f. And yes, in the Admin. The only other plugins we’ve got that touch products.php (off the top of my head) are Product Sorter, Dynamic Price Updater, and POSSIBLY Super Orders, and even still I’m fairly uncertain about that. It was running pretty late in the day yesterday when I got to the point where this all happened, so I wasn’t able to look deeper, but I’m going to run another WinMerge comparison against our live products.php when I get in today. Everything on the live side is working fine, so it may be as simple as I merged a line in the wrong spot.
Wish you the best in finding the cause. Neither this module nor Dynamic Price Updater touch the admin product file(s). I don't believe Super Orders does either at least as much as I recall of how it "used" to be. Can't speak for product sorter and yes, likely just a merging issue.
Quote:
Originally Posted by mc12345678
Hi all, so I was wrong for implying that there were no changes made to the file admin/product.php, there was a modification incorporated over many previous versions that added a notifier (where it would work) to support copying product and maintaining at least the SBA variants and reduce the amount of re-entry/generation of that information.Quote:
Originally Posted by Lordzoabar
The file provided in the fileset is/was the vanilla version of that file with the commented addition included.
So again, while the change made to that file to support SBA didn't or shouldn't affect normal viewing operations, it was made to support copying. Zen Cart V1.5.6 and above currently has that notifier present so no changes to the similar file are needed until a few version does something different in this area of code.
I will also note that for installation to ZC versions 1.5.5 and below, only the product type was modified, not the other product types such as document_product, music or the like. The same modification made in the same location of logic for those product types would continue to support copying variants from an existing product to one that is duplicated.
So I've managed to get everything installed, merged, and working mostly happily, the only issue I'm getting now is when I try to put in my second attribute variant, the page crashes and I get:
WARNING: An Error occurred, please refresh the page and try again.If you were entering information, press the BACK button in your browser and re-check the information you had entered to be sure you left no blank fields.
Logs are showing:
[15-Feb-2020 12:21:32 America/Phoenix] Request URI: /********/products_with_attributes_stock.php?products_id=2804&quantity=3&customid=23523V2& skuTitle=Burl%20Wallet%20Double&attributes=4399,,,&add_edit=add&action=execute, IP address: 47.46.139.205
#1 trigger_error() called at [/home/********/public_html/includes/classes/db/mysql/query_factory.php:171]
#2 queryFactory->show_error() called at [/home/********/public_html/includes/classes/db/mysql/query_factory.php:143]
#3 queryFactory->set_error() called at [/home/********/public_html/includes/classes/db/mysql/query_factory.php:270]
#4 queryFactory->Execute() called at [/home/********/public_html/********/includes/classes/products_with_attributes_stock.php:674]
#5 products_with_attributes_stock->insertNewAttribQty() called at [/home/********/public_html/********/products_with_attributes_stock.php:557]
--> PHP Fatal error: 1054:Unknown column '23523V2' in 'where clause' :: SELECT count(*) AS total FROM zen_products_with_attributes_stock WHERE (products_id = 2804 AND stock_attributes = 4399) OR product_attribute_combo = '2804-4399' OR customid = 23523V2 ==> (as called by) /home/********/public_html/********/includes/classes/products_with_attributes_stock.php on line 674 <== in /home/********/public_html/includes/classes/db/mysql/query_factory.php on line 171.
I've checked the Install.php page, run file check, made sure the database updates were run, and everything on that end says there aren't any errors.
So it's interesting. This is happening on the "add variant" page but it is not happening when typing directly in the field. Further it is not happening with the "title" or "description" box, but is with customid... I see that the data between these two options is handled differently between the two so need to align them and to ensure not losing operation when manually entering using the "ajax" data entry. Will be working on a solution shortly, but tending to something at the moment...Quote:
Originally Posted by Lordzoabar
Quote:
Originally Posted by mc12345678
Ok. I was mainly worried that it was something I uploaded or merged incorrectly, or that it was missing a database field. If that isn't the case, then that's fine. I've got other projects I'm working on as well.
Was just playing around and I found a workaround. I tried inserting my second variant and left the customid field blank... and it went through perfectly. Back on the main SBA page for the item, I typed in the missing info using the quick-update fields, saved, and everything shows up and is working as it should.Quote:
Originally Posted by mc12345678
One other small thing I've noticed. Now when I go to the live product page, the attribute prices are duplicating themselves. They aren't adding themselves to the final price, just displaying twice in the same place.
Attachment 18853
There's a coding issue with the "strike through price" option that is causing 1) the base price to be shown in both locations of interest and 2) showing twice at times when it shouldn't show at all. Recommend disabling that option under configuration->stock->SBA Original Price Struck Through and setting to false.Quote:
Originally Posted by Lordzoabar
I thought I had it fixed but have recently seen it happening again so not sure yet what I did to muck it up, but it is an added feature and not something part of core ZC. Further, until the dropdown is built using javascript/jquery as basic dropdowns do not support additional internal html.
Perfect. That has fixed all of my issues that I've had crop up (so far at least). Aside from that minor issue with the add variations page, I think we are go for launch. After I finish uploading the remaining 30 frames, along with their 5-6 variants each. You got a method to automate THAT? lolQuote:
Originally Posted by mc12345678
I DID take a look at the bit in the SBA wiki about showing the variant stock on the product info page, but I'm guessing that bit is a bit out of date as I couldn't find the lines referenced in either the attributes.php or the main_template_vars_attributes.php, but that is more a "nice to have" than a "need to have". and can wait for now.
Just found another new issue. Focusing on the highlighted lines in Config > Stock
Attachment 18858
Allow Checkout is technically working, except it is saying that everything is out of stock, despite SBA showing otherwise, and the product page showing the correct total in stock of all variants together. IE: For a 4x6 frame, I have it set to 5 units in stock, the product page is showing 30 (which is all my variants added up), but when I do a test order, it doesn't matter if I say I want 1 or 10, it says it's out of stock regardless. If I set "Allow Checkout" to "true", then the order goes through, but the *** for "Mark product out of stock" shows regardless of order quantity.
"SBA Show Available Stock Level in Cart" likewise is not showing ANYTHING, though I suspect its problem is tied in to the above issues.
Sba itself has gone through various variants. The current version supported here is last based off of the work done by Potteryhouse which was focused on single option name type product, but it allowed focusing on the central needs and ways to integrate with Zen Cart. As discussion and need branched into multiple option names, other tools and options made available through the forum site were used to get to this point. I believe there is still some changes necessary to the database structure, but have been trying to move some of the code outwards so that those changes can be made with ease when the time comes. Anyways, there are some things that may make integration/use "easier" but there is a cost to that as well as things such as the standard admin product page continue to be so heavily revised. Let's say that this pet project can only support so much new development at once... I have additional tools already built in (non-stock attributes) that don't really have a good, no almost no interface of their presence. Yet, they have the potential to support so much. I've even come to nearly realize that such "non-stock" attributes themselves almost could be a stock traceable option of their own, but that interface is yet to be considered.Quote:
Originally Posted by Lordzoabar
Anyways, it really depends on your attribute combinations/needs as to how to carry them forwards or assign them.
If you don't need to put a customid or description immediately, you can use the dropdown(s) when adding stock to apply variations to the product. For single option name product (I call this single attributes), the dropdown can be used to apply all option values. For multiple option names (multi-attributes) you can create them either as mixed option values or where each option name's option value is individual. Just select the option to be applied for each option name. Note that generally speaking if say there are 5 option names (number used to minimize confusion of the following), having 3 option names combined in a variant and the other 2 option names combined in its own variant will not work (without some further logic/decision priorities). It's basically either all 5 combined or all 5 individual. There is though still the case of having non-stock attributes which deviates from the above "partial list" a little.
Anyways, you can quickly populate variants using the above, also you can copy attributes from one product to another to include the variants as part of the copy and can do the same when copying product.
So that's a few ways to expedite variant entry.
This is unusual in some parts. The total quantity showing 30 is expected when the stock is "synchronized" as the total stock is equal to the sum of the variants. There are reasons where/when it may be desired for that quantity to be different, but basically as a variant is removed so is one of the total quantity. So use that information as seen fit.Quote:
Originally Posted by Lordzoabar
From that point, the indication of a quantity being out-of-stock or not is then expected to be processed by the observer class that is looking for the notifier at the end of includes/modules/pages/shopping_cart/header_php.php so that SBA can evaluate if this one variant (per product in the cart) has sufficient quantity remaining. It evaluates whether the condition of the cart to consider what if any SBA tracked items are in stock or not and in particular evaluates whether the cart as a whole has any out-of-stock product and corrects the condition if there is something about the SBA product to identify that all is "okay".
Now in earlier versions, there used to be a modification to that header_php.php file; however, a method was determined possible to perform the determination later. Problem I'm having right now is what is identifying that 1 of even 5 or 30 items is causing the software to consider that there are no product available.
One thing that comes to mind is if there are attributes in the product/provided to the shopping cart for which no variant respects... Not having a matching variant or method to handle the other attributes would cause what is described...
Do you perhaps have "display only" type option values/names? or better asked, is there a Web page to look at for the problem product and/or can you identify the attribute and variant setup for this product?
The only attributes I have attached are one for frame size - what I am using SBA to track and maintain in the first place- and an optional file upload for if the customer wants to send in a photo to be printed and included with the frame. Single file upload for single frames, and a second and third for bi and tri fold frames.Quote:
Originally Posted by mc12345678
Now, if you're telling me that that is at least partially what's responsible for tripping it up, then I don't have any issue with removing that attribute. We already have a system in place for handling online photo orders, so I can just slap the link in the product description and call it a day.
When I DON'T sync the quantity, then the product page shows it as being zero units in stock, and swaps out the "Add to Cart" button for the "Sold Out". I'll put a link to one I left un-synced as well.
https://www.athensartandframe.com/in...oducts_id=2803
https://www.athensartandframe.com/in...oducts_id=2805
There's no need (or shouldn't be) to change how you do business such as removing the image/file attribute. Just need to associate it/consider it as appropriate... meaning, try this one thing (or I'll have to go back into my variety of test product to see what it would take). Add one variant to the product with products_id 2803, that variant will have say: frame size: 2x3, upload file, upload file 2 and upload file 3 all as a single variant. Give it a quantity such as 4 (something different than the others, just to be sure tracking the correct selection).Quote:
Originally Posted by Lordzoabar
Then try to add that product selection without including a file...
That should work...
An alternative "solution" would be to identify the option name/value combination (whichever is necessary) to the non-stock attribute table so that when that data is presented that it ignores the file attribute(s) as part of the stock quantity... in this situation though, it doesn't appear possible to submit this product without picking a frame size (even if the way it is setup that one may "accidentally" pick the default 2x3 without realizing that they had other options which could turn into charge backs for those hastily picking for whatever reason...) see the FAQs about adding a display only, default with a sort order of 0...
Quote:
Originally Posted by mc12345678
Ok. Just to see what would happen, I removed the upload image from one of them, and that apparently makes the entire product free! Checked the Controller, Attribute is Free when Product is free was selected. Switched that to "false", and product is still showing as free, including in the cart. It DID add a line to the dropdown about "please elect one of the following" though.
If that is/was an attempt to force the customer to make a selection of one of the dropdown items, then the attribute that has the text "please select..." or whatever was used needs to be marked as display only, default and have a sort order of 0...Quote:
Originally Posted by Lordzoabar
If it is not marked display only (and the attribute is also marked to have its price part of the base price) then that attribute will be identified as the lowest priced attribute and will be allowed to be added to the cart making the product free... if it is not marked to be part of the base price, then the price shown will be the lowest price of any options that are part of the base price, but if that attribute is selected as part of adding to the cart, the price will be whatever is assigned to that attribute (which likely is nothing or 0)...
Now seeing that neither of the above two product were modified as described, I can't validate any of the above without walking through the entire store to find the one product that actually has this additional option value.
More importantly (at least as far as SBA is concerned) what's the status of the variant addition requested above to the specific product?
That's the thing. I never MADE a "Please select..." attribute. It just loaded itself in there on it's own, and placed itself at the top of the list. It might have been something with the Dynamic Drop Downs configs, but I don't actually know what THEY point to specifically, so I had just left them all set to default.Quote:
Originally Posted by mc12345678
I added the image upload back in, and made a second variant with the image included, and that did ultimately work. I WAS actually hoping that just removing that attribute might have been enough, as then I wouldn't have to go back and add even MORE variants to each product, but oh well.Quote:
Originally Posted by mc12345678
Fyi, I went back to my test store (it's almost to ZC 1.5.7 although some pages here and there are not yet updated the core code has been as of recent), I created a product that had two dropdown option names, it also had checkboxes, but I didn't really use them, and an attribute to upload a file.
I then went into the SBA admin screen and added variants to the product which were to combine the two dropdowns with the file attribute and gave it a quantity of 5.
This created a long list of variants where a variant for each option value from the first option name was combined with each option value of the second dropdown's option values and all had this one file attribute as well. So a variant showed three things in it where it is possible to see the option name with option value for the variant.
I then went to the store for this product, added it (without selecting to upload a file) and was presented with a cart without "stock missing".
I then went back into the admin, deleted one variant and then added it back in without the file option selected and gave it a different quantity (3) in this case.
I then tried to add that specific selection of attributes (no file uploaded either) and received a rejected notice because that particular selection of the product was out-of-stock.
This confirmed for me two things, specifically about my database that I didn't have an option in place to ignore the file attribute as a non-stock attribute, and that by having the file in the variant that even when no file was uploaded, the selection of the product was possible.
So, to that end, that issue I think is closed (for now). The other thing(s) being seen:
A product that has zero overall stock will be out-of-stock and is treated as such even if the variant(s) are available. Again, there are those that have need/desire to be able to have that type of independent stock control. Similarly, a product can be in stock and have some/all attributes be out-of-stock... again, there are cases for that... but... generally speaking like for "frames" as sold at that store as physical product, they are there or they are not... so synchronizing the attributes with the overall product quantity is a good idea, it may even be good for the total quantity to have one more than the variant quantity if it is desired to keep that product active even when no variants exist anymore... All depends on how you want things to be displayed/available...
Ok. That all does make sense, and if that's how it has to be, then that's fine. The one thing I'm still a bit confused on, is if I have a set of stock without the image upload (30 total after syncing) and then a set of stock WITH the upload (also synced?)... since the size attribute is what the stock is needing to look at, and the sizes are the same for the 2 variations (2x3 + image and 2x3 alone), is it going to count the stock once, and stay at 30, or is it actually going to double the count? Or do I just leave it unsynced after adding all the image variants?
Well, if the dynamic dropdown configuration was left as it is provided in the install and there was only one attribute (frame size) then those settings don't take part in the operation. I don't see where in that, Dynamic Price updater nor SBA where it would add that option except where the product seems to have multiple attributes and sequenced dropdowns are being used. Some "odd" things can be seen too if a product is modified in the admin and on the catalog side the page is simply reloaded... it's a long standing "issue" I guess one could say.Quote:
Originally Posted by Lordzoabar
As to the other variants, yes, as said there are two approaches that can be taken. One I would call a sort of "cop out" when considering the need. That would be to just make the file upload a non-stock related attribute for all product... but the right way would be to create variants that include the file upload or could just create a bunch of file upload variants, though if not mistaken their stock quantity would decrease in parallel with the frame(s) and frame variants.
If making combination variants, I actually would delete all variants for a product first and then add them in using the combo option... but that's me. I do have on my todo list to add a checkbox to support deleting just selected ones, but that's a separate issue too. :)