Printable View
I figured it out. Sorry, It was that I had two files. One thing to note is that you should not keep the same file names next to each other like Order.php and lets say Order1.php<-- using the (1) as something of a backup file. It works sometimes, but can confuse the system other times.
Actually, generally speaking, the extension (.php) should be modified in such a case of trying to take a file out of the process. Ie. .php~ or some other final extension.Quote:
Originally Posted by Zoloworld
Something that I did not even think about. I will switch that in the future when experimenting. When I uploaded the picture swap mod, it had some weird language on the pages where there were attributes. I will revisit this sometime next week and play with it a bit.Quote:
Originally Posted by mc12345678
Considering the method(s) of incorporation that I've been seeing (file renaming), I want to be sure you understand how software like either of these is provided. (there are other ways as well).Quote:
Originally Posted by Zoloworld
The provided files ought to be the version that one would obtain if downloading a new copy of ZC, but where a file is modified, it would include code that "activates" the necessary actions for the plugin. It is possible that other software (template related or as provided by another existing installed program) may have already modified the file. Therefore replacing the file (even if by renaming an existing one) could/would remove the changes made by the other program. This is generally not desired. Instead, the goal is to add to what already exists. This is made easier by the use of comparison software such as WinMerge, Beyond Compare, etc...
Although the above message relates to software unrelated to SBA, I have the concern regardless. That said, when you get back to it, I would suggest that issues with the attribute image swap be addressed in the forum thread for that software. :)
Hi mc12345678,
Thanks for maintaining this add-on.
I am about to upgrade my site from ZC 1.5.1 to ZC 1.5.5e and am after a little advice on this add-on. I have 2 other add-ons installed but they are both pretty simple ones (e.g. US to UK English one which alters all of one file) so are easy enough to re-implement so can be done last once everything else is running fine. I did a file compare a bit ago so have a list of the files that were altered by the 3 add-ons but am waiting for a decent amount of un-interrupted time to actually do the upgrade. This is looking like next weekend.
I have downloaded your Git with all the files in it but was wondering if there are any instructions? I have set up a test version of my site which currently has a vanilla install of ZC 1.5.5e and the database copy has the original extra tables/fields from Stock by Attributes (I have a feeling an extra field was added to one of the tables at some point so that will need adding but I can add that in manually if necessary). So, now to where I am after some advice (and your README.md says to ask here :wink:)...
Do I just copy the files from the 1_5_5 directory from the Git (after renaming the template and admin folders) or is this more an incremental upgrade and needs files copying from previous version folders (and/or the root) as there appears to be some files missing from just the 1_5_5 folder? I have looked back through pages of this thread and can't find an answer but if it is there and you know roughly when (or the post number) please point me in that direction.
Thanks in advance.
Hi mc12345678,
Thanks for keeping this add-on alive and updated.
I am after some quick advice before upgrading.
I am currently running ZC 1.5.1 with 3 add-ons, one being Stock By Attributes. The other 2 are very basic add-ons so I will worry about re-implementing them once the rest is working. I am looking to upgrade this to ZC 1.5.5e probably next weekend when I will hopefully have some uninterrupted time.
I have compared my current ZC files with the vanilla 1.5.1 files so have a list of what files were changed by each add-on. I have also downloaded your Git. I have installed 1.5.5e on top of a backup copy of my site but have yet to put the add-ons back in but the extra tables/fields for SBA are in the backup database (although I believe an extra field was added to one of the tables in a more recent update which will need adding to one of the tables - but this can be easily added manually if that is the case).
What I would like to know is what will need copying into the new ZC version to get SBA back up and running? I have renamed the template folders to the correct template names and will do the same for the admin folder but it looks like it is more than just copying the files from the 1_5_5 folder of the Git. Do I need to copy all the version files across in order or just the ones from the root folder + the 1_5_5 folder?
Sorry if this has been asked before but I have looked back through pages of posts in this thread and can find nothing about this. Also, apologies if this appears as a duplicate post but I tried to post similar to this earlier and it disappeared.
Thanks in advance.
Been a long day for me and I can't say I understand the history of the two posts, but they seem to contain the same basic content. While it doesn't prevent me from providing an answer, I just wish to say that posting more than once doesn't necessarily make things go faster. If they were posted elsewhere in the forum, it's actually good that they are now here.
Anyways, the instructions remain in modification as the instructions that potteryhouse generated while accurate to the extent that he revamped the program, they identify only a limited amount of the capacity.
So. Installation is best as such (for now) install the base includes and admin folders (there are a few YOUR_TEMPLATE related files in the includes folder). Where a template file exists already in your system, installation means to merge the changes made to support SBA with the existing template file. The includes/modules/YOUR_TEMPLATE/attributes.php file is generally the ZC 1.5.5 version with a few extra features to support some display features rather than duplicating the internal content.
Then merge the changes made to the files associated with your version of ZC for both store and admin (includes and admin).
You can then run the install/upgrade by logging into your admin and accessing stock_by_attr_install.php
As far as your "extra field" in a table. Since you are upgrading the database, that field is not deleted or anything and will remain present. The question becomes if there is software that uses that field in your new install...
Thanks for getting back to me.
The history of the 2 posts is that 3 hours after I posted the first post it was still not showing and my profile was still saying I hadn't posted anything. This may have been some admin thing as it was my first post but I thought maybe I hit the wrong button and cancelled it rather than posting it (been a long day here too!). Hence also the apology in the second if it showed up twice. I assume the edit/delete function disappears after a while or I would have deleted one of them. I did edit the second one slightly when first posted but there was still no sign of the first one at that time.
I read through loads of posts by potteryhouse about 120 pages back but saw nothing about actual installation but I think you have answered most of my queries and pretty much confirmed my thoughts.
I had another look into the missing fields (these are ones missing from my version of SBA that are now in) and there are quite a few (my main SBA table only has 5 fields whereas the install mentions 8). Looking through the install code, there appears to be code to add these in so they shouldn't be an issue.
I was wondering if the "gift wrapping" scenario in the original release 12+ years ago was ever addressed? Adding a an attribute/option that isn't linked to other attributes offered for the product? Or are there any separate mods that achieve this? (not gift wrapping per say but an attribute for a product that isn't quantity tracked)
So, I'm not sure your method of viewing this forum "thread" but yes in the last couple of pages it has been posted how to assign data information to apply data to get a non-stock tracked attribute "portion" assigned. I thought that the stock_by_attr_install screen was also updated to reflect some of the information related. I'm still waiting for other to provide feedback on its use/success before I dig into the user interface to improve its accesibility.Quote:
Originally Posted by ivopivo
Ie. Right now a sql script has to be applied manually. There are a few ways and places I think it would be beneficial to allow applying such feature, but don't want to spend too much time on a feature if there are already major issues with it.
Post 2725 has instructions on how to apply the "gift wrap" option and also is some additional information before that.Quote:
Originally Posted by mc12345678
Thanks. I'm running SBA Version 1.5.4 / Zen Cart Version 1.5.4.Quote:
Originally Posted by mc12345678
I don't have the "products_with_attributes_stock_attributes_non_stock" table, should I create it?
Or is this for another version of SBA?
I'm happy to give this a good test as I have many products that this feature would apply to.
Use of the table takes more than just creating it. Unfortunately, version control is more so by date than version number. The date is related to when the software was downloaded from github at the following link: https://github.com/mc12345678/Stock_...butes_Combined which has been observed/reported as operational for ZC 1.5.0 through 1.5.5e. I have also incorporated ZC 1.5.6 files as they were on the date of incorporation.Quote:
Originally Posted by ivopivo
Be glad to get some feedback other than need instructions. :) that part I know, but there is a lot of instruction covered in these later pages of the thread.
Hi mc12345678,
I decided to start my upgrade but ran into a couple of problems...
Firstly one of the files just would not load onto my server despite trying 2 different ftp programs - I haven't a clue why as it said it was copying fine but wasn't appearing server side. I managed to get around that by logging onto the server back end and pulling the file in from there! I hope there are no other files missing but I guess time will tell. This isn't an issue with what you have written so don't worry, just REALLY annoying! When I get around to updating the real site I might have to pull in all the files to be on the safe side.
Secondly I had a couple of problems with the Install program.
There are 2 typos in there
Line 1321 is missing the $ in !$field_exists
Line 1335 has "options" spelt wrong - this didn't effect me, I just happened to notice it.
Having corrected these it appeared to run through fine (just telling me to delete some old files) although it didn't add the idx_products_id_stock_attributes unique key to the products_with_attributes_stock table. I'm not sure how important that is but added it in manually anyway.
It is late now so I haven't even tried anything on the site itself but looking good so far.
The two items identified by line number have been updated in the install file.
Don't know what to say about the files not wanting to upload... :) as to the index key, well it is intended to help find data. Supposedly it would end up in there on its own, but better to start off with a good index all the same. Will see if there is something off about the script in that area.
I am using the method now. I haven't had issues, its been flawless. I have numerous products and have received orders with no issues to report in the SBA functionality. Everything working as it should.Quote:
Originally Posted by mc12345678
Glad to hear and thank you for reporting back. :)Quote:
Originally Posted by ivopivo
Hard to fix something that isn't known nor expressed to be a problem.
Hi,
just a question about SBA and Edit Orders. I installed both modules on a fresh 1.55e install. It seem all fine untill You try edit an order, in wich case i got this error:
What i noticed is that this error show if an article in the order has no SBA variant, infact it also show in the upper part the warning :PHP Code:[11-Oct-2017 00:16:09 UTC] Request URI: /../edit_orders.php?origin=index&page=1&oID=3&action=update_order, IP address: ::1
#1 products_with_attributes_stock_admin->updateEditOrdersAddProduct() called at [C:\..\includes\classes\class.base.php:103]
#2 base->notify() called at [C:\..\..min\includes\functions\extra_functions\edit_orders_functions.php:971]
#3 eo_add_product_to_order() called at [C:\w..\..admin\edit_orders.php:381]
[11-Oct-2017 00:16:09 UTC] PHP Warning: Invalid argument supplied for foreach() in C:\..\...min\includes\classes\observers\class.products_with_attributes_stock.php on line 576
[11-Oct-2017 00:16:09 UTC] PHP Stack trace:
[11-Oct-2017 00:16:09 UTC] PHP 1. {main}() C:\...\..min\edit_orders.php:0
[11-Oct-2017 00:16:09 UTC] PHP 2. eo_add_product_to_order() C:\...\..min\edit_orders.php:381
[11-Oct-2017 00:16:09 UTC] PHP 3. base->notify() C:\..\..min\includes\functions\extra_functions\edit_orders_functions.php:971
[11-Oct-2017 00:16:09 UTC] PHP 4. products_with_attributes_stock_admin->updateEditOrdersAddProduct() C:\..\includes\classes\class.base.php:103
" Product 2 in the list below, named 'xxxxx', with a quantity of 1 did not exist. Attribute(s) selected:
Quantity: 50grams
Its attribute(s) were not updated.
Reading around i found quite nothing on how to integrate the 2 contributions or solve this, any help would be really appreciated.
Zencart 1.55e
Edit Orders 4.3.0 (last version from github)
SBA 1.5.4 (github last version)
PHP 5.6.31
An update...
The error shown before will be generate always when updating an order, no matter if the order has articles with SBA variants or not.
If you put an article with no SBA variant in the order it will not update and show the Warning:
" Product 2 in the list below, named 'xxxxx', with a quantity of 1 did not exist. Attribute(s) selected:
Quantity: 50grams
Its attribute(s) were not updated."
Sorry for the double post
Quote:
Originally Posted by izar74
Yeah, you're the first one to report anything about it. Issues confirmed to exist and have been corrected through the following "comparison" commit (though this was discovered through use of EO 4.1.7 on ZC 1.5.5 that was slightly modified to work with SBA).Quote:
Originally Posted by izar74
https://github.com/mc12345678/Stock_...3d1a60cda91485
These exist on the master branch of the plugin.
Hi again,Quote:
Originally Posted by mc12345678
thank you for the answer. I applied all the changes, now no error log is generated but if i try to update and order containing an article with no SBA variants defined but with variants i get a warning and no update are made.
To be more specific i tested:
1. adding products with SBA variant -->work fine
2. adding products without any variants ---> work fine
3. adding products with variants no SBA defined --> work fine
4. modifing product with variants no SBA defined --> ERROR no update are made to just variants
To be precise now it show both the warning:
"Product 2 in the list below, named 'Incenso', with a quantity of 1 did not exist. Attribute(s) selected:
Quantita: 100
Its attribute(s) were not updated."
And after the green message: "Success: Order has been successfully updated."
The order has 2 article:
n°1 has SBA attributes and if I modify it, It got update correctly.
n°2 has no SBA attribute defined and if i try to update the attributes it wont, BUT if i modify quantity or price it work, so the only thing not updated are the attributes.
here a screen of it
Attachment 17353
Hope it will help
Info certainly did thank you for being so thorough. I haven't tested this, but would appreciate feedback on it.
In admin/includes/init_includes/init_eo_sba.php, line 171 add the following:
Code:if (!$_SESSION['pwas_class2']->zen_product_is_sba($product_id)) continue;
Code:$product_id = $old_product['id'];
if (!$_SESSION['pwas_class2']->zen_product_is_sba($product_id)) continue;
// Handle attributes
if(!empty($product_options) && is_array($product_options))
Thanks to you for your effort, I'm merely trying to solve this :D
Ok Modified and tested, the result is that now no warning appears and it correctly change the attributes. The problem is that it wont change the price associated with the attributes.
Let me be clear, in the image i posted You can see that the second products "Incenso" has a base price of 5 with a base attribute of 50g, the other attributes is 100g and should apply a +5.00 to the item (it does correctly during the normal buying process).
Now editing the orders wont show any warning and if You change the attribute it will be updated correctly, but the price will remain always 5.00.
I'm going to do some more testing with mixed product if i came up with something else i'll post it
Sorry i realize only after writing that probabily It's not something that concern SBA module but it's an Edit Order plugin problem cause it affect all the article (SBA or not).
I will test this to be sure.
Hi again,
confirmed everything works fine. Adding and removing articles and modifing it is ok!
Thanks a lot for the help
Thanks for the feedback. It has helped to make the plugin better. I can recall wanting to have those two changes in place, but had moved onto something else before either identifying the issue or it becoming a problem. I think I had just been merrily testing the SBA operation so much that I didn't go back to finish off the remaining. (think I even commented on its limitations at the time of posting awaiting some feedback that you have thankfully provided.)Quote:
Originally Posted by izar74
Hi all,
I am new to 1.55e, just did a fresh install and i cant seems to find the option to display stock level on the attribute
Attachment 17359
Already did the options for
Config > Product type > General > Show Quantity in Stock = 1
Config > Stock > Show Quantity in Stock > true
Attachment 17360
Sync'ed a few times already but still not showing :(
Anyone could give me some tips on where should i start looking? Thank you!
For single attribute product/option names like shown above, the option name type needs to be modified to the newly added (new to your ZC) SBA Basic select (dropdown) either through the option name manager or thanks to the support of fbroz through one of the two scripts in the configuration section.Quote:
Originally Posted by thymine
If that has already been done, there should also be a setting in configuration->Stock: SBA Show Stock Level on Product Info Page which is really the option of concern because it operates independent of the display of the total product count.
Thank you MC, you solved my problem! Yes the SBA Basic select (dropdown)!!Quote:
Originally Posted by mc12345678
This affects a "limited" group meeting the following conditions:
1. Software downloaded from the master branch of the github repository at https://github.com/mc12345678/Stock_...butes_Combined
2. obtained between Jul 28th, 2017 and Oct 15th, 2017.
3. Product is tracked by SBA and has only one option name (attribute).
4. one or more option values (variant) is out-of-stock.
The condition observed is that when looking at the product info page, the list of attribute options contains some random like information such as the same option value listed more than once some with the out-of-stock notification some without, blank squares/selections, etc...
Specific resolution to this is to update the includes/classes/observers/class.products_with_attributes_stock.php file; however, there have also been some additional enhancements to the admin side. Basically the recommendation would be to update the includesand admin/includes files that are not template or version specific related.
The current commit leading to what would also be at the master thread right now is: https://github.com/mc12345678/Stock_...9a50e8a56750f2.
I have downloaded the latest version and installed on a 1.5.5e store. I am having a problem with the display in the shopping cart. I checked in the shopping cart template file, but it has the right code. I can't understand why it's displaying the second "Out of Stock:" text when it should be showing "Available Stock:" with the available stock levels.
Also, that product has 1 in stock of size 6-12 month, and 2 in stock of size 12-18 months. The stock levels are synced in the admin. If I have 1 of the 6-12 and 1 or 2 of the size 12-18 in the cart, it displays fine. But if I try and do 3 of the 12-18, it is showing that the 6-12 are out of stock as well, even though there is only 1 of those in the cart, and there is 1 in stock.
Attachment 17394
I'm not yet able to reproduce the problem. I've tried two different product configurations. One where the product had multiple attributes and a group of attributes were assigned to offer a variant for each configuration. I've also gone to a product that had one attribute similar to the product in the image. I tried with mixed attributes as well as without and even applied a maximum number of product from which to select and was not able to reproduce the issue when the product quantity was synchronized with the number of product. Meaning if there were 2 size 12-18 and 1 of size 6-12 then the total quantity in stock for the product should be 3 as far as being synchronized. No matter how I approached modifying the quantity in the cart (modify on the shopping cart page or by trying to add from the product information page), I was always advised that the quantity was adjusted for the maximum quantity in stock and the value last modified was again updated to prevent exceeding either the total product in stock or the total for that attribute. I also repeated this by swapping the quantity available of the two attributes (in case there was some sort of sequence issue that was causing a problem) and didn't get a different result. Now I didn't try adding those product in reverse order, but...Quote:
Originally Posted by Danielle
Now... When I reduced the total quantity of the product to be less than the synchronized quantity (ie. in the above if the total product quantity were 3 and the quantity available of size 12-18 were increased to 3 (by attribute 4 available, but by product only 3), then I was able to get the error message that you describe as soon as I refreshed the cart where it already had quantity in it that exceeded the total quantity of the available product (I actually did quantities differently than provided above where I had 1 and 3 instead of 1 and 2, then my original total quantity was 4. When I had in cart 1 and 3 of the respective product, then reduced the total quantity available (simulating someone purchased a product but the individual attribute quantity hadn't been reduced) then I had an error message for both product (or any quantity product that had the same products_id basically) that the product was out-of-stock. If I reduced my quantity of 3 down to a quantity of 2, then the message disappeared, but if I then increased the quantity to 3 again, the error message again appeared.
So, it would seem to me that the issue is that at the time this occurs, there is a discrepancy between the sum of the quantity of attribute variants and the total product available such that the total quantity of product is less than the quantity for the applicable attribute product. As far as what to do in this situation, I'm certainly open to suggestions, I can tell you that there is a conflict in information at that point... What is the limiting factor? The quantity of attribute type product or the total quantity of product? How should the cart respond? If I'm allowed to pick X and Y items out of bag but the bag has some number less than the total of X and Y items, what should "auto" change the one that has the higher quantity, the one that was last modified (how can one tell which is last modified if both are modified on a single screen refresh)? Dump the changes made and just return back to whatever was last entered? (Think of having a long list of items, having determined just the right balance, selecting update cart and all the work done disappears? Not a good experience.) Should one reduce down to the lowest quantity permitted and then the other? Which one? "Higher quantity?" (What if both have the same quantity entered?) Last one added? Why should it get priority of reducing quantity?
Okay, anyways, open to suggestions and ideas, just know that there are more questions than answers in some cases.. Some would say why even allow that type of discrepancy to exist? Why not? Could work for some stores...
Now I didn't try with my store set to allow over-selling product, so that could be a condition you have set for yours, I don't know unless the settings associated with stock and SBA are shared.
Oh, I'm also going to compare my fileset to the github fileset which I presume you downloaded: https://github.com/mc12345678/Stock_...butes_Combined as the source was not identified and some older versions certainly had issues.
Just did the following regarding file status:
retrieved the remote files from github to my local computer (no differences existed for my local github repository).
Reviewed where my local master pointer was at (one commit ahead as I was working on a feature for the admin menu), returned the pointer back one commit to where github was pointing and I did find one file that had a minor modification on my local computer as compared to github:
functions affected by the difference:
zen_get_customid
zen_get_sba_attribute_ids
zen_sba_has_text_field
zen_get_sba_attribute_info
The difference(s) are/were instead of simply checking if a value was empty, the value had to also be an array. This affected 5 lines of code.
I'm going to upload it in the event that it could be causing what was seen. The file affected is includes/classes/class.products_with_attributes_class_stock.php
After committing the above, I went through the tests again with the changes removed and didn't run into the described issue until again the total product quantity was less than the combination of attributes and the total in cart was more than the quantity that is entered on the product information page.
Be glad to fix something that I can make happen (and hasn't already been considered to remain as is for general use) and have a reasonable direction to take.
Hi there,
I appreciate your looking into this. However, I don't mean the error message above the cart, is that what you are referring to? I mean down below the product image, where it says "Out of Stock:". On the older versions, this would say "Stock Available:2". I've attached a screenshot of how it looks on the current site (SBA 1.5.3 running on Zen-Cart 1.5.1), as well as how it looks on the new site I'm working on (SBA 1.5.5 running on Zen-Cart 1.5.5e).
Additionally, on the older version, if there was too many of one product variant in the cart, that one would show out of stock, but if there was another variant of the product also in the cart with the correct quantity for the variant, it would show in stock. You can also see this in the screenshot.
It seems like the newer version is not treating each variant as having it's own stock. As soon as the total amount in stock is gone over, all variants show as out of stock in the cart, even though actually it's only the one variant that is over.
Attachment 17396Attachment 17397Quote:
Originally Posted by mc12345678
So, I'm going to need more information. Do you have your store set to allow ordering in excess of what is available? Ie. What are the settings for like the first three options in configuration->stock? What about in the "old" store?Quote:
Originally Posted by Danielle
How is the product setup regarding min/max mixing? Do you have a maximum entered?
Mind you, again. SBA won't allow adding product to the cart in excess of what is available for the variant when all of the files from the recent version are put on the server and the store is not set to allow purchase when product is out-of-stock. Additionally, the ZC 1.5.5 shopping cart class has been updated to not allow a quantity to be in the cart greater than the available and will do so by reducing the item quantity to that which is in stock and provide a message about the change.
The fact that both product variants appeared to be out-of-stock is because the store does not allow over-selling, and the quantity of product available is less than the sum of the variant quantities associated with those in the cart. There is a setting that will allow the display of those quantities, but the display of the quantity available in stock won't happen if the store doesn't permit overselling and that both went out of stock is not because either variant ran out but the total supply did... that brings us back to one of the above long paragraphs. :)
Need actual setup information, verification that only the files provided in this version of SBA have been installed (not those from a previous version).
I can't reproduce the issue other than as described above. The additional discussion of other options and "activating" them depends on those settings and information.
I didn't test on a store that allows checkout when product is out-of-stock as that did not appear to be related based on the discussion of only having certain quantity available.
OK, it appears then that this version of the module just doesn't work the same in that regard. The total product quantity really shouldn't even matter when it comes to products with attribute stock. In the older version, if there are 3 total in stock, you could have 4 in your cart, but only the variant that is putting the stock overlimit would show as out of stock. There is no reason for both variants to show as out of stock. How then does the customer know which one to reduce? It's super confusing as it makes it look like they have too many of both variants, when actually they only have too many of the one variant. I think the old behavior is much more user-friendly and logical. I would change it back, but I'm really not sure how.
All settings are the same in both carts. The first three settings under Stock are all set to true.
What about the issue with it not showing the available stock in the cart?
Quote:
Originally Posted by mc12345678
I did notice that on the SBA setup page in the admin, it says that one of the changed core files is includes/modules/pages/shopping_cart/header_php.php, however, that file isn't in the github download. Are there just no changes to that file anymore?
I went through the commits and see that file was removed quite awhile ago...darn...a missing file would have been an easy fix ;)Quote:
Originally Posted by Danielle
Quote:
Originally Posted by Danielle
Ok. So hope you haven't run off and tried to "restore" the modified shopping_cart header file. The problem will persist even so.Quote:
Originally Posted by Danielle
I found the issue and was able to reproduce it.
Line 948 of includes/classes/observers/class.products_with_attributes_stock.php
Change:
To:Code:if ($SBAqtyAvailable - $products[$i]['quantity'] < 0 || $totalQtyAvailable - $_SESSION['cart']->in_cart_mixed($productArray[$i]['id']) < 0) {
That will resolve the marking of all product in the cart associated with the one products_id where the total quantity of the item's variants has exceeded the total available quantity of the item.Code:if ($SBAqtyAvailable - $products[$i]['quantity'] < 0 || ($totalQtyAvailable - $_SESSION['cart']->in_cart_mixed($productArray[$i]['id']) < 0) && STOCK_ALLOW_CHECKOUT! !== 'true') {
So, understand also that the concept of variant quantity and product quantity relates to some individuals conditions. Ie. Assume the shirts you sell are hand made/decorated. If you have 4 shirts, but enough product of one type to make 3 and enough product of another to make 2, well you only have 4 shirts. Which do you decide to not be able to make? Or do you let the purchase power of the customer figure it out for you by them buying what they want of what you have?
As to the other notification? Well, at one point around the same location in that file, the "feature" was basically disabled... seeing that someone wants it/likes it? I'll gladly put it back. I haven't looked for it recently and can't recall where I saw it, but at one point there was a lot of discussion that the maximum available quantity of a product shouldn't be made known... the store has been designed/redesigned to quite the contrary, so guess it was a false alarm...
The changes will be in that one file, so you don't have to do any sort of total reinstall. I have to figure out how to reinstate the remaining quantity and do so on something other than my cell phone. :)
The installer "information" does need to be updated. Last real modification to it was so that it would operate in a new install. Yes, there have been some changes to align more with ZC processes, but that identification is not applicable at least for ZC 1.5.5 where modifications have been pulled from the files.Quote:
Originally Posted by Danielle
OK, thanks so much, I will try that! I did test with the Allow Checkout setting set to False, and it does work perfectly that way. It is only when allow checkout is set to true, because then customers can have as many as they want in the cart with no indication as to which will be shipped right away and which will be put on backorder.Quote:
Originally Posted by mc12345678
In this store, they have single attributes only, so it's not an issue. I see your point though when multiple attributes are involved.
I tried changing that line, but the cart behavior remains the same, it shows all variants as out of stock.Quote:
Originally Posted by mc12345678
Umm do my eyes deceive me or in the new line did I type: STOCK_ALLOW_CHECKOUT followed by 2 exclamation points? (effectively negating the whole reason the content was added? Dang "grammar" checker... I knew I typed it, but didn't see the first one so I typed it again...Quote:
Originally Posted by Danielle
Please correct that first and retest before applying the below potential fix...
I really hope that removing the first exclamation point fixes it, because I can perceive how there are some other issues that could crop up if that doesn't do it and the below has to be applied...
Ok, then in the same file, and I'm thinking that the main header_php.php file may have caused the marker to be present, going to add a check to clear the condition for the unaffected product. Btw, you did navigate away from the shopping cart and/or login/out to clear the session right? I could test before posting the fix I am proposing but it's not fun to program and test together via mobile.
So same area:
To:Code:if ($SBAqtyAvailable - $products[$i]['quantity'] < 0 || (($totalQtyAvailable - $_SESSION['cart']->in_cart_mixed($productArray[$i]['id']) < 0) && STOCK_ALLOW_CHECKOUT !== 'true') ) {
$productArray[$i]['flagStockCheck'] = '<span class="markProductOutOfStock">' . STOCK_MARK_PRODUCT_OUT_OF_STOCK . '</span>';
$flagAnyOutOfStock = true;
}
Code:if ($SBAqtyAvailable - $products[$i]['quantity'] < 0 || (($totalQtyAvailable - $_SESSION['cart']->in_cart_mixed($productArray[$i]['id']) < 0) && STOCK_ALLOW_CHECKOUT !== 'true') ) {
$productArray[$i]['flagStockCheck'] = '<span class="markProductOutOfStock">' . STOCK_MARK_PRODUCT_OUT_OF_STOCK . '</span>';
$flagAnyOutOfStock = true;
} else if (zen_not_null($productArray[$i]['flagStockCheck']) && (($totalQtyAvailable - $_SESSION['cart']->in_cart_mixed($productArray[$i]['id']) < 0) && STOCK_ALLOW_CHECKOUT === 'true') {
$productArray[$i]['flagStockCheck'] = '';
}
Realize it doesn't apply to how this store is setup. A store with a single attribute could still need/want the arrangement I described. If the product were all entered such that a shirt was one size and the options were say the color of beads to be embroidered into it, then the one attribute could be color for example having red or blue as options... yes, all a matter of perspective and operation.Quote:
Originally Posted by Danielle
Danielle, for the product in question, what is the setting for Product qty Min/Unit Mix?
I have confirmed that if the code beginning at line 948 of includes/classes/observers/class.products_with_attributes_stock.php is changed from:
To:Code:if ($SBAqtyAvailable - $products[$i]['quantity'] < 0 || $totalQtyAvailable - $_SESSION['cart']->in_cart_mixed($productArray[$i]['id']) < 0) {
$productArray[$i]['flagStockCheck'] = '<span class="markProductOutOfStock">' . STOCK_MARK_PRODUCT_OUT_OF_STOCK . '</span>';
$flagAnyOutOfStock = true;
}
Then for the store setup condition of:Code:if ($SBAqtyAvailable - $products[$i]['quantity'] < 0 || (($totalQtyAvailable - $_SESSION['cart']->in_cart_mixed($productArray[$i]['id']) < 0) && STOCK_ALLOW_CHECKOUT !== 'true') ) {
$productArray[$i]['flagStockCheck'] = '<span class="markProductOutOfStock">' . STOCK_MARK_PRODUCT_OUT_OF_STOCK . '</span>';
$flagAnyOutOfStock = true;
} else if (zen_not_null($productArray[$i]['flagStockCheck']) && (($totalQtyAvailable - $_SESSION['cart']->in_cart_mixed($productArray[$i]['id']) < 0) && STOCK_ALLOW_CHECKOUT === 'true') {
$productArray[$i]['flagStockCheck'] = '';
}
-the product is set to have Product Qty Min/Unit Mix set to true,
-the stock is allowed to sell beyond the available quantity (STOCK_ALLOW_CHECKOUT === 'true',
-the variant quantity in the cart exceeds total stock quantity of the product.
That only the individual variant that has a quantity greater than the identified variant will show as out-of-stock (or the soon to be provided message associated such as the total number of that variant available). Mind you that information is available for display on the product page. Of course by the time they get to the shopping cart that quantity may have also changed (first one to checkout wins).
I am looking at adding a switch to control how this area of the code operates in the condition of STOCK_ALLOW_CHECKOUT === 'true' so that the other behavior could be used if desired. (which in turn means that could lead to each individual product being able to be controlled independently by substitution of the defined value with a database look up.)
Of course my other concern still holds. Ie. One variant in the cart. The available quantity of that variant is more than the total quantity of the product. As soon as the quantity selected exceeds the available quantity, a message appears at the top of the cart indicating out-of-stock (this is because of the check in the base header_php.php file identifying that the in cart mix quantity exceeds the total quantity of product. Then using the above code, the individual variant is dismissed from being out-of-stock because the individual variant quantity has not been exceeded. So the result is a message saying those identified as out-of-stock are marked below (assuming one uses a marker), but none of the product is marked...
Easy solution in a one item/variant cart, becomes a little more convoluted for the rest, though going to make it work without forcing ZC not to be able to be setup this way and not to limit its capabilities.
Sorry for all the posts, I've conceptualized how to make it work without additional database query.
Both issues addressed to my "current" satisfaction. :) There is room for expansion and other application, some of which will eventually get incorporated, but for now, the product marking has been modified for stores that allow checkout with product that are out-of-stock (either by variant or by total product) to just mark the individual variant and not as observed where all variants for a product would be marked out-of-stock. There has been a switch point incorporated to allow such identification for those that have determined such a need (STOCK_MARK_ALLOW_MIX_TOTAL_ALL set to true will change the operation to show all variants of a product as out-of-stock when the total quantity of variant in the cart exceeds the allowable total positive quantity of product. ie. quantity of variant - total product quantity < 0).
On the shopping cart page, if a variant is marked out of stock (less than 0 or purchasing will result in such) then based on the actual quantity that remain one of three types of message (which were already in the overridden shopping_cart template) will be displayed. If the total quantity of the available variant is <=0 then out-of-stock will be displayed, then if the quantity of variant is less than the STOCK_REORDER_LEVEL (level at which notification is made to re-order stock), then a low-level with remaining quantity message will appear. then, if however the remaining quantity of the variant is above that number a message indicating the available quantity only will be displayed. Of course these messages can be modified, but thought those interested might like to understand under the hood a little.
This is all captured in the latest download of the master branch: https://www.github.com/mc12345678/St...butes_Combined.
Additional comment welcome.
Thank you! It is working perfectly now. I really appreciate all of your help :)
Quote:
Originally Posted by mc12345678
Thanks for the feedback (before and now), can only know to make changes when an issue is identified. Thank you also for putting up with me. :) normally I'm not so difficult. Verbose... sure (almost a running joke around here.). But wouldn't think difficult. :)Quote:
Originally Posted by Danielle
No, I didn't think you were difficult at all! I thought I was being difficult haha. I am super impressed and grateful for how quickly you addressed and resolved this!Quote:
Originally Posted by mc12345678
Having an issue: The admin page is blank after installing this module.
Downloaded it from: https://www.zen-cart.com/downloads.php?do=file&id=202
Version is 1.5.3
My Zen Cart version is 1.5.5e
Renamed the admin and template folders as instructed. Used Filezilla to drag and drop the files
The error log shows:
PHP Fatal error: Call to undefined function zen_get_ip_address() in /home/(myfolder)/public_html/(myadmin)/includes/init_includes/init_sessions.php on line 31
Line 31 of that file is: $ipAddressArray = explode(',', zen_get_ip_address());
What am I missing?
The files compatible with ZC 1.5.5 (and more up-to-date) that can be found at: https://github.com/mc12345678/Stock_...butes_CombinedQuote:
Originally Posted by In2Deep
The version currently for download from zen-cart.com is only for ZC 1.5.1 (or rather requires a lot of effort to merge/work with ZC 1.5.5 that efort has already been done at the above location and with additional improvements).
Please post with additional question and/or status.
Thank you, should I restore from my backed up files and database and then try again with these files or would it suffice to just upload these new files from github?Quote:
Originally Posted by mc12345678
I would restore the files. The database has not been affected in a way that needs restoration.Quote:
Originally Posted by In2Deep
Got it. Seems to be working just fine now. I wish they would just remove that old plugin link.Quote:
Originally Posted by mc12345678
I can respect and understand the thought; however, there is nothing wrong with the software as advertised in that it only works with ZC 1.5.1 as advertised. But, as to having a more up-to-date version presented there, I'd say that's on me. In order to submit software for posting, there are some minimum instructions required. Potteryhouse began some, but they describe only a limited amount of what the software can do and at this time do not really want to advertise it having such limited capability. For the time being having been providing support through this forum where even in the recent few pages most "issues" are covered and capability described. Atop that, while I have received some development support, often other priorities make it to the top of the list.Quote:
Originally Posted by In2Deep
Further as is the case with plugins and open source, users should protect themselves like you did of backing up before trying something new and try on a development location first.
Test install of ZenCart upgrade from 1.5.1 to 1.5.4. on linux with SBA from github - using Stock_By_Attributes_Combined-master, file: 1_5_3 and 1_5_4
Can only work on this in our offseason so into it now for almost a year with a multitude of mods all working but SBA and numinex extra fields
Question: is there a sql statement I am missing for SBA? I can not see the SBA in the admin.
Question 2: am I using the correct file of 1_5_3 and 1_5_4 for ZenCart 1.5.4?
Thanks everyone for working on this mod. Our upgrades of zencart depend on it working. I've always had to tweak it so much... hoping progress is steady and sure.
To be sure all in place: All SBA installs require the initial includes and admin directories (in an approaching change will be restructuring the file folders to make this easier to understand just by looking at the fileset). To further incorporate the software into the applicable ZC version then the applicable ZC version directory is used/merged (i.e. 1_5_3 and 1_5_4 to support installation to ZC 1.5.4).Quote:
Originally Posted by athena
Working in this sequence, there is no disruption to site operation during installation.
As to the absence of any SBA related items on the admin side, after all applicable files have been placed installation requires execution/access of the admin file: stock_by_attr_install.php (ie. YOUR_DOMAIN_NAME/YOUR_CATALOG_DIRECTORY/YOUR_ADMIN_DIRECTORY/stock_by_attr_install.php)
So any one or combination of the below could be the cause:
1. Depending also on the install/upgrade path/method the applicable files may not have been placed,
2. the database may not have yet been transferred to have the old "connection" to the install, or
3. the install has not been accessed with the currently loaded database in place.
All the files check out... thank you for the quick response.
It must be a db connection issue but it is a new db and I simply imported the data from the active site into the new db to test it. It stands alone right now as a new cart down for maintenance. I'll try and approach it from a db path angle and see if there is an issue there.
I can navigate to the stock_by_attr_install.php file. Any recommendation on what to choose in the drop down to make it install? Default SQL looks like the thing to do.... nope, scratch that. Full/Upgrade i reckon.
So here is what I got:
FAILURES:
There were ERRORs Reported.
Review results below:
Results from the selection Full Install: (Errors!)
File needs to be removed: /home/mysite/public_html/admin/ajax/jquery.form.js
File needs to be removed: /home/mysite/public_html/admin/ajax/jquery-1.10.2.min.js
Clean-Up, Removing from configuration:
• Deleted STOCK_SHOW_IMAGE
• Deleted STOCK_SHOW_LOW_IN_CART
• Deleted STOCK_SHOW_ATTRIB_LEVEL_STOCK
• Deleted STOCK_SHOW_ORIGINAL_PRICE_STRUCK
• Deleted STOCK_SET_SBA_SEARCHBOX
• Deleted STOCK_SBA_SEARCHLIST
• Deleted STOCK_SBA_DISPLAY_CUSTOMID
• Deleted SBA_SHOW_IMAGE_ON_PRODUCT_INFO
• Deleted PRODUCTS_OPTIONS_TYPE_SELECT_SBA
• Deleted ATTRIBUTES_SBA_DISPLAY_CUSTOMID
• Deleted SBA_SHOW_OUT_OF_STOCK_ATTR_ON_PRODUCT_INFO
• Deleted STOCK_SBA_CUSTOM_FOR_MODEL
Clean-Up, Removing from products_options_types:
• Moving option types from SBA Select List (Dropdown) Basic to an equivalent type to prepare for removal.
• Deleted products_options_types_name
Clean-Up, Removing from admin_pages:
• Deleted productsWithAttributesStock
• Deleted productsWithAttributesStockSetup
• Deleted productsWithAttributesStockAjax
Clean-Up, Removing from configuration:
• Deleted PRODINFO_ATTRIBUTE_PLUGIN_SINGLE
• Deleted PRODINFO_ATTRIBUTE_PLUGIN_MULTI
• Deleted PRODINFO_ATTRIBUTE_SHOW_OUT_OF_STOCK
• Deleted PRODINFO_ATTRIBUTE_MARK_OUT_OF_STOCK
• Deleted PRODINFO_ATTRIBUTE_OUT_OF_STOCK_MSGLINE
• Deleted PRODiNFO_ATTRIBUTE_NO_ADD_OUT_OF_STOCK
• Deleted STOCK_SET_SBA_NUMRECORDS
• Deleted PRODINFO_ATTRIBUTE_DYNAMIC_STATUS
• Deleted SBA_ZC_DEFAULT
• Deleted PRODINFO_ATTRIBUTE_POPUP_OUT_OF_STOCK
• Deleted PRODINFO_ATTRIBUTE_DYNAMIC_STOCK_READ_ONLY
Clean-Up, Removing Dynamic Dropdowns from admin_pages:
• Deleted configDynamicDropdownSBA
• Deleted Dynamic Drop Downs from configuration_group
Adding to admin_pages:
• Inserted into admin_pages productsWithAttributesStock.
Adding to configuration (SBA option switches):
Inserted into configuration:
• STOCK_SHOW_IMAGE
• STOCK_SHOW_LOW_IN_CART
• STOCK_SHOW_ATTRIB_LEVEL_STOCK
• STOCK_SHOW_ORIGINAL_PRICE_STRUCK
• STOCK_SET_SBA_SEARCHBOX
• STOCK_SBA_SEARCHLIST
• STOCK_SBA_DISPLAY_CUSTOMID
• SBA_SHOW_IMAGE_ON_PRODUCT_INFO
Adding to admin_pages:
• Inserted into configuration_group Dynamic Drop Downs.
• Inserted into admin_pages configDynamicDropdownSBA.
Adding to configuration (Dynamic Dropdowns option switches):
Inserted into configuration:
• PRODINFO_ATTRIBUTE_PLUGIN_SINGLE
• PRODINFO_ATTRIBUTE_PLUGIN_MULTI
• PRODINFO_ATTRIBUTE_SHOW_OUT_OF_STOCK
• PRODINFO_ATTRIBUTE_MARK_OUT_OF_STOCK
• PRODINFO_ATTRIBUTE_OUT_OF_STOCK_MSGLINE
• PRODINFO_ATTRIBUTE_NO_ADD_OUT_OF_STOCK
• STOCK_SET_SBA_NUMRECORDS
• products_with_attributes_stock Table Fields: stock_id | products_id | stock_attributes | quantity | sort |
Altered Table products_with_attributes_stock to add DEFAULT value of 0.
Added customid field to table products_with_attributes_stock.
Added title field to table products_with_attributes_stock.
Added product_attribute_combo field to table products_with_attributes_stock.
Added Table orders_products_with_attributes_stock:
Added New Table products_with_attributes_stock_attributes_non_stock.
Adding to admin_pages:
• Inserted into admin_pages productsWithAttributesStockSetup.
Updating PRODUCTS_OPTIONS_TYPE_SELECT, UPLOAD_PREFIX and TEXT_PREFIX
Updated PRODUCTS_OPTIONS_TYPE_SELECT, UPLOAD_PREFIX and TEXT_PREFIX
Verifiying products_options_types:
Finding highest products_options_types value:
Adding to products_options_types:
• Inserted into products_options_types "SBA Select List (Dropdown) Basic".
Adding to configuration:
• Inserted into configuration "Selection list product option type (SBA)" .
File not found: /home/mysite/public_html/mysite/includes/modules/pages/checkout_success/header_php_sba.php
While the database install itself doesn't really care what version of ZC it is on and I realize the question relates to SBA, but if all that was done was to import the old 1.5.1 database into the database referenced by ZC 1.5.4 and nothing else, then there are other steps still to be taken such as updating that database to ZC 1.5.4. Otherwise, again, if the file stock_by_attr_install.php is accessed, that should at least initiate the "install" of the admin's configuration option to again return to that same menu. Then you can do an install/upgrade, or a remove (without removing the database table(s)) followed by an install/upgrade in order to make the other options/settings again available. There really should generally be no other modifications necessary to move from the older store to a newer yet still old store. If there are, please advise so that can either incorporate into the code to address automatically or incorporate into some level of instruction beyond a potentially "lost" post.Quote:
Originally Posted by athena
Full/Upgrade is/was a good choice generally speaking. Does look like one file (at least) was not put to the server as identified by the last line of the above response (File not found: /home/mysite/public_html/mysite/includes/modules/pages/checkout_success/header_php_sba.php). Then of course there are a few files that should be removed from the server (somehow left over from the "old" install???) as it relates to SBA. If something else accesses them, then so be it, but SBA does not need those files as located at that location.Quote:
Originally Posted by athena
I believe I must have accessed the install page once before and used it to try and uninstall as I do recall running it to check if all the files were present. I then must have methodically gone through and removed then re-uploaded the pages, missing checkout_success/header_php_sba.php. It is now replaced.
I checked all my other mods and none are using the ajax/.js files so removed. Everything appears to be in place in the admin now. I will put this install through its paces to make sure SBA is working. Just one more mod and we can go live with 1.5.4. Thank you so much again
Good to hear and glad is working. Please report any issues back so that they may be addressed even if you self fix them.Quote:
Originally Posted by athena
Hi
Many thanks for putting the work into this addon, it is a great help. I am how ever having a problem with the stock quantity and out of stock notifications in the drop down box, in that I cannot get them to appear. I have been through the previous posts and tried what has been suggested before but to no avail. I am probably doing something stupid, but it is beyond me now.
ZC is 1.5.4 and the addon I used is from https://github.com/mc12345678/Stock_...butes_Combined, downloaded this morning using the 1.5.4 files. The site is live and otherwise works fine. The only other addon installed is multi cross sell
A test page for a product is here
https://www.catmint.biz/shop/index.p...bvtkgpbcn7llo3
"Right hand drive set" has a stock of 3
"Left hand drive set" has a stock of 0
"Right hand drive box dash only (no passenger side)" has a stock of 2
"Leftt hand drive box dash only (no passenger side)" has a stock of 0
Configuration/stock is as follows
Subtract stock true
Allow Checkout false
Mark product out of stock ***
Stock Re-order level 5
Products status in Catalog when out of stock should be set to 1
Show Sold Out Image in place of Add to Cart 1
Product Quantity Decimals 0
Show Shopping Cart - Delete Checkboxes or Delete Button 3
Show Shopping Cart - Update Cart Button Location 3
Show New Products on empty Shopping Cart Page 1
Show Featured Products on empty Shopping Cart Page 2
Show Special Products on empty Shopping Cart Page 3
Show Upcoming Products on empty Shopping Cart Page 4
Show Notice of Combining Shopping Cart on Login 1
SBA Show Available Stock Level in Cart (when less than order) true
SBA Display Images in Admin true Info
SBA Show Stock Level on Product Info Page true
SBA Original Price Struck Through true
SBA Display Search Box Only false
SBA Display Search List Box true
SBA Display Custom ID true
SBA Display Attributes Images 1
SBA Display Non-DD Out-of-Stock Attributes 1
SBA CustomID replaces products_model 1
Configuration/dynamic drop downs
Product Info Single Attribute Display Plugin sba_sequenced_dropdowns
Product Info Multiple Attribute Display Plugin sba_sequenced_dropdowns
Use ZC default HTML Attribute Tags false
Show Out of Stock Attributes True
Mark Out of Stock Attributes Left
SBA Number of Records to Displayed 25
Display Out of Stock Message Line True
Prevent Adding Out of Stock to Cart True
Display Javascript Popup for Out-of-Stock Selection True
Count Read Only as Stock false
Any help would be greatly appreciated
Many thanks in advance, Gordon
A very informative post, thank you for the details. There was one setting missing from the dynamic dropdowns section, but looking at the site I would say that I was able to determine its setting.
For the option name: Box Dash selection, go back into admin->catalog->option names manager and modify the type of attribute from "dropdown" to the one that is likely at the end of the list having the words SBA Select in it...
It appears that the option type is the standard dropdown and SBA has not been written to just "take over" aspects such as that.
Many thanks for the reply and help. I think the settings you mentioned are as they should be.
Sorry, I thought I had caught all the details - the missing dropdowns setting is to "enable dynamic dropdowns" and is set to 1, with the sub menu box set for "On for all SBA Tracked"
In the options name manager, the dropdown option is set to " SBA Select List (Dropdown) Basic"
Would there be anything in the SBA setup that I may have missed? When installing I did the file check which came out OK and then ran the full database install. I also ran the stock_by_attr_install.php from my browser, but I am not sure if it was successful.
Thanks again, Gordon
Restore "enable dynamic dropdowns" to its default value of 2 (on for multiple attributes only) and you should be a-okay. It's an "under-the-hood" thing. The SBA Select dropdowns were incorporated well before Dynamic Dropdowns were merged into this fileset and were functional out-of-the-box. DD still needs/needed work, so they were kept separate.Quote:
Originally Posted by catmint
Anyways, that should get the stock quantity showing (even though those items out-of-stock should not be allowed to be added to the cart).
Thanks, I have set the enable dynamic dropdowns to 2, but frustratingly the stock quantities are still not showing (did a clean page refresh as well on the web site just in case).
Thanks, Gordon
Besides all of the files located in the includes and the admin base directory, there are two additional files that must be in the proper place to further support SBA: includes/modules/YOUR_TEMPLATE/attributes.php (which adds capability to the file rather than limit it) and includes/templates/YOUR_TEMPLATE/templates/tpl_modules_attributes.php both of which are found under the base fileset having the includes directory.Quote:
Originally Posted by catmint
Brilliant, it was the attributes.php that was in the wrong place. Stock levels are now present, although the £ sign has changed to the coding word rather than the symbol, but I am not bothered about that as the priority is the stock attributes.
Many many thanks for your prompt help, it is greatly appreciated, Gordon
Welcome. Besides having instruction to identify what files/folders need to go where, it seems that the installer possibly could attempt to verify the presence of the needed file(s), though in some cases one may choose to modify the base version instead of the override and the plugin could/should recognize this possibility with regards to file existence. The "next" step to that is some sort of validation that whatever file(s) were not stored in the expected location that they still at least offer the expected operation.Quote:
Originally Posted by catmint
As to the currency display issue. I'm not yet sure if that is a general html in a dropdown problem or if there is a "conversion" not performed that should be in generating the text of the line. Since the additional cost is not on one of the "shorter" entries, I hadn't previously seen how it was displayed to know whether there was an issue created by using the SBA dropdown or not... seems unusual that it would have changed because really SBA was using the same data that was otherwise available and basically just adding to it instead of replacing it.
Will look into that because the sanitized currency symbol on the dropdown doesn't seem right. Thanks for reporting it.
This is because of a change that was incorporated into lines 192/193 of includes/classes/class.products_with_attributes_class_stock.php to sanitize to the maximum extent the name that would be displayed in the drop-down list, specifically to capture any other potential needed sanitization that was not included in line 192. I might therefore suggest removing the comment on line 192 and then commenting out line 193. This would at least restore the proper display of the text and currency symbol until possibly another alternative is considered.Quote:
Originally Posted by catmint
Therefore change:
to:Code://close tag and display text
// $field .= '>' . zen_output_string($values[$i]['text'], array('"' => '"', '\'' => ''', '<' => '<', '>' => '>')) . '</option>' . "\n";
$field .= '>' . zen_output_string_protected($values[$i]['text']) . '</option>' . "\n";
I may even suggest modifying that a little to:Code://close tag and display text
$field .= '>' . zen_output_string($values[$i]['text'], array('"' => '"', '\'' => ''', '<' => '<', '>' => '>')) . '</option>' . "\n";
// $field .= '>' . zen_output_string_protected($values[$i]['text']) . '</option>' . "\n";
to address converting "lone" '&' symbols to their corresponding html entity, but leaving combination type symbols (£) alone so that they can be properly handled/displayed.Code://close tag and display text
$field .= '>' . zen_output_string($values[$i]['text'], array('"' => '"', '\'' => ''', '<' => '<', '>' => '>', ' & ' => ' & ')) . '</option>' . "\n";
// $field .= '>' . zen_output_string_protected($values[$i]['text']) . '</option>' . "\n";
Note that the "lone" symbol is identified by having a space before and after the & which is included in the replaced value(s) as well.. Unfortunately, this replacement will not work if the only content in the field is an &. In that case the & will not be "converted".
Great, that has sorted that out as well.
Many thanks again for your support, Gordon
This is a fresh install of ZenCart 1.5.5f. I just built this web server and it has the latest stable releases to my knowledge. I'm on Debian 9. This is my Server info from my admin.
Attachment 17675
I have Categories center box for index page, COWOA, One page, Dynamic Price Update, Debug backstrace, and my payment/shipping modules installed.
I keep getting this error when I try to run the install script:
[31-Jan-2018 14:42:28 UTC] Request URI: /MY_ADMIN/stock_by_attr_install.php?selectSBAinstall=installAll&getSBAinstallPage=Run+Scri pt, IP address: 173.8.96.194
#1 trigger_error() called at [/var/www/clients/client0/web1/web/includes/classes/db/mysql/query_factory.php:171]
#2 queryFactory->show_error() called at [/var/www/clients/client0/web1/web/includes/classes/db/mysql/query_factory.php:143]
#3 queryFactory->set_error() called at [/var/www/clients/client0/web1/web/includes/classes/db/mysql/query_factory.php:270]
#4 queryFactory->Execute() called at [/var/www/clients/client0/web1/web/MY_ADMIN/stock_by_attr_install.php:963]
#5 addSBAtable() called at [/var/www/clients/client0/web1/web/MY_ADMIN/stock_by_attr_install.php:2784]
[31-Jan-2018 14:42:28 UTC] PHP Fatal error: 1071:Specified key was too long; max key length is 767 bytes :: CREATE TABLE IF NOT EXISTS `products_with_attributes_stock` (
`stock_id` int(11) NOT NULL AUTO_INCREMENT,
`products_id` int(11) NOT NULL,
`product_attribute_combo` varchar(255) DEFAULT NULL,
`stock_attributes` varchar(255) NOT NULL,
`quantity` float NOT NULL DEFAULT '0',
`sort` int(11) NOT NULL DEFAULT '0',
`customid` varchar(255) DEFAULT NULL,
`title` varchar(100) DEFAULT NULL,
PRIMARY KEY (`stock_id`),
UNIQUE KEY `idx_products_id_stock_attributes` (`products_id`,`stock_attributes`),
UNIQUE KEY `idx_products_id_attributes_id` (`product_attribute_combo`),
UNIQUE KEY `idx_customid` (`customid`)
); ==> (as called by) /var/www/clients/client0/web1/web/MY_ADMIN/stock_by_attr_install.php on line 963 <== in /var/www/clients/client0/web1/web/includes/classes/db/mysql/query_factory.php on line 171
Is it a MySQL/MariaDB issue? if so how can I remedy it?
Quote:
Originally Posted by tmpinsnty
More than likely the key that is causing the issue on the current system configuration is:
as a result of stock_attributes being 255 characters (~765 Bytes) combined with products_id being an integer (4 Bytes) puts the key over the 767 Bytes limit by 2 bytes (when using utf8, if using utf8mb4, then well the result is 1020 Bytes instead of the 767).Code:UNIQUE KEY `idx_products_id_stock_attributes` (`products_id`,`stock_attributes`),
So to correct this condition, there are a couple of things that could be done, possibly the most "flexible" is to modify the table definition such that the varchar related fields have a small enough size that the database could eventually be transitioned to utf8mb4 (if not already) and support continuing to have the unique keys identified above. (As a result of this notification may need to rethink that assignment of a unique key anyways. The code tends to prevent two or more entries from clashing at least for that particular entry, so it may not even be necessary, but would only suggest that after additional review).
There are some settings that can be applied if the mySql version were 5.6 or above and MariaDb 10.0 and above; however, in trying to keep things applicable to more systems, a more appropriate solution (to address the key issue only) would be one that supports continuing having the key and potential future use of utf8mb4 to do this, I would suggest changing:
to:Code:CREATE TABLE IF NOT EXISTS `products_with_attributes_stock` (
`stock_id` int(11) NOT NULL AUTO_INCREMENT,
`products_id` int(11) NOT NULL,
`product_attribute_combo` varchar(255) DEFAULT NULL,
`stock_attributes` varchar(255) NOT NULL,
`quantity` float NOT NULL DEFAULT '0',
`sort` int(11) NOT NULL DEFAULT '0',
`customid` varchar(255) DEFAULT NULL,
`title` varchar(100) DEFAULT NULL,
PRIMARY KEY (`stock_id`),
UNIQUE KEY `idx_products_id_stock_attributes` (`products_id`,`stock_attributes`),
UNIQUE KEY `idx_products_id_attributes_id` (`product_attribute_combo`),
UNIQUE KEY `idx_customid` (`customid`)
);
Now, that does have a potential impact on the combination(s) of attributes as the code is currently written. The number (integer) that is generated for each option name/option value combination is stored as text and when more than one such attribute is identified then the next pair is also stored with a comma between. Therefore if an attribute_id were to approach the "upper" limit of 2147483647 or 4294967295 (if the number is stored unsigned) then that one attribute alone takes 10 characters adding an additional attribute would take an additional 11 characters for each additional attribute (comma plus up to 10 characters), therefore the maximum limit in the database scheme applied above would be to have a maximum of 17 attributes for a single variant. That also said, that's considered way more than necessary and/or ever suggested for any product.Code:CREATE TABLE IF NOT EXISTS `products_with_attributes_stock` (
`stock_id` int(11) NOT NULL AUTO_INCREMENT,
`products_id` int(11) NOT NULL,
`product_attribute_combo` varchar(255) DEFAULT NULL,
`stock_attributes` varchar(190) NOT NULL,
`quantity` float NOT NULL DEFAULT '0',
`sort` int(11) NOT NULL DEFAULT '0',
`customid` varchar(255) DEFAULT NULL,
`title` varchar(100) DEFAULT NULL,
PRIMARY KEY (`stock_id`),
UNIQUE KEY `idx_products_id_stock_attributes` (`products_id`,`stock_attributes`),
UNIQUE KEY `idx_products_id_attributes_id` (`product_attribute_combo`),
UNIQUE KEY `idx_customid` (`customid`)
);
To further the database creation with possibility of utf8mb4 being used would be to reduce the other varchar(255) identifiers down to 191 instead, possibly... I've done some reading and can't recall if the 191 limit is specific to keys or to individual fields as well, but either way it seems like that's more than enough room for anything needed. :)
Please advise if the above minor change is successful so that it can be incorporated into the distribution.
The other "trial-and-error" approach would be to remove the unique key declarations, attempt to install, if successful, remove the install, then add one of the unique key designations in, install and repeat as necessary until it fails. Then if it fails on the last addition again remove the other unique key designators except for the last added and try again, should fail at that point again and would require applying changes like described above.
On another "side" note, if not mistaken debug backtrace (or a slightly modified version) is already incorporated into ZC 1.5.5 so it does not need to be specifically installed.
First of all, thank you so much for all the hard work in creating this plugin. And thank you for the help here and in other places.
So I changed to varchar amount to 190 -> didn't work
removed all three unique ids and installing worked.
Adding any one back cause the error.
Should I just take off the unique or give up the this mod? I think I want it because I can 'turn off' my attribute status when we are out of stock of one size/color. Instead of deleting the attribute and then having to re-add it (plus remembering to add the up-charges) is silly. I thought I added an older version or the code someone put in that allowed an attribute_status field. It didn't actually work quite right, but I was able to but the attribute_status = 0 in the database and that works.
It's a would be nice but not it's not like I HAVE to have it.
M
Technically, it seems that could do without any of the additional unique keys, though I can't remember if there is an internal test/check to see if a custom id is entered as a unique value which from your described usage is likely not to be a problem. There's a plan to incorporate such an independent check/test, but it hasn't been a priority (yet).Quote:
Originally Posted by tmpinsnty
So you could continue to operate the software without those three unique key entries, though it looks like a little could be done in the admin processing to test for and insert new items with consideration of allowing/rejecting duplicates meaning there may be a few operations of insertion that do not quite as cleanly prevent creating duplicate variant entries/stock increases, but this is not something that can't be through. There are multiple sensical ways to update particular records/entries and maintain operation.
I did a cursory review to see if customid as a key is essential or what effect it would have. The only thing I see is that without that table definition, then it is possible to enter the same customid for two different records. This may be desirable for some, it may not be for others. Maintaining unique customids otherwise would require a little bit of code to check for the existence and if present to prevent. The biggest obstacle is in attempting to come out of a duplicate customid condition to a unique customid condition in a way that makes sense to the user.
If anything it identifies that perhaps there are some originally builtin and until now functional considerations that if they are to remain a part of the code need to be handled in a different way that is more software driven rather than database structure driven.
So, I don't see any immediate operational issue with not using the additional three unique keys. When the appropriate duplication checking area(s) have been updated will post something here so that the change(s) can be incorporated and restore "normal" operation. :)
This isn't really a question as much as a comment ;o)
Live site is zc 1.5.5e recently update to f. Responsive Sheffield Blue 2.0, many mods. In preparation for eventual aging out of my template I built two test sites first. One updating and testing my live site files with live site db, and the other with a clean install of zc 1.5.5f and a clone responsive_classic template.
On the latter, I installed Canada Post, ckEditor, OPC 5.0, EZPop4 and Colorbox 1.2.2 followed later by IH5, SbyA most recent, and Attribute Replace Main Image.
Following the instructions on the Misc tab of IH5 I used the IH5 version of incl/modules/YOUR TEMP/additional images.php instead of Colorbox v. To my great surprise, everything worked nicely together with very little fiddling. Attribute images swapped, stock counted and adjusted, lightbox with additional images fully functional.
So next, I took the test site copy of my live site and tried to replicate this success, beginning by cloning a responsive_classic template. I didn't remove Responsive Sheffiled Blue. While it may be easier just to make my virgin site into my livesite I have great fear of losing my google rankings.
I ran into some snags. Biggest difference I can think of - non-template files merged as part of RSB template package or other mods added over the years. And perhaps relevant, Colorbox and IH4 were both resident on the RSB test site. I updated them to newest versions before adding SbyA, Attribute Image replace Main Image mods.
On my sample product I hit a snag with Attribute Images replace Main Image in both clone responsive and RSB - images wouldn't replace. Hit partial snag with SbyA - radio buttons for attribute showed but one button insisted on being default (not set that way) and the stock was being counted but didn't show (like it I try to add more than available to cart). Strangely, everything worked if I switched to Classic Green or Responsive Classic. My clone Responsive worked perfectly in the clean install test site, but not in the reworked test site.
I Beyond Compared everything to death, and eventually arrived at this solution:
Removing completely includes/YOUR TEMP/templates/tpl_modules_attributes and includes/modules/YOUR TEMP/main_product_image from both my RSB and clone Resp Classic folders rendered everything fully functional. Those files are both present in my clean test site and work fine.
I have no idea why, and I post this only in the event that it means something to anyone else ;o) I flipped a coin where to post this as it involves interplay of many mods, but I didn't want to cross post.
So, on the one hand it sounds like the problems were that a radio button styled attribute did not default to the attributes controller default and that there was an issue with some stock level display (don't follow what was expected where), but then there is some discussion of everything working fine versus another template it seems. I mean were doing really well up front explaining all that was going on, but then I get lost in what has been done to apply the same software to the other template(s).Quote:
Originally Posted by soxophoneplayer
I can say that SBA does do some data review and potentially will change the default selection of attributes if the original default is for an attribute selection that is out-of-stock (would need information about the SBA setup/configuration as well as information about the applicable variant(s).
For SBA, the file includes/templates/YOUR_TEMPLATE/templates/tpl_modules_attributes.php is what allows the dynamic dropdown aspect of the plugin to be displayed/operate. SBA will still manage the addition of product to the shopping cart, but there may be some other things that do not work as expected. Removal of includes/modules/YOUR_TEMPLATE/main_product_image.php may affect the built-in SBA image swap for single attribute product, but that too depends on the settings in attribute configuration area.
On the product listing page, each attribute showed with a radio button, but no stock level visible. If you added to cart more than was in stock you would get the warning on the cart page. This behaviour was on my modified existing test site, both in the Responsive Sheffield Blue template and newly created clone Responsive_Classic. On my second clean test site with only one test product the stock levels (and everything else) functioned perfectly.Quote:
Originally Posted by mc12345678
On the updating of existing test site, all mods were present, but in earlier versions, except SbyA and Attrib Image Swap which were not present. I updated the existing mods, in particular Colorbox and IH5, then added SbyA and Attrib Image. On the second test site - new clean install - all mods were installed from scratch. I noted that IH5 was installed after Colorbox as that had different implications for merging additional_images php according to the Misc tab in the readme folder. The clean install site was zc 1.5.5f with clone Responsive Classic.Quote:
but then there is some discussion of everything working fine versus another template it seems. I mean were doing really well up front explaining all that was going on, but then I get lost in what has been done to apply the same software to the other template(s).
Set up on both test sites involved one sample product with a single attribute - Size with 4 vatriants. I don't anticipate doing multiple attribute products.Quote:
I can say that SBA does do some data review and potentially will change the default selection of attributes if the original default is for an attribute selection that is out-of-stock (would need information about the SBA setup/configuration as well as information about the applicable variant(s).
My Dynamic Dropdown config first three settings: 1, radio, radio. On the Attribute Controller no attributes are set to Default, and each attribute has stock and each has an image file. On the Option Name Manager the single attirbute is Size and is set to Radio button and stlye 8. (6 and 7 also worked).These settings worked on the second (clean) test site without further adieu. On the updated existing test site these setting would not work until I removed the two files named above - this was with template set to Responsive Sheffield Blue, clone Responsive_Classic, and also the two stock templates.
This is why I think 'some other' mod or bits of old code junk on my existing test site mustn't be playing nice. The site was originally zc 1.5.1 first edition, which in turn was a rebuild of my original zc 1.3.7.
Oh - SbyA has image swap built in? I installed most recent SbyA but also Attrib_Image_Swap.6 (on both test sites). Would this cause issues?Quote:
For SBA, the file includes/templates/YOUR_TEMPLATE/templates/tpl_modules_attributes.php is what allows the dynamic dropdown aspect of the plugin to be displayed/operate. SBA will still manage the addition of product to the shopping cart, but there may be some other things that do not work as expected. Removal of includes/modules/YOUR_TEMPLATE/main_product_image.php may affect the built-in SBA image swap for single attribute product, but that too depends on the settings in attribute configuration area.
My crude hack of removing the two files has everything, seemingly, working with whatever old files weren't playing nice. It's still an interesting riddle to me as to what old spanner in my files was mucking up the works.
As a point if interest - it took me but a few hours to build a clean test site with zc 1.5.5f, clone a template, install Colorbox, IH5, SbyA, Attrib_Switch, CanadaPost, EZPop, OnePageCheckout, ckEditor, ColumnLayoutGrid, and to set up a test product with additional images, swappable images and stock control.
So, again... I can not yet vouch for the operability of Dynamic Dropdowns when it is used for only a single option name (single attribute), like it is above, its inclusion is to address multiple attributes/multiple option names.Quote:
Originally Posted by soxophoneplayer
SBA was rebuilt by potteryhouse (quite successfully) to work with tracking stock of a single option name/attribute which includes the display of stock adjacent or as part of the selection(s). This is also basically how the default install is arranged... If you do not have items to track that have multiple option names, then there is no reason to even access the dynamic dropdowns area after initial installation, all necessary settings are (or should be) in either the stock or attributes configuration screen.
Part of the stock display also involves using the updated includes/modules/YOUR_TEMPLATE/attributes.php file which is the same/similar to the ZC 1.5.5 version but with a few added notifiers and some other items and could potentially explain the lack of additional information (although the settings to use dynamic dropdowns in this case also could be the cause).
Note that at least without SBA, a product that has radio buttons without a default selected is one that can be selected/added to the cart without any attribute being selected.... This can cause problems for the store owner if there is none selected, especially if the product is priced-by-attributes and none are selected... When using radio buttons pretty much like any of the attribute options, a default should be selected that also is a display only option. This way if selected and the product added to the cart then ZC kicks back to identify an issue and that the customer needs to select a product.
SBA has been written to try to prevent selecting an option that has not been populated as a variant, though I do not recall the result of testing a product setup in this condition (radio button options none selected, all variants identified to product), though the expectation is that if the product has attributes and all variants identify that there are attributes selected then it seems like it should also bounce back to say that something is not right, but I'm also sure I'll be quickly corrected on this. :)
So removal of the files...
Removal of includes/templates/YOUR_TEMPLATE/templates/tpl_modules_attributes.php basically disabled the Dynamic Dropdown "features" from being displayed which would have also been corrected by restoring the Dynamic Dropdown options back to their default(s).
I'm guessing and could be wrong here, that the includes/templates/YOUR_TEMPLATE/templates/tpl_modules_attributes.php file was the second file to be removed at which point "everything" started working correctly. This is for a couple of "known" reasons, dynamic dropdowns unfortunately does not provide the same html tags around information as a default ZC store, and therefore there are some aspects of attribute monitoring that do not (yet) work as expected/desired... Again, I've been trying to maintain existing functionality and add to it rather than take over things, disable options/code that others have been paid to make get functionl, etc... What that means is that while not all of the files provided also do everything expected they are present for th previously existing functionality and if someone has rewritten some of the code to work further, it still will work.
Lastly for now, yes there is some minor image swap capability already within the SBA code for single option name type product, but it has not proven to conflict with the other attribute image swap software that you have loaded.
Hey, not sure what I've done wrong but cant seem to find a solution myself.
Basically when adding a price offset for a product with a variant, in the dynamic dropdown to select said item, I see the offset price, but the currency symbol shows as "+£" which looks horrible.
How would I go about soeting this for zen cart 1.5.5f? Ideal behaviour would be to display the selected currency symbol (my site only uses GBP, so a £ symbol in this case).
An example can be seen on the following link by selecting strength:0mg & size:50ml.
https://phantomvaper.com/store/e-liq...lish-p-88.html
Thanks!
Please see post 2875 for the solution that was posted for this problem.Quote:
Originally Posted by madshaun1984
Thanks have applied both variants (not at the same time) of the code change suggested there but am still not getting the converted symbol displayed.Quote:
Originally Posted by mc12345678
The latter version of code in that post is applied now, and
I added the offset price via the attributes manager, is that the correct way to do it when using product variants? Or is this just a caching thing?
Thanks,
Shaun
I would suspect a caching issue; however, I can not confirm as there is now a 500 error reported when attempting to access the provided link.Quote:
Originally Posted by madshaun1984
Sorry was playing with the code, missed a curly brace... Sorted now and sites back up. I've also purged the cache via cdn, still not resolved...Quote:
Originally Posted by mc12345678
Ok, I seeall that is/was going on. When the dynamic dropdowns was edited to support things like quotes and other "special" characters in the products_options_values_name that was incorporated first which then was applied to single attributes for consistency (which is what the referenced post addresses).Quote:
Originally Posted by madshaun1984
So, a similar change is needed to the dynamic dropdowns file(s) as was done for single attributes. I'm on my phone at the moment which makes it a little difficult to provide all of the change correctly/quickly, but the file in question is: includes/classes/pad_sba_sequenced_dropdowns.php
Then at line 833 modifying:
(if there are #s in there, ignore them/treat as spaces.Code:$out.='"_' . $oval['id'] . '"' . ': "' . zen_output_string_protected($oval['text']) . '", ';
To use the function provided by:
In place of the zen_output_string_protected portion of the above.Code:zen_output_string($values[$i]['text'], array('"' => '"', '\'' => ''', '<' => '<', '>' => '>', ' & ' => ' & ')) . '</option>' . "\n";
Thanks, edited the suggested line to be the following,Quote:
Originally Posted by mc12345678
Unfortunately still no change :(Code:$out.='"_' . $oval['id'] . '"' . ': "' . zen_output_string($oval['text'], array('"' => '"', '\'' => ''', '<' => '<', '>' => '>', ' & ' => ' & ')) . '", ';
Have I edited correctly?
Actually, there is/was a change, but not for the better. The code incorporated looks correct on its own; however, I believe the mix of single and double quotes within the line are causing issues and is part of why I was saying it's difficult on a cell phone. :)Quote:
Originally Posted by madshaun1984
What I suggest is to use a "temporary" variable that is to be set to the result of the zen_output_string function. That string variable is then used in place of the entire protected portion of the original code. This way the single/double quotes do not play a factor in the line that is puting together the javascriopt.
It could also be that in copying/pasting on either side (yours or mine) that some character "got in the way" that shouldn't be there.
Regardless suggest checking the logs directory again as page is only partially displayed.
Hmmm, the page is displaying in full for me, but with no difference pre/post edit (the partial page I believe you saw was the result of me editing the line I eventually settled on and pasted into my last post).Quote:
Originally Posted by mc12345678
I'll try the temp var suggestion you made now though, will update with results.
Also, is there anyway to step through website code in a similar fashion to a c# application? (I'm familiar with debugging via Visual studio, and have worked on asp.net apps / pure html / js sites previously, but never a live website that wasn't of my own creation), so not sure how it works with zen cart etc... This would save me keep coming back and might enable me to lend a better hand / start adding my own contributions.
Thanks again!
Update: adding the protected string to the temp var and then passing that through didn't make any difference.
Pretty sure the edit I made last time was ok and have a hunch that there's still something deeper not quite right.Code:$x = $out.='"_' . $oval['id'] . '"' . ': "' . zen_output_string_protected($oval['text']) . '", ';
$out.='"_' . $x['id'] . '"' . ': "' . zen_output_string($x['text'], array('"' => '"', '\'' => ''', '<' => '<', '>' => '>', ' & ' => ' & ')) . '", ';
How about this
At line 833 of includes/classes/pad_sba_sequenced_dropdowns.php
change:
to:Code:$out.='"_' . $oval['id'] . '"' . ': "' . zen_output_string_protected($oval['text']) . '", ';
So that area of code would go from:Code:$out.='"_' . $oval['id'] . '"' . ': "';
// $out.=zen_output_string_protected($oval['text']);
$out.=zen_output_string($oval['text'],
array(
'"' => '"',
'\'' => ''',
'<' => '<',
'>' => '>',
' & ' => ' & ',
'& ' => '& '
)
);
$out.='", ';
To:Code:foreach ($attr['ovals'] as $oval) {
$out.='"_' . $oval['id'] . '"' . ': "' . zen_output_string_protected($oval['text']) . '", ';[/TD]
}
This is another way to accomplish the "interim" variable perspective and is a little cleaner to some extent but also not as easy to read.Code:foreach ($attr['ovals'] as $oval) {
$out.='"_' . $oval['id'] . '"' . ': "';
// $out.=zen_output_string_protected($oval['text']);
$out.=zen_output_string($oval['text'],
array(
'"' => '"',
'\'' => ''',
'<' => '<',
'>' => '>',
' & ' => ' & ',
'& ' => '& '
)
);
$out.='", ';
}
There is something that was not right about how it was put together in the previous method/attempts and it currently still displays this html code which is causing the problem:
It is this result that we are trying to modify. The &pound; is the part that is the problem because of basically dual sanitization at least in the second dropdown. Still may need to do something for the first dropdown to resolve this.Code:var txt3 = {"_38": "10ml ", "_<": "<", "_40": "50ml (+&pound;15.00) ", "_<": "<"};
It should instead look like:
Code:var txt3 = {"_38": "10ml ", "_<": "<", "_40": "50ml (+£15.00) ", "_<": "<"};
Just added the change suggested, not getting an sba dropdown shown at all now, (partial page).
Rolled code back to as I pasted earlier.
Its as if these sections of code are having no impact on the string, or the string being processed by any replace method.
The blank/partial blank page would have generated an error as described here: http://www.zen-cart.com/content.php?124-blank-pageQuote:
Originally Posted by madshaun1984
The information from that would help identify what was causing the issue.
I didn't see anything that again modified the code content after that txt3 code is generated. I'll have to look at one of my test sites as set for an alternate currency to see how it plays out with the proposed change incorporated.
@madshaun1984, et al...Quote:
Originally Posted by mc12345678
Ok, figured out what's going on.
There were two things, one was the additional encoding that caused £ to become $amp;pound; in the txtXXX section (should be addressed by the above change(s) though processing of the code may make that change unnecessary), the other is/was that when selecting a "parent" option, the child select options are added by pushing the content to the option list. This push (creating a new option) though populated the text of the option not the html of the option. I.e put £ directly in the output text instead of the more "inner" html. So, while this was tested for the change identified at line 1053 below it has not been tested in absence of the previously posed changes or other similar changes that I made on my test server. I do think the below changes would address the wrongful display of £ instead of £.
I'm providing line numbers here working from the "bottom" to the "top" so that as each change is made the identified line numbers will still line up with the content on github at the moment (haven't pushed an update, just realized what needed to be done and proved that at least adding the change to line 1053 worked, though had also made some other changes as well that need to be validated as unnecessary.)
Between lines 1091 and 1092 having this content:
Modify it to look like the below:Code:$out.='), opt.substring(1));' . "\n";
if ((STOCK_ALLOW_CHECKOUT == 'false' && ($curattr == count($attributes) - 2)) || PRODINFO_ATTRIBUTE_NO_ADD_OUT_OF_STOCK == 'True') {
and then again between lines 1066 and 1067 having this content:Code:$out.='), opt.substring(1));' . "\n";
$out.=' frm["id[' . $attributes[$nextattr]['oid'] . ']"].options[frm["id[' . $attributes[$nextattr]['oid'] . ']"].length].innerHTML = frm["id[' . $attributes[$nextattr]['oid'] . ']"].options[frm["id[' . $attributes[$nextattr]['oid'] . ']"].length].text;' . "\n";
if ((STOCK_ALLOW_CHECKOUT == 'false' && ($curattr == count($attributes) - 2)) || PRODINFO_ATTRIBUTE_NO_ADD_OUT_OF_STOCK == 'True') {
Modify it to look like:Code:$out.='), opt.substring(1));' . "\n";
if ((STOCK_ALLOW_CHECKOUT == 'false' && ($curattr == count($attributes) - 2)) || PRODINFO_ATTRIBUTE_NO_ADD_OUT_OF_STOCK == 'True') {
Between Lines 1052 and 1053 having this content:Code:$out.='), opt.substring(1));' . "\n";
$out.=' frm["id[' . $attributes[$nextattr]['oid'] . ']"].options[frm["id[' . $attributes[$nextattr]['oid'] . ']"].length].innerHTML = frm["id[' . $attributes[$nextattr]['oid'] . ']"].options[frm["id[' . $attributes[$nextattr]['oid'] . ']"].length].text;' . "\n";
if ((STOCK_ALLOW_CHECKOUT == 'false' && ($curattr == count($attributes) - 2)) || PRODINFO_ATTRIBUTE_NO_ADD_OUT_OF_STOCK == 'True') {
have it look like the following:Code:$out.=', opt.substring(1));' . "\n";
$out.=' }';
Code:$out.=', opt.substring(1));' . "\n";
$out.=' frm["id[' . $attributes[$nextattr]['oid'] . ']"].options[frm["id[' . $attributes[$nextattr]['oid'] . ']"].length].innerHTML = frm["id[' . $attributes[$nextattr]['oid'] . ']"].options[frm["id[' . $attributes[$nextattr]['oid'] . ']"].length].text;' . "\n";
$out.=' }';
Not had a chance to look at this today, been a long day.
Will try and get on ot tomorrow and report outcome.
Thanks again,
Shaun
Look forwards to the report. Thanks for identifying the issue.Quote:
Originally Posted by madshaun1984