No announcement yet.

Warning Dynamik 1.3 update ruined my font sizes !!!

  • Filter
  • Time
  • Show
Clear All
new posts

  • Warning Dynamik 1.3 update ruined my font sizes !!!

    In case you hesitate to update a production install to 1.3 BE WARNED : it completely ruined my font sizing !!!

    Somehow this updates change em into rem... but doesn't do it correclty.

    I'll send a support request but in the meantime I'm striving to revert my site to the previous version, damn it I hate badly tested upgrades

  • #2
    Yes, the default for fonts was changed to rem and yes, this might change your font-sizes (funny enough it worked for me on one site and not on another, seems to depend on previous settings). So I just went through my settings in Dynamik and put it right, but of course this is a pain if you have to do this on many sites...


    • #3
      Well there is 100% a bug :

      Body font changed from 18px to.... 18rem instead of 1.8rem !

      I'm pretty sure most of the issues come when you migrate a site which was in "em".


      • #4
        The thing is changes such as "we'll change the default font styling and move from em to rem" should NOT be a small line in the change-log !!!

        Anything which could make your client go MAD should NOT be a small-print in the changelog !!


        • #5
          Hi. That's the reason I wrote two days ago here:

          Keep in mind:
          Make a complete backup (files and database)
          Export Dynamik Design
          Export Dynamik Settings

          When you are done with this, you have a complete backup-site for reconstruction your website, if something fails with update to DWB 1.3

          After updating to DWB 1.3:
          import dynamik design
          import dynamik settings!

          That's what I have done. Before the imports my website looked crashed, with huge fonts etc

          Every webmaster should know, that he has to make a complete backup, before every update. So go back to the previous version and export and import the DWB (design & settings).

          But I agree, this is an enormous effort for clients. Not the backup thing - this is something they should learn pressing, if they want to update their sites themselves. But import / exoprt DWB thing not obligatory. Since you also have the option to deactive the access to DWB in their account.


          • #6
            I would love to see Beta or "unstable" releases in the future to avoid these types of ongoing issues. It would save people lots of heartache and time both for their own sites as well as their client sites. If a product hasn't been tested for weeks by a variety of professionals, these types of things are almost certain to happen. Since Cobalt is not a large crew, using your audience would be idea since they are going to eventually get the updates anyway. When updates here are released, they are typically considered stable by customers and ready to go. With a small company, beta testing is ideal. I would rather have stable and properly functioning features and products instead of a big surprise that doesn't work properly but instead causes more work to be fixed.That being said, why not release a beta version where people can take the new changes, test them extensively for a few weeks while providing feedback? This would give them the heads-up to use them at their own risk and knowing ahead of time that bugs and issues may exist. This also lets them know to use them on test sites and not client sites. Then when all known issues are corrected, then release a stable version? Releasing an update that is considered stable and that hasn't been tested extensively is problems waiting to happen.


            • #7
              @Jordanemery, so please do me the favour and explain me, what do you think is beta in this version?

              The only element that's not ideal is the increase of the font-size. Reason: EM has been changed to REM. This itself is no bug, but there should probably be a fall back solution to avoid huge font sizes after update ( in this point I agree). But all other changes of this version work without any problem.

              Au contraire: DWB 1.3 is a little bit like an awesome give away, with a lot of and very appreciated new features.


              • SiGa
                SiGa commented
                Editing a comment
                @La Geek: He didn´t write this version is a beta (you should maybe read that again). He meant there should be a beta first so it would be clear for members not to install it on live sites but to test it first and find the culprits - the improvements could go into the final "update" version then. Not the the badest idea, if I may say that.

            • #8
              @Siga: He wrote "I would love to see Beta or "unstable" releases in the future to avoid these types of ongoing issues" and he wrote this in this thread. And not in the feature suggestions thread. So I think, the question I asked Jordanemery is absolutely entitled.

              Btw. it is the nature of betas, that they should not be installed on live sites. But do you see any reason, that DWB 1.3 should not be installed on live sites? For me it is a stable release, that probably needs a little update for font-size fallback.


              • SiGa
                SiGa commented
                Editing a comment
                I´ll now leave it up to Jordan to explain how he meant it, if he wants to.
                "But do you see any reason, that DWB 1.3 should not be installed on live sites?". If there is no warning regarding the rem and I don´t want to go through all font settings again or do a rollback - and all this on a live site - then yes. An update shouldn´t change the frontend look of a site completely. I´d expect it to still look the same afterwards - no?

            • #9
              Hey guys,

              I've found the issue and hopefully solved it for future updates to version 1.3. In the vast majority of cases PX units are used exclusively and therefore this didn't show up clearly among our beta testers. So I've since added a function in the current version of DWB 1.3 that should properly convert your font sizes based on the various px/em/rem changes that take place in the update process.

              So this won't help with your sites that have already be updates to 1.3, but future updates should convert your font sizes properly. I also updated the "My Account" DWB 1.3 zip file so if you're doing manual updates then re-download that file and use it instead of what you may have already downloaded.

              I apologize for not catching this, but know that we did, as always, beta test before releasing. But I agree that releasing a beta version to all members, especially with larger updates like this one would not be a bad idea. It will slow down the release process, but in cases like this would be worth it.



              • #10
                La Geek,

                I am very sorry for now being more clear there. I would be happy to explain what I meant.

                First, I think that in the future, before releasing any update, releasing a beta version would be the best approach to avoid possible issues. Alpha testing is testing done within the company and select users of the product. Beta testing on the other hand is done by the end users which are those that use the product consistently and on a daily basis. Alpha testing, is good but it will never find all issues. Even small teams of 30 to 50 people that are professionals cannot even test a product and find all the issues. Instead, once Alpha testing is complete and the internal testers of the company cannot seem to find anymore issues, they release a beta version to general users where you have a much much bigger audience to test the product. This is where many more devices, internet connections, browsers, etc. are put to the test. Surprisingly, in the beginning of the beta stage you would not expect to see many issues since alpha testing gave it a thorough scrub right? Instead, lots of other issues that were not tested end up coming up almost immediately. This is a good thing though. This is where we want the issues to show up. We want them to show up on test sites. Fortunately in this case it was only font size issues. Also, during beta testing, users are well informed not to put this on live sites. Sometimes, the smallest issues can be the biggest pain the butt.

                When a beta version is released, this is where change logs are normally the most used. This is the listing of new features and changes that need to be tested. In this release, there are of course many new great features. Unfortunately, the font issue is present in this release. In the change long, testers would see this change/addition and would have tested it thorough across many different devices, browsers, etc. Once beta testers seem to be finding no more issues and all testing appears to be done, a stable release (extensively tested) is then created. This does not mean it is a perfect release. It is simply the best they can make it unless small bugs come about from time to time (but very unlikely). When a company has a plan of action is place on where a product needs to be tested, they benefit greatly from this both for the company and the end users!

                Beta testing also gives the company (in this case Cobalt) a solid foundation on where they need to create documentation. This is one of the primary sources where a company can see where users are struggle and need help understanding something. During beta testing, documentation is created and prepared for users of the final release. Overall, there are thousands of users that use Eric's products that can help him out in creating solid products. I'm sure Eric can't test all browsers, all screen sizes, all devices, all internet connections.... you get the idea. This community has the ability to test such a wide range of variations.

                Overall, it becomes and win-win situation for all parties.

                If you need an example of "is beta testing needed"... think about Microsoft. They have thousands of alpha testers and never release a beta version. As big as that audience is and as skilled as their teams are, even they aren't able to find thousands of issues. There is where NOT have a beta version is a bad thing. Instead, once the product is released, they are left putting out updates like crazy. This is where re-work is done which wastes time and money.. Video games have the same system. Once the games are released, patches and updates come out all the time because instead of just thousands of alpha testers testing the product, now millions of people are using the product under hundreds of different variations which find the bugs. This is where the bugs become known.

                End the end, Eric is putting out a great product and overall doing a great job at it. This would just help him out in numerous areas in terms of product development and support content that "needs" to be created. In the end, the end user has a solid product with all the help they need.

                That clear it up a bit?
                Last edited by Jordanemery; 09-21-2013, 11:03 PM.


                • La Geek
                  La Geek commented
                  Editing a comment
                  Hi Jordanemery,

                  I wrote the post below in the same time, you wrote your reply. So the post below was written as answer of Erics post.Nonetheless it could be also an answer to your post, and funny it is.

                  In my first post I asked you, if you have anything to claim about DWB 1.3, since it sounded so. And pointed to the only item, that failed: font-size (REM). I wanted to ask you, if there were more issues - if you had found more issues in DWB 1.3

                  I did not criticize your suggestion of beta releases and I did not challenge it - - - although I have a different perspective and a lot of experience with beta tests ( I am doing daily til weekly betatests). Also I had no questions about (your thoughts) about beta tests and what you meant, when you wrote this.

                  However thanks for your answer, this was appreciated
                  Last edited by La Geek; 09-21-2013, 11:39 PM.

              • #11
                Hi Eric, thank you for the fast update, that's very appreciated. I will test, set my installation back to DWB 1.2 and install the new DWB 1.3 and will report here.

                Concerning Beta tests:

                I am working more than 6 years with Joomla! (but since ca 2 years I prefer to build websites with WP - I keep my knowledge about J! up to date only, because a lot of clients want J! Sites). I am member of the official Joomla! Bug Squad Team and so I have good experience with bug testings and also with the resonance of "normal users".

                J! uses a bugtracker system: jforge and merges patches and pulls items with github. For serious bugtests you need exact informations about the CMS Core version, the build number of DWB, mostly also about the OS and the Browser.

                In my experience normal users are rarely interested in bug tests. And often enough they use it on live sites. A few guys and I have built a german J! bug site, where users can describe an issue with J! in german language. So they don't need to know english and they don't need to fill in a probably complicated tracker form. Instead they can write the issue in a normal forum, and fill in a very easy form, where we ask the datas we need.

                But what we noticed in this year since we started: Most users write in the greatest german J! forum (not ours), describe the issue and are only interested to fix this for their own website. Although it would pretty nice, to fix this now and forever in the upcoming J! versions. So they whether write a tracker item nor they use the german bug site.

                And often enough the issue exists between chair and keyboard. Official beta releases bring you a huge amount of work:
                1.) Gather the needed datas (which versions are used etc)
                2.) exclude plugins as cause of the issue
                3.) exclude user as cause of the issue
                4.) test the patches again
                5.) find testers for the patch
                - and I think atm I have forgotten some importants items.

                I really was (and I still am) sure, that you (Eric) don't release versions without beta tests before release.

                I also know, that errors can happen and always happen. This happens often to Joomla! versions, although they have had alpha, beta 1, beta 2 and pre release packages for all users. And although they have a bug squad team, which pulls the newest master versions from github, which tests patches and which are experienced users with deeper knowledge of J!.

                So my point is: Beta releases sounds good, but it's not as easy as it sounds. It probably slow down the release process for longer time as it should. You'll get a huge amount of additional work (see points 1 to 5).

                Closed beta would be the best way, I guess. With experienced users with different testing environments and probably a bug tracker system for this closed team.

                Just my2cents.
                Last edited by La Geek; 09-21-2013, 11:25 PM.


                • #12
                  La Geek,

                  I agree with your reply here in most instances. WordPress and Joomla of course have much of the same target audience. Fortunately, conversations like this one about testing is a great subject to improved products. But, I am not sure the testing is being done properly by your numbered list here...

                  1.) Gather the needed datas (which versions are used etc)
                  • This is done easily with the tools implemented in Dynamik for Genesis. Takes at most 30 seconds to find this information based on the layout by in the software. (I commend Eric on making this information easily accessible.)
                  2.) exclude plugins as cause of the issue
                  • When testing a product, you should only test the product with the product only. You should never test based on plugin simply because this is impricatical and ultimately is not a product issue. Instead, Plugins should be tested to meet that of major products. You will NEVER create a product to be perfectly compatible with all plugins as there is simply too many to test. Instead, test the product as it is.
                  3.) exclude user as cause of the issue
                  • This is where ease of use, design, user interface, and documentation benefits from beta testing. If the user is the cause, what are they doing that we can make the product easier to use? This is instead a supporting factor to beta testing.
                  4.) test the patches again
                  • Open Beta testing will eliminate most patch needs.
                  5.) find testers for the patch
                  • Beta test. Most will be thrilled to give the new stuff a test run. Closed Beta test is very similar to alpha testing which limits many of the different variations in testing. It will take longer to find a closed beta testing group than to use an open beta test. With a closed beta test, you have to find users that meet certain criteria such as users that use different browsers, internet connections, etc. This will make new releases much much more delayed since testing wont take place for quite some time. Since Cobalt apps in only a small group, closed beta isn't practical.
                  Overall, you have some valid points here!


                  • #13
                    Yeah Jordanemery,

                    but as stated above: We are just talking about "normal users". Please see above, what I wrote in context of these users and beta releases (no interest, use this on live sites, use it WITH plugins, are not experienced - see a border and claim it as issue and so on and at last: No interest of fixing it for all, but only for the own website.)

                    I don't know, if you have experience as a forum supporter. How often you have to ask again and again for the same informations? E.g. they have an issue with CSS and their websites, but don't post a link to it. You can write thousands of F.A.Q. and billions of Documentations and include a popup hint for every item - they don't read it. They ask, but without the possibility to help (lack of informations).

                    So - only this point - ask again and again for needed informations bind the manpower and waste time. And keep in mind, that this forum is not installed as "support forum", but rather as users for users forum.

                    However, I would be glad to see betatests, which can be done in an effective way and are successful - but as mentioned above:
                    "I also know, that errors can happen and always happen. This happens often to Joomla! versions, although they have had alpha, beta 1, beta 2 and pre release packages for all users. And although they have a bug squad team, which pulls the newest master versions from github, which tests patches and which are experienced users with deeper knowledge of J!."

                    Please don't misunderstand me, I am not against SUCCESSFUL and EFFICIENT Betatest - but I only don't see a chance for realisation


                    • #14
                      Originally posted by eric View Post
                      but future updates should convert your font sizes properly. I also updated the "My Account" DWB 1.3 zip file so if you're doing manual updates then re-download that file and use it instead of what you may have already downloaded.
                      Hi Eric, thank you for the fast update, that's very appreciated. I will test, set my installation back to DWB 1.2 and install the new DWB 1.3 and will report here.
                      So, I did this test: Now it works like a charme (same website failed with first / previous update version). I tested with WP 3.6.1, Genesis 2.0.1 and DWB 1.2 --> automatic update via backend to DWB 1.3
                      (fonts were set to em in DWB 1.2)


                      • #15
                        La Geek,

                        Understand what you mean. I think one way to combat the ask again and again is to make a form that has required fields to be populated before submitting a bug or issue request. For example, Product would be a pull down to select. Then a version number would be a drop down again to select. Once all required fields would be mandatory before the form can be submitted. For each field within the form, make a tool-tip like the ones in the product so that they user has instructions on how to fill out the specified field or drop down. This would make the submission a walk in the park and still allow open beta testing.

                        Once a system like this is created, Eric can hand select a team (closed beta testers) to retest the know issues through beta testing in a controlled environment to duplicate the issue submitted. This form submission would be addressed with a team of highly skilled "hand selected" professionals to pinpoint the know issue and report it to Eric. This would allow his to understand the issue once found and allow him to continue to work on future content instead of past problems. WOW. This would also allow for pin point need for documentation creation.

                        To me, bug testing and user research is a lot of fun. I have done it for years as well.

                        If you ever have the time, I would enjoy to have a Skype session with you. I think we have a discussion here that could be a new method for testing products. I would like to run it by you and see what you think.