Announcement

Collapse
No announcement yet.

Miva Merchant 10.00.x Bug Reports

Collapse
This is a sticky topic.
X
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Southlander
    replied
    Shadows Readytheme (browsing on mobile) - There is a login bug on the OINF page, **on just Android** far as I can test/confirm and have others test. When you select "Click here to log in" -- that form. It auto closes when you touch inside (for example) the login ID field to input your login. Thus there is no way to log in at that point in the checkout process. It works normally on iOS and also a desktop browser.
    Screenshot_2022-07-25-04-30-32-63_dc00545bd3b8828f033a02ac25b2d36d.jpg

    Leave a comment:


  • Jim McCormick
    replied
    I've created a ticket in our support system and just emailed you from the ticket so we can collect some more information on this.

    Originally posted by William Davis View Post
    URGENT! - Unable to "301 Redirect to Canonical" legacy URI with illegal character(s) and/or space(s).

    Upon attempting to correct legacy URI with illegal characters and/or space(s), the following message is displayed (screenshot):



    Note: Attempt was made to temporarily disable Admin > Domain Settings > Site Configuration > Use Strict Validation Codes, in order to circumvent error displayed in above screenshot, but was unsuccessful. Thus, "Use Strict Validation Codes" feature was re-enabled.

    Proposed Solution: Permit authorized Admin users to "301 Redirect to Canonical" URIs with illegal characters and/or space(s).

    History: Though store operates on Miva Merchant latest version, it originally had "Use Strict Validation Codes" feature disabled from it's "MM4.24c Open UI" days as a work around in order to permit customers to use their email address ("@" symbol) as their user ID. Since the store has always used product and category codes as part of their URI structure (e.g.: https://www.abc.com/[prod_code].html), any illegal character(s) and/or space(s) used in these "code" fields would subsequently generate comparable URI.

    Ideally, when "Use Strict Validation Codes" feature is enabled, the platform should perform a check for any illegal character(s) and/or space(s) violations prior to permitting the use of said feature and provide an option to generate an error log.

    Example:

    PRODUCT_CODE|CANONICAL_URI

    Leave a comment:


  • William Davis
    replied
    URGENT! - Unable to "301 Redirect to Canonical" legacy URI with illegal character(s) and/or space(s).

    Upon attempting to correct legacy URI with illegal characters and/or space(s), the following message is displayed (screenshot):



    Note: Attempt was made to temporarily disable Admin > Domain Settings > Site Configuration > Use Strict Validation Codes, in order to circumvent error displayed in above screenshot, but was unsuccessful. Thus, "Use Strict Validation Codes" feature was re-enabled.

    Proposed Solution: Permit authorized Admin users to "301 Redirect to Canonical" URIs with illegal characters and/or space(s).

    History: Though store operates on Miva Merchant latest version, it originally had "Use Strict Validation Codes" feature disabled from it's "MM4.24c Open UI" days as a work around in order to permit customers to use their email address ("@" symbol) as their user ID. Since the store has always used product and category codes as part of their URI structure (e.g.: https://www.abc.com/[prod_code].html), any illegal character(s) and/or space(s) used in these "code" fields would subsequently generate comparable URI.

    Ideally, when "Use Strict Validation Codes" feature is enabled, the platform should perform a check for any illegal character(s) and/or space(s) violations prior to permitting the use of said feature and provide an option to generate an error log.

    Example:

    PRODUCT_CODE|CANONICAL_URI

    Leave a comment:


  • Eric Foresman
    replied
    Originally posted by [email protected] View Post
    I was doing some testing with coupons. I am seeing an issue during Checkout, but I don't experience it in the Basket (edit cart) page. The Basket page works as expected.

    Once a coupon has been applied, it appears you can add another coupon to the order, but the + sign is no longer active.
    There is not the ability to delete a coupon from the Checkout page. You have to go to the Basket page to delete it.

    ScreenHunter_1829 Jun. 18 11.02.jpg

    I also experienced the same behavior if an incorrect code was typed. If the user made a typo, they cannot click the + and try again.


    ScreenHunter_1830 Jun. 18 11.09.jpg


    Hi Shannon, i have reproduced this and field a bug for it. thanks for the info

    -Eric

    Leave a comment:


  • shannon@xactx.com
    replied
    I was doing some testing with coupons. I am seeing an issue during Checkout, but I don't experience it in the Basket (edit cart) page. The Basket page works as expected.

    Once a coupon has been applied, it appears you can add another coupon to the order, but the + sign is no longer active.
    There is not the ability to delete a coupon from the Checkout page. You have to go to the Basket page to delete it.

    ScreenHunter_1829 Jun. 18 11.02.jpg

    I also experienced the same behavior if an incorrect code was typed. If the user made a typo, they cannot click the + and try again.


    ScreenHunter_1830 Jun. 18 11.09.jpg


    Leave a comment:


  • Jim Cockerham
    replied
    Originally posted by Ron Frigon View Post

    I've run into this issue before as well. Simple fix is to just wrap the restore link in a conditional. A message could easily be added as well.

    Code:
    <mvt:if expr="l.settings:group:product:code"><a class="u-font-small u-color-green" href="&mvte:group:restore:link;">Reorder</a></mvt:if>
    Nice Ron! That's works nicely, thank you. I added a check to see if the product was active so that inactive products don't give the error.
    Code:
    <mvt:if expr="( l.settings:group:product:code ) AND (l.settings:group:product:active )"><a class="u-font-small u-color-green" href="&mvte:group:restore:link;">Reorder</a></mvt:if>

    Leave a comment:


  • Ron Frigon
    replied
    Originally posted by Jim Cockerham View Post
    When a customer tries to "Reorder" a product from a previous order on the ORDS screen, they will receive a Fatal Error if the product is no longer available or if the product code has changed. I don't know that this is really a bug, but it seem like there should be a more friendly error message.
    I've run into this issue before as well. Simple fix is to just wrap the restore link in a conditional. A message could easily be added as well.

    Code:
    <mvt:if expr="l.settings:group:product:code"><a class="u-font-small u-color-green" href="&mvte:group:restore:link;">Reorder</a></mvt:if>

    Leave a comment:


  • Jim Cockerham
    replied
    When a customer tries to "Reorder" a product from a previous order on the ORDS screen, they will receive a Fatal Error if the product is no longer available or if the product code has changed. I don't know that this is really a bug, but it seem like there should be a more friendly error message.

    Leave a comment:


  • William Davis
    replied
    Admin > Product > Product Code field should never permit illegal URI characters when product code is being used as part of URI (e.g.: blank spaces, number sign, etc.).

    Example:

    .../test- #12345.html

    This is a nightmare to fix because unlike Product Code field, URI screen does check for errors so how does one correct can URI to perform a 301 redirect?

    Update: Since my initial post, I've been advised that such a feature has been in existence for many years. I later came across on old post on the forums by me when on MM4.24c OpenUI, discussing the disabling of said feature in order to enable customers the ability use their email address as their users id as a workaround. I have enable this feature to avoid further problems in the future. Apologies for my confusion.
    Last edited by William Davis; 06-03-22, 06:28 AM.

    Leave a comment:


  • shannon@xactx.com
    replied
    I didn't see this in the list of bugs, so I'll pile another one onto the Product Copy feature. The attribute template option "default" setting does not copy over.

    Original product is using just attributes & options, no attribute template. Copied product attributes are correct, but we lose the selection for the default option and have to manually go and set it on each copy.

    Miva Merchant 10.02.00
    MivaScript Enginev5.36
    Database APImysql

    Leave a comment:


  • lesliekirk
    replied
    Originally posted by jstinsch View Post
    I wasn't sure if this was the best place to get help, but my company has been having issues ever since we updated to 10.03.01. We have had a large sum of customers who once they get to the shipping options page and click continue after they select their shipping speed, nothing happens. So they are just forever stuck at this page with nothing further even attempting to load. The IT department consists of just me and my manager and I have been trying to work with our customers to try and find out what is causing this, but we have not been able to find a rhyme or reason as to fix this issue. Has anyone else been having this problem?
    Are you using any sort of Address Verification?

    Leave a comment:


  • jstinsch
    replied
    I wasn't sure if this was the best place to get help, but my company has been having issues ever since we updated to 10.03.01. We have had a large sum of customers who once they get to the shipping options page and click continue after they select their shipping speed, nothing happens. So they are just forever stuck at this page with nothing further even attempting to load. The IT department consists of just me and my manager and I have been trying to work with our customers to try and find out what is causing this, but we have not been able to find a rhyme or reason as to fix this issue. Has anyone else been having this problem?

    Leave a comment:


  • lesliekirk
    replied
    Issues with how the included version of Shadows is handled as it related to stores that have older versions of Shadows installed.

    Item 1- I have run into an issue with a site that had a version of Shadows installed. When Miva had an update for Shadows it updates whatever version of Shadows is installed in the store. Thankfully it does not apply the framework to the templates. But the store shows that latest version of Shadows as the "Active" Framework. This is very misleading. In this case the store shows in the (Production Primary) Framework screen that Shadows 2.03.00 is the Active Framework with a Last Applied date of 4-8-2022 and Created Date of 3-29-2022. This is incorrect. In this store (Production Primary) Framework Shadows was applied on 8-5-2021 and was never "updated". I have no idea which version of Shadows is actually applied because of the way Shadows is updated.

    Item 2 - (and might be a bug) I created a Branch (after first saving the Production Framework). I applied the latest version of Shadows to the new Branch. When I went to compare the Production Branch to the new Dev Branch (using the development preview) I noticed issues with the look & feel of the Production Branch. I created a third branch and applied the saved framework to it. I was expecting the Production Branch to look just like the saved framework branch but it didn't. I suspected an issue with the CSS files. I opened the site up via FTP and stated comparing file modified dates. In the Production directory /mm5/themes/00000001/shadows the dates on these files jumped right out at me:

    core.css
    core.js
    extensions.css
    extensions.js
    polyfills.js
    theme.css
    theme.js

    All of these files had the same time stamp as the Branch I created for the newest version of Shadows. I dug into other folders and discovered changes there too. The clue that gave it all away was the theme.css file. I had had an annotated version of the theme.css in the Production version and it had been overwritten when I installed the latest Shadows version into the Branch. I did notice that the folder dates for the Production directory /mm5/themes/00000001/shadows had the "correct" dates from when the ReadyTheme was first applied. But it went in an updated files in folders such as:

    ​​​​​​/mm5/themes/00000001/shadows/core/images
    /mm5/themes/00000001/shadows/extensions/contact

    Granted these updates might not be a bad thing but overwriting the theme.css that is not good. What is did to the entire Production version of Shadows is not good. I suspect the problem might be related to Item 1.

    And as a side note, when I did apply the Shadows 2.03.00 to the branch, in addition to the ReadyTheme categories (I thought there were plans to not allow the framework to add these categories), some how categories that had been deleted back last fall right after the initial set up of the dev site were resurrected and re-added to the site.

    FWIW - I really like having a copy of the current version of the UI but it really needs to not have the ability to overwrite the UI I 'm using just because they are the same file name.

    Leave a comment:


  • SidFeyDesigns
    replied
    Hi Eric Foresman

    I actually noticed that in the Template Branches there was no issue.

    We use Redis and I know in the Template Branches, Redis will not cache the page templates.

    So I disconnected Redis and the issue went away in the Production Branch as well.

    We do have some Transients set up with Tess's Module, so maybe there is a conflict.

    I don't believe the issue was with the recent update, although I can't say for sure.

    We started using Redis (early March) before the update rolled out so the issue could have already been there and I just didn't notice until now.

    I'll create a ticket though and see if they can help me track down what is causing this to happen when Redis is turned on.

    Thanks

    Leave a comment:


  • Eric Foresman
    replied
    Originally posted by SidFeyDesigns View Post
    The Smart Breadcrumbs don't seem to be functioning like they used to.

    Prior to the update products could be assigned to multiple categories and the breadcrumbs would match the path you took to get to the product.

    Now it only shows the path based on the product's canonical category code.

    Ex:

    Product 1 is assigned to Category 1, Category 2 and Category 3 with Category 1 being the canonical category

    Breadcrumbs Before update:

    Path 1: Category 1 > Product 1
    Breadcrumbs: Category 1 > Product 1

    Path 2: Category 2 > Product 1
    Breadcrumbs: Category 2 > Product 1

    Path 3: Category 3 > Product 1
    Breadcrumbs: Category 3 > Product 1

    Breadcrumbs After update:

    Path 1: Category 1 > Product 1
    Breadcrumbs: Category 1 > Product 1

    Path 2: Category 2 > Product 1
    Breadcrumbs: Category 1 > Product 1

    Path 3: Category 3 > Product 1
    Breadcrumbs: Category 1 > Product 1

    Is this the new intended functionality or is this a bug?

    Or shall I contact support in the event that it could be due to custom code within our templates?

    Thanks in advance.
    Hi SidFeyDesigns

    I’m not able to reproduce that issue in my test store. Did you have any luck tracking this down with support?

    Thanks

    -Eric

    Leave a comment:

Working...
X