Please post any bugs found in 9.10.x (and 9.11.x as they'll be essentially the same release fork) here.
Announcement
Collapse
No announcement yet.
Miva Merchant 9.10.x Bug Reports
Collapse
This topic is closed.
X
X
-
I upgraded to 9.10.01 this morning. (I didn't upgrade to 9.10.00; I jumped straight to the patched version.) Now I am not able to add digital downloads to new products.
I have tried to add a .zip file to a new product I am setting up using the local delivery method. When I upload the file, the admin interface doesn't update the Downloaded File Name and Local File Path fields as it ordinarily does. And when I check in the directory where digital downloads are saved, I don't see any file uploaded with today's date. I last added a product with a digital download on 7/12 using the previous version of Miva and I had no issues then.Todd Gibson
Oliver + S | Sewing Patterns for Kids and the Whole Family
-
This isn't particular to 9.10.x but I'm not sure where else to report it (and my apologies if it's already been reported elsewhere).
When using Amazon Pay, the customer goes through an alternative checkout flow. If there's an error (cart contents changed, payment issue, etc) the customer gets sent back to the default checkout flow instead of the Amazon one. I opened a ticket for a related issue because we're about to test an alternative checkout flow, and I noticed the Amazon Pay issue when I checked what would happen there under the same circumstances.
So to reproduce:- add items to cart and proceed to checkout using Amazon Pay
- get to AMAZONPAY_OPAY screen
- in a separate tab, open your cart and change the quantity of an item
- in the original tab (still on AMAZONPAY_OPAY) refresh the page
- you should be redirected (I think to OCST if I remember right) with a message saying that the cart contents changed during checkout
EDIT: I was able to work around the issue using TemplateManager_Render_PageLooking for work as of March 2024! I've been a web developer for going on 20 years, with most of that time spent on Miva sites.
Comment
-
Originally posted by oliverands View PostI upgraded to 9.10.01 this morning. (I didn't upgrade to 9.10.00; I jumped straight to the patched version.) Now I am not able to add digital downloads to new products.
I have tried to add a .zip file to a new product I am setting up using the local delivery method. When I upload the file, the admin interface doesn't update the Downloaded File Name and Local File Path fields as it ordinarily does. And when I check in the directory where digital downloads are saved, I don't see any file uploaded with today's date. I last added a product with a digital download on 7/12 using the previous version of Miva and I had no issues then.
We have added a bug on this issue, currently the best workaround is to create a non-admin user and assign that user the view, add, and modify privileges for both products and digital downloads. With that user you will be able to update the product with the new digital download file correctly.
Hope this helps
-Eric
Eric Foresman
Software Tester
Miva Merchant
http://www.mivamerchant.com/
[email protected]
Comment
-
Originally posted by Mike521w View PostThis isn't particular to 9.10.x but I'm not sure where else to report it (and my apologies if it's already been reported elsewhere).
When using Amazon Pay, the customer goes through an alternative checkout flow. If there's an error (cart contents changed, payment issue, etc) the customer gets sent back to the default checkout flow instead of the Amazon one. I opened a ticket for a related issue because we're about to test an alternative checkout flow, and I noticed the Amazon Pay issue when I checked what would happen there under the same circumstances.
So to reproduce:- add items to cart and proceed to checkout using Amazon Pay
- get to AMAZONPAY_OPAY screen
- in a separate tab, open your cart and change the quantity of an item
- in the original tab (still on AMAZONPAY_OPAY) refresh the page
- you should be redirected (I think to OCST if I remember right) with a message saying that the cart contents changed during checkout
EDIT: I was able to work around the issue using TemplateManager_Render_Page
I have added a bug for this issue, thanks for letting us know about it.
-Eric
Eric Foresman
Software Tester
Miva Merchant
http://www.mivamerchant.com/
[email protected]
Comment
-
I'm seeing some odd behavior in the admin. It happened just now: a client asked me to take a look at some admin settings in their store, so I logged in, had a look, and then reported what I had seen. The client told me, no, those weren't the correct settings, and I should clear my browser cache and look again.
I thought that was wrong, but I did log back into admin, and have another look at the page, and it was the same as I had seen before. Then I clicked the Reset button; and some of the settings changed! I'm referring to the Reset button on the page, not something in my browser (Firefox, latest version, on Windows 8). I don't think that could be a browser problem. Has anyone else seen this?
Thanks --Kent Multer
Magic Metal Productions
http://TheMagicM.com
* Web developer/designer
* E-commerce and Miva
* Author, The Official Miva Web Scripting Book -- available on-line:
http://www.amazon.com/exec/obidos/IS...icmetalproducA
Comment
-
shipping method rules rate adjustment doesn't allow negative value (NOT shipping settings tab)
I found on two different stores that are on 9.10.1 that
There are two areas where you can apply rate adjustments.. one is the shipping:settings: tab and I am not talking about this adjustment which affects ALL methods in the store.
The second is on the shipping: shipping method rules tab where you can alter the display name of each shipping method rule and also add a per method rate adjustment.
This rate adjustment doesn't allow negative values. It should.
I need to have 2.45 added too ALL but two methods in my store. I need to have a free shipping method and a will call available. I used the flat rate method to accomplish this. I do have a shipping:settings storewide 2.45 added to all my shipping rules. So I thought I could zero that out by going to the shipping method rule for the free shipping flat rate and setting the adjustment for that to 2.45.
However it isn't working.
note: I also can not just simple put the 2.45 on all the other rates in the shipping method rules tab.. because I have to do a % adjustment to all our UPS rates coming from UPS.
So I already use the storewide shipping :settings: 2.45 and the shipping method rules % for all the UPS. That works because we only need positive values in those two rate adjustments.
But I REALLY need free shipping and will call to end up being zero.
I think this is a bug involved with the shipping rate methods area of the admin.
Comment
-
The product level rate adjustment can be both positive and negative. The issue here is that you're also using the Handling Charge to change the rate which is a completely separate adjustment. That handling charge gets added after any shipping method level rate adjustments.
You can accomplish what you're trying to do with a Free Shipping Price Group. Create a new price groups and give your free shipping and will call methods a 100% discount. This discount will overwrite your handling charge for these methods and give you what you're looking for.
I think an improvement to the handling charge section is also needed to allow for product level overrides which would have also helped in this case. I'll see if we can get this added in a future version.
Comment
-
From your explanation.. am I interpreting correctly that it has to do with the order in which the rate adjustments are applied? And that at no time can shipping be a negative value?
Thus if the shipping method rate adjustment on the shipping method rules screen is applied first, and not allowed to go below 0. Even if I put a -2.45 there, on a 0.00 shipping rate, the shipping can never be -2.45, so it is zero; and then the storewide setting applies at the end which then adds the 2.45 to the shipping total?
product level adjustments won't help in this case. I would have to add that to every single product and every single new product in the store.. that would be insane with thousands and thousands of products which we have.
Free shipping can be handled with the price group. I am implementing that, we use it only with coupons anyway, so that is perfect.
However, we still need a will call shipping method that is $0. A few local customers are allowed to bring trucks and pickup their orders if they order over $1000 from us. Other shipping methods have to be a available to those customers though, sometimes they have us ship to a non local location instead of picking up. So I need the will call $0.00 as well as the other shipping methods to appear for those. How do I handle that?
Comment
-
Originally posted by kayakbabe View Postshipping method rules rate adjustment doesn't allow negative value (NOT shipping settings tab)
I found on two different stores that are on 9.10.1 that
There are two areas where you can apply rate adjustments.. one is the shipping:settings: tab and I am not talking about this adjustment which affects ALL methods in the store.
The second is on the shipping: shipping method rules tab where you can alter the display name of each shipping method rule and also add a per method rate adjustment.
This rate adjustment doesn't allow negative values. It should.
I need to have 2.45 added too ALL but two methods in my store. I need to have a free shipping method and a will call available. I used the flat rate method to accomplish this. I do have a shipping:settings storewide 2.45 added to all my shipping rules. So I thought I could zero that out by going to the shipping method rule for the free shipping flat rate and setting the adjustment for that to 2.45.
However it isn't working.
note: I also can not just simple put the 2.45 on all the other rates in the shipping method rules tab.. because I have to do a % adjustment to all our UPS rates coming from UPS.
So I already use the storewide shipping :settings: 2.45 and the shipping method rules % for all the UPS. That works because we only need positive values in those two rate adjustments.
But I REALLY need free shipping and will call to end up being zero.
I think this is a bug involved with the shipping rate methods area of the admin.
I don't know if this will work for your setup, but you can get the shipping method rate to go negative by using the rate adjustment in percent mode.
In this case you would set the price of the free shipping to $2.45 then set the Rate Adjustment to be -200%. This will get you the -$2.45 that you are looking for.
Hope this helps
-Eric
Eric Foresman
Software Tester
Miva Merchant
http://www.mivamerchant.com/
[email protected]
- 1 like
Comment
-
ohhh that might just work! It's a bandaid.. but it'll work! Thanks!
It is so odd though.
if I set the flat rate method to 1.00 and the shipping settings handling charge to always, include in shipping rate 1.00
then in shipping method rules for the flat rate method I set percent -200
The shipping will appear as 0.
but if I use all the same settings except have the shipping method rule set to fixed -2.00
It shows a shipping amount of $1
I have to conclude the bandaid works, but the shipping method rule rate adjustment is buggy. whether % or fixed, it should work the same way and it doesn't.
I would also expect that the shipping method rules would be applied last. But they aren't and they are applied in a different order if fixed or percent.
note: Also a different bug that I previously reported, the shipping method rule display as setting isn't carried throughout the store system, it only displays on the checkout shipping selection. It should be shown on the invoice and order downloading and wherever the shipping method is displayed or is used.
Last edited by kayakbabe; 07-24-18, 04:30 PM.
Comment
-
Originally posted by kayakbabe View Postohhh that might just work! It's a bandaid.. but it'll work! Thanks!
It is so odd though.
if I set the flat rate method to 1.00 and the shipping settings handling charge to always, include in shipping rate 1.00
then in shipping method rules for the flat rate method I set percent -200
The shipping will appear as 0.
but if I use all the same settings except have the shipping method rule set to fixed -2.00
It shows a shipping amount of $1
I have to conclude the bandaid works, but the shipping method rule rate adjustment is buggy. whether % or fixed, it should work the same way and it doesn't.
I would also expect that the shipping method rules would be applied last. But they aren't and they are applied in a different order if fixed or percent.
note: Also a different bug that I previously reported, the shipping method rule display as setting isn't carried throughout the store system, it only displays on the checkout shipping selection. It should be shown on the invoice and order downloading and wherever the shipping method is displayed or is used.
The functionality of the shipping rate adjustment is deliberate, when using a fixed negative adjustment say -$5.00, and a generated shipping rate from say UPS this would work fine as long as all shipping rates were above $5.00. should you get a shipping rate from UPS that was only $1.00 you would end up with a -$4.00 shipping rate. In some cases this would prevent you from checking out as PayPal does not allow a negative value for shipping methods. Also, what was intended as a $5 discount on shipping has just become a $5 discount on the entire order. In order to solve that bug we put in a check to prevent a fixed negative adjustment from setting the shipping rate below $0.00.
In the case of the percentage negative rate adjustment, if you deliberately set an adjustment of -200% then you as the store owner are specifically asking for a negative shipping rate not accidentally getting a negative shipping rate when UPS doesn't charge much.
For the second issue, in my store the shipping method rules “display as” setting does get displayed on all pages during checkout and is used in admin as well. It maybe there needs to be a template change in order to see that instead of default shipping method name? I'm just using the current default framework as of mm9.10.Eric Foresman
Software Tester
Miva Merchant
http://www.mivamerchant.com/
[email protected]
Comment
-
Provisioning Issues
with <Product_Update code="PRODUCT_CODE"> vs way it works compared with the custom field provisioning tag and Miva 5
1. in miva 5, the product update code doesn't have to match on case, ie. aa716-Blue and aa716-BLUE would update the same record.
Now I find in Miva 9.10.1 that it does not. the code for the <Product_Update has to match.
2. now that the product update code has to match, it seems odd that the <Product_CustomField module="customfields" product="PRODUCT_CODE"
does NOT have to match and it still updates.
I think there is probably a bug in <Product_Update where it is now checking for a case.. when it didn't use to.
or if this was intentionally changed... then ALL xml import provisioning tags should check for the case on the product code.
however I don't think case should matter, I've been in retail for many years and it doesn't matter. the uniqueness matters on sky's. There are so many different systems, Mac, apache, Microsoft, etc. I think aa716, AA716, aA716 should all match, and use store owner should keep these very unique for each product. aA716 Aa716 AA716 should NOT be different products.
Here is my example I just imported
<Product_Update code="AA716-Blue"><cost>3.09</cost><price>10.30</price></Product_Update><Product_CustomField module="customfields" product="AA716-Blue" field="RETAILPRIC">10.30</Product_CustomField>
Price didn't update and store gave me error that "8-2-2018 16:35:41 24 Product_Update: Product with the code 'AA716-BLUE' already exists"
but the custom field DID update. And we all should expect that the product already exists as we are updating not adding.
this error is what I would have expected to see if I has used <Product_Add><code>AA716-blue</code></Product_Add>
so I suspect there is some issue with provisioning.
Comment
-
Originally posted by kayakbabe View PostProvisioning Issues
with <Product_Update code="PRODUCT_CODE"> vs way it works compared with the custom field provisioning tag and Miva 5
1. in miva 5, the product update code doesn't have to match on case, ie. aa716-Blue and aa716-BLUE would update the same record.
Now I find in Miva 9.10.1 that it does not. the code for the <Product_Update has to match.
2. now that the product update code has to match, it seems odd that the <Product_CustomField module="customfields" product="PRODUCT_CODE"
does NOT have to match and it still updates.
I think there is probably a bug in <Product_Update where it is now checking for a case.. when it didn't use to.
or if this was intentionally changed... then ALL xml import provisioning tags should check for the case on the product code.
however I don't think case should matter, I've been in retail for many years and it doesn't matter. the uniqueness matters on sky's. There are so many different systems, Mac, apache, Microsoft, etc. I think aa716, AA716, aA716 should all match, and use store owner should keep these very unique for each product. aA716 Aa716 AA716 should NOT be different products.
Here is my example I just imported
<Product_Update code="AA716-Blue"><cost>3.09</cost><price>10.30</price></Product_Update><Product_CustomField module="customfields" product="AA716-Blue" field="RETAILPRIC">10.30</Product_CustomField>
Price didn't update and store gave me error that "8-2-2018 16:35:41 24 Product_Update: Product with the code 'AA716-BLUE' already exists"
but the custom field DID update. And we all should expect that the product already exists as we are updating not adding.
this error is what I would have expected to see if I has used <Product_Add><code>AA716-blue</code></Product_Add>
so I suspect there is some issue with provisioning.
Thanks for letting us know about this issue, we have a bug in for it.
Thanks again
-Eric
Eric Foresman
Software Tester
Miva Merchant
http://www.mivamerchant.com/
[email protected]
Comment
Comment