Announcement

Collapse
No announcement yet.

9.00065 was there, now missing.

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    9.00065 was there, now missing.

    Afternoon all,
    We have been anxiously awaiting the 9.00065 update for cvv integration. When I logged in this afternoon, it showed that the update was there to be installed. I wanted to read the release notes before installing (which I did). However, when I logged back into the admin interface, the update button was gone. The banner noting that 65 is available is still there, but no update button. When I look on the right side, it shows I am still on 64 (not a surprise as I didn't start the process). Am I missing something? I have tried logging out and logging back in - but - it's gone.

    #2
    The banner and the button are two different things. I wish the banner would disappear after the update is run as it causes a bit of confusion. As for why the button disappeared even though you didn't run the update, that is another question. What are your settings for checking for updates? Once a day or at every log in?
    Leslie Kirk
    Miva Certified Developer
    Miva Merchant Specialist since 1997
    Previously of Webs Your Way
    (aka Leslie Nord leslienord)

    Email me: [email protected]
    www.lesliekirk.com

    Follow me: Twitter | Facebook | FourSquare | Pinterest | Flickr

    Comment


      #3
      Every login. Yeah, it's just gone. The button was there - as was the banner - now it's just the banner. Which you know...doesn't help :)

      Comment


        #4
        Hopefully Brennan will have a minute to chime in (he's busy getting ready for MivaCon17), they may have needed to pull the update for some reason.
        Leslie Kirk
        Miva Certified Developer
        Miva Merchant Specialist since 1997
        Previously of Webs Your Way
        (aka Leslie Nord leslienord)

        Email me: [email protected]
        www.lesliekirk.com

        Follow me: Twitter | Facebook | FourSquare | Pinterest | Flickr

        Comment


          #5
          Yeah, it's looking like it was pulled...bummer.

          Comment


            #6
            We made some performance optimizations for sites using ReadyThemes and we have at least one live site have the opposite impact. We pulled the patch while we review that live site for issues. We'll be back shortly and announce it here.
            Thanks,

            Rick Wilson
            CEO
            Miva, Inc.
            [email protected]
            https://www.miva.com

            Comment


              #7
              We made some performance optimizations for sites using ReadyThemes and we have at least one live site have the opposite impact. We pulled the patch while we review that live site for issues. We'll be back shortly and announce it here.
              Not sure if this is related or not, but l.settings:readytheme:layout is getting overridden to "single-column", causing existing navigation items specified as "Horizontal Mega-Menu" to revert to horizontal dropdowns after 9.65 upgrade. This especially impacts the Suivant theme which relies on that menu type. Quick workaround is to manually overwrite "&mvte:readytheme:layout;" in the Main Navigation Bar item template to "horizontal-mega-menu".

              Comment


                #8
                Dan, I've been told a fix for that will be ready today.
                David Hubbard
                CIO
                Miva
                [email protected]
                http://www.miva.com

                Comment


                  #9
                  Originally posted by ILoveHostasaurus View Post
                  Dan, I've been told a fix for that will be ready today.
                  Thanks for the update David. The store that initially brought this to our attention had a deep menu. In conjunction with the sticky global header, this made the navigation unusable so we implemented the workaround. We are currently running through client stores to see which ones are especially bad and trying to notify, but a lot of our east coast clients have already shut down for the day.

                  Comment


                    #10
                    Were we not supposed to install the 9.0065 update? I installed that and then the 9.0066 update showed up later & then I installed that. I'm using the ready theme on my dev site



                    Kathleen Steimle-Hermes
                    , owner
                    Miss Kate's Creations
                    [email protected]
                    www.misskatescreations.com


                    Handcrafted fabric covered photo albums, frames, brag books and MORE


                    Comment


                      #11
                      There was an issue that was detected in the new optimization code nearly immediately after release, which caused the update to be put on hold, so at that point only those who had already applied it had it, and the rest were on hold. New code was added to detect the issue, and block installation on stores that would be negatively impacted by applying the update, then it was re-released. Later in the afternoon, the next release came out which corrected a problem related to certain themes. So at this point, we believe the latest update is safe to apply, as the criteria that can cause the performance issue will block installation, and the other bug has been corrected. If you do have a store where the performance degradation (instead of improvement) could result, the update will not allow you to proceed and will instead ask you to click to create a support ticket, and then our staff will investigate and help you through the next steps.
                      David Hubbard
                      CIO
                      Miva
                      [email protected]
                      http://www.miva.com

                      Comment


                        #12
                        Originally posted by ILoveHostasaurus View Post
                        There was an issue that was detected in the new optimization code nearly immediately after release, which caused the update to be put on hold, so at that point only those who had already applied it had it, and the rest were on hold. New code was added to detect the issue, and block installation on stores that would be negatively impacted by applying the update, then it was re-released. Later in the afternoon, the next release came out which corrected a problem related to certain themes. So at this point, we believe the latest update is safe to apply, as the criteria that can cause the performance issue will block installation, and the other bug has been corrected. If you do have a store where the performance degradation (instead of improvement) could result, the update will not allow you to proceed and will instead ask you to click to create a support ticket, and then our staff will investigate and help you through the next steps.
                        I may have a theory about this since I've now had two stores "block" the update. Both stores used the MMUI to CSSUI converter. What pointed me to this is one of the sites has 2 dev sites. I was able to update one without any issues - it was still MMUI. The other version had had the converter run on it.

                        I'll try to keep watch on this since I've used the converter on a few sites.



                        Leslie Kirk
                        Miva Certified Developer
                        Miva Merchant Specialist since 1997
                        Previously of Webs Your Way
                        (aka Leslie Nord leslienord)

                        Email me: [email protected]
                        www.lesliekirk.com

                        Follow me: Twitter | Facebook | FourSquare | Pinterest | Flickr

                        Comment


                          #13
                          Originally posted by lesliekirk View Post

                          I may have a theory about this since I've now had two stores "block" the update. Both stores used the MMUI to CSSUI converter. What pointed me to this is one of the sites has 2 dev sites. I was able to update one without any issues - it was still MMUI. The other version had had the converter run on it.

                          I'll try to keep watch on this since I've used the converter on a few sites.


                          The issue is not related to the converter; in fact, if a store were recently converted, the issue would not occur because ALL the database tables would be created at the same time.

                          The issue primarily affects stores which have been MySQL-based for many years, and most likely, have moved servers at least once. The cause is differences in the default character set MySQL has used for its tables across its versions. Some versions used latin1, some used UTF8, and Merchant does not choose one explicitly, so whatever is the default for the version of MySQL in use at the time, that's what you end up with for a new table Merchant creates when new tables are necessitated by new features. We will likely make the choice explicit soon to avoid this issue in the future.

                          So, if, over time, the site in question moves between servers and the version of MySQL in place on a different server has a different default character set, and new features in Merchant cause the creation of more new tables, then those tables end up with a different character set than the older ones. For the vast majority of stores, this was an inconsequential characteristic. However, the new performance improvements involve SQL queries that are not compatible with certain tables being a different character set from one another; in that situation, the improvement turns into a massive degradation instead. So, the upgrader blocks until it can be fixed.

                          Fixing, for most stores, is very easy for our support staff. However, some stores make use of certain characters that could potentially be incorrectly translated during conversion, so in those instances we give examples of what could occur and ask for permission to perform the conversion. The issue mostly affects 'special' latin1 characters, such as Microsoft's fancy curly quote marks (which won't render correctly in the forum since it uses UTF8) or other high characters like È, ä, so on and so forth. Most stores do not use those characters in their product or category data (the two affected tables) if the data was produced by typing into a US keyboard, but some stores do have these if they imported their product data, or someone on a non US-English keyboard typed them. Converting them may turn those characters into something else unpredictably. In those cases we try to give examples, a word of warning, a complete list of what would be possibly affected product codes, and then get permission to perform the conversion so the upgrade can proceed.
                          David Hubbard
                          CIO
                          Miva
                          [email protected]
                          http://www.miva.com

                          Comment


                            #14
                            Originally posted by ILoveHostasaurus View Post

                            The issue is not related to the converter; in fact, if a store were recently converted, the issue would not occur because ALL the database tables would be created at the same time.

                            The issue primarily affects stores which have been MySQL-based for many years, and most likely, have moved servers at least once. The cause is differences in the default character set MySQL has used for its tables across its versions. Some versions used latin1, some used UTF8, and Merchant does not choose one explicitly, so whatever is the default for the version of MySQL in use at the time, that's what you end up with for a new table Merchant creates when new tables are necessitated by new features. We will likely make the choice explicit soon to avoid this issue in the future.

                            So, if, over time, the site in question moves between servers and the version of MySQL in place on a different server has a different default character set, and new features in Merchant cause the creation of more new tables, then those tables end up with a different character set than the older ones. For the vast majority of stores, this was an inconsequential characteristic. However, the new performance improvements involve SQL queries that are not compatible with certain tables being a different character set from one another; in that situation, the improvement turns into a massive degradation instead. So, the upgrader blocks until it can be fixed.

                            Fixing, for most stores, is very easy for our support staff. However, some stores make use of certain characters that could potentially be incorrectly translated during conversion, so in those instances we give examples of what could occur and ask for permission to perform the conversion. The issue mostly affects 'special' latin1 characters, such as Microsoft's fancy curly quote marks (which won't render correctly in the forum since it uses UTF8) or other high characters like È, ä, so on and so forth. Most stores do not use those characters in their product or category data (the two affected tables) if the data was produced by typing into a US keyboard, but some stores do have these if they imported their product data, or someone on a non US-English keyboard typed them. Converting them may turn those characters into something else unpredictably. In those cases we try to give examples, a word of warning, a complete list of what would be possibly affected product codes, and then get permission to perform the conversion so the upgrade can proceed.
                            Okay, understood. The support techs replying to tickets being opened by the simple click of the "Request Assistance" button in the failure window have been great about explaining all this. I understand the need to explain it, but I guess Rick left me thinking it was just going to be an easy fix that wasn't going to take a lot of intervention. That would explain why store owners are now being ask for verification.

                            Requests of this nature require verification of the associated account by confirming one of the following items, which can be provided by replying back to this e-mail or by calling in to our support line listed below:

                            • * Security Passphrase
                            • * Last 4 digits of credit card number currently on file as the default billing account.
                            • * Last 4 digits of the last check number used for payment.
                            I think I do have a number of store owners who like to copy and paste from Microsoft Word...but they are also really being freaked out by this too.





                            Leslie Kirk
                            Miva Certified Developer
                            Miva Merchant Specialist since 1997
                            Previously of Webs Your Way
                            (aka Leslie Nord leslienord)

                            Email me: [email protected]
                            www.lesliekirk.com

                            Follow me: Twitter | Facebook | FourSquare | Pinterest | Flickr

                            Comment


                              #15
                              Yes, copy/paste from Word could potentially create a problem because it may introduce a few microsoft-specific proprietary characters. You can see them in this chart:

                              http://casa.colorado.edu/~ajsh/iso8859-1.html

                              I believe the bullet character may be one of the more common ones in addition to the 'fancy' quote marks (numbers 147/148 on that page). Those characters may end up looking like something else post-conversion from latin1 to UTF8. Fortunately in stores that were manually prepared with cut/paste, the number of affected products is probably not going to be too heavy to check manually afterward.
                              David Hubbard
                              CIO
                              Miva
                              [email protected]
                              http://www.miva.com

                              Comment

                              Working...
                              X