Skip Navigation
Home » WPML Blog – News and Updates for the WordPress Multilingual Plugin » WPML versions » WPML 4.3 Beta 1 with Much Faster String Translation

WPML 4.3 Beta 1 with Much Faster String Translation

WPML versions
69

Today we released the first public beta of a completely new String Translation, which avoids all database calls to translate strings on the front-end and WordPress admin.

The way String Translation in WPML works has changed over the years. Our goal was always to allow you to translate every piece of text on your site and to load the server as little as possible.

In recent years, plugins and themes have grown bigger, using many more translatable strings. A typical admin page which opens a page builder, WooCommerce and several other big plugins could load over 30K strings from the database. This growth in the number of translatable strings has made sites slower with String Translation. WPML allows you to translate everything on the page and when it filters these many strings, the CPU and database get loaded.

Today, we’re ready with a new version that completely changes how String Translation works. This new release does two major changes:

  • Only touch strings that you want to translate
  • Rely on .mo files to apply translations

The first change means that the String Translation table will not include all texts by all plugins and the theme by default. For the vast majority of the sites, themes and plugins come with their own .mo files with good and complete translations. There’s no need for WPML to filter (and make translatable) all these strings. If you want to override the translation of texts from a plugin, you can still do it. You’ll be able to choose which plugins you want and WPML will register the strings coming from it.

The second big change means that WPML does not call the database for the translation of any string. WPML compiles .mo files for your translations and lets WordPress load them. The size of these .mo files depends on the number of strings that you translate. On most servers, loading a file is significantly faster than loading multiple entries from the database (the DB is the performance bottleneck for many sites).

Generation of the .mo files

WPML String Translation handles the generation and maintenance of the .mo files automatically. This happens every time you translate a string on the WPML -> String Translation page.

However, after upgrading to this beta, you will need to generate the files for the first time.

If your site had any translated strings before the upgrade, you will see the following dialog on any admin page after updating String Translation:


.mo files generation dialog

You can regenerate the .mo if something goes wrong while testing the beta.

To do so:

  1. Go to WPML -> Support.
  2. Click the Troubleshooting link.
  3. Scroll towards the end of the page, and click Show custom MO Files Pre-generation dialog box.
  4. Reload the page (this step won’t be needed in the final release).
  5. The dialog which allows you to regenerate the .mo files will appear.

The Results

This version is already running on all our production websites (WPML.org, Toolset.com and ICanLocalize.com). It’s working smoothly and the servers are happy. String Translation was never a significant factor in our sites’ performance, so we’re using other sites for performance analysis.

We received dozens of sites form clients, where String Translation was a lot more significant. On all these sites, we confirm that the server load due to String Translation has practically dropped to zero. These sites now load at about half the time they loaded before (hurrah!).

Current Development Status

This beta is ready for your testing. The only caveat is that it’s not yet working on multisite installations. If you have a single-site (regular) WordPress install and you suspect that you have performance issues due to String Translation, try this beta. We’re going to let this beta run for several weeks and collect client feedback in the meanwhile. We’ll be completing the support for multisite while profiling more client sites.

If you’ve switched to this beta and are still getting significant performance issues related to WPML, we want to see your site. We may find other pockets of performance issues that we need to handle. We want to make sure that by the time this goes into production, nobody has any performance issues related to WPML. Our aim is to release WPML 4.3 for production at the first half of September.

Download and Try

Remember, this version doesn’t yet work on multisite installations!

It’s OK to use it on development sites and on production sites, but with some caution.

Automatic update

To get this beta, go to the Plugins -> Add New and click Commercial tab:

Commercial tab

From this page, enable the Beta channel and update the plugins automatically.

Visit our page about installing beta versions of WPML for more details.

To get the automatic updates or switch to the beta channel, you must register your site.

Manual update

You can also update manually.

To do so, follow the directions in Updating WPML manually (even if it refers to an old version of WPML, the process is exactly the same).

Feedback?

After you try this beta of WPML, we’d love to get your feedback. Please share all the information that you can with us. We want to know when this beta fixes performance issues and about any remaining performance problems that we need to handle.

Leave your comments and we’ll get back to you.

Update – 2019-08-16

We have released a new beta which fixes the following issues:

  1. Incompatibility with WooCommerce Multilingual: you can install either the current release or the beta of WooCommerce Multilingual included with this release.
  2. Bad performance when saving the post with a big number of custom fields.

Known issues so far

We are still working on polishings some parts. As of today, this is the list of known issues:

  1. Multisite is not supported yet.
  2. Deleting strings from String Translation does not update the generated .mo file.
  3. Deleting all the strings of a domain, will not delete the generated .mo file.
  4. After deleting all the strings of a domain, the .mo files regeneration (see “Generation of the .mo files” above to find how to regenerate the files) will not delete the corresponding .mo file.
  5. Translated admin texts returned original in icl_translate function (affecting WooCommerce Multilingual: “Custom subject of new order emails isn’t translated”).

69 Responses to “WPML 4.3 Beta 1 with Much Faster String Translation”

  1. Was so happy to see this beta until I read that it doesn’t work with Multisite!!! Have turned off String Translstion on one site just to get it to run.
    PLEASE make it MS compatible soon!!

    • Yes. We’re working on it and will release another beta once we have the multisite functionality working.

      • Hi Amir
        Exported out one site from an MS and set it up locally (DesktopServer).
        Updated everything to latest apart from Woo.
        Beta 5 for 3 of your plugins.

        There are still over 24000 strings in String Translation.
        Should I delete them?
        If so how?
        Do something under Support to clean up the DB?

        • The size of the ST table shouldn’t influence the speed of the site. This version doesn’t automatically remove strings. However, WPML will no longer access these strings when displaying pages. It will compile .mo files only once (when strings are added or changed) and that’s it. If your site had performance issues linked to String Translation before, can you tell us what you’re seeing with this new release?

          • Hi

            OK.

            I have 2 local installs now, one with the old versions and one with Beta.
            Sometimes one is faster than the other, the next it’s the other way around!

            My problem has always been opening several Products tabs in Woo by control clicking. Can hang the Droplet on DO for a minute with old ST.

            I’ll wait for MS to be released.

            • Would you like us to profile your site and see what contributes to the processing time? We will need to receive a copy of your site to do this locally.

              • Sure. I’ll make a backup with Duplicator of the beat install.
                How do I send it to you?

                • Hi Amir and Igor

                  So with some help from Igor I got the Beta up and running. There is a definite speed difference from before. Here are some numbers.
                  Run both installs on 2 different DO Droplets (both 2 GB / 2 vCPUs), and Woo.
                  Single install for Beta; MS for old.

                  I have 6 pages that I test the speed for

                  -Dashboard
                  Page Generation Time (PGT): 2.88 s -> 0.50 s
                  Peak Memory Usage (PMU): 64 kB -> 24 kB
                  Database Query Time (DBQT): 1.8 s -> 0.16 s!!!!
                  Database Queries (DBQ): 558Q -> 233Q!!!

                  -Plugins
                  PGT: 2.69 s -> 1.12 s
                  PMU: 58 kB -> 25 kB
                  DBQT: 1.47 s -> 0.32 s
                  DBQ: 464Q -> 201Q

                  -Products (all 62 items)
                  PGT: 4.66 s -> 1.89 s
                  PMU: 80 kB -> 36 kB
                  DBQT: 1.6 s -> 0.46 s
                  DBQ: 1167Q -> 966Q

                  -Product page 1
                  PGT: 2.06 s -> 0.66 s
                  PMU: 57 kB -> 26 kB
                  DBQT: 0.77 s -> 0.21 s
                  DBQ: 438Q -> 273Q

                  -Product page 2
                  PGT: 1.71 s -> 0.88 s
                  PMU: 57 kB -> 26 kB
                  DBQT: 0.6 s -> 0.35 s
                  DBQ: 433Q -> 270Q

                  -Product page 3
                  PGT: 3.72 s -> 0.58 s
                  PMU: 55 kB -> 25 kB
                  DBQT: 1.35 s -> 0.17 s
                  DBQ: 372Q -> 240Q

                  So pretty drastic differences.

                  On a separate copy of the Beta install I’ve deleted all but a few of the Strings on the TS page (some can’t be deleted for some reason!).
                  The weird thing is that I still see my translations in the front-end but they are not in the TS database. If I search for them I can’t find them.

                  Where are they stored and how can I edit them??

                  This gives me back the confidence to use WPML with Woo again. I have TS turned off on a live Swedish Woo site because I can hardly work in the backend. Will make a backup of it and update and see how it goes.
                  Let you know.

                  Are you planning any updates to the Beta in the coming day or so so I should wait?

                  Cheers

                • Hi Kristian,

                  I’m glad you appreciate the differences!

                  What do you mean by “TS”? Is the “String Translation” page? If you could not delete some strings, we would be happy to address the issue.
                  As this would require a few more information, the support forums would be the best option, so you can also include one or two screenshots to understand the issue better.

                  > The weird thing is that I still see my translations in the front-end but they are not in the TS database. If I search for them I can’t find them.

                  Again, the support forum may help to address this.

                  At the moment, I can think that the translations might be in the generated .mo files (under “wp-content/languages/wpml”).
                  If you have deleted those strings, String Translation must delete them from the .mo files as well: if that’s not the case, it might be something we must fix from our side. I’ll ask our team to check this case.

                  As for the beta, we are planning to release more updates before the final release.
                  We are releasing on today.

                  As explained in the blog’s post, we plan to have the beta (and updates to it) run for a few weeks so to collect and address feedback from clients who, like you, are willing to test it.

          • Great news!
            I think an answer to all Kristians questions regarding strings would be beneficial to us all. I guess you’re saying it doesn’t matter if they are deleted or not? But most people like to keep their data lean and minimal. So, can they be deleted somehow or shouldn’t they for some reason?

            Thanks!

            • You can delete strings. When you update to this new beta, you will notice that WPML no longer auto-registers strings from plugins, so the table will not grow again.

              We haven’t deleted (cleaned-up) strings on our sites. We have some modifications for some translations and we didn’t bother reviewing which stings we need and which we don’t need.

              You can always clean these strings manually. You can filter the list of strings by context, “select all” and delete.

              Again, this should not change the load on the server or speed of pages.

              • Hi Amir. This sounds like a great update! Looking forward to this one :-). Also I agree with Kristian and Ben. I would rather delete all the strings from my database that are not being used. Even if it doesn’t directly impact performance. I try hard to keep my db clean and this has always bothered me about WPML.

                If the plugin isn’t going to clean this up automatically, then please can you provide an easy step by step guide to follow so we can do it manually ourselves.

                Also 1 question might be should we be changing any settings after this release?

                Thanks again for this update!

                • You don’t need to change settings after this release. With this update, WPML needs a lot fewer settings so you will see the “WPML->Theme and plugins localization” page much cleaner now with fewer options to choose.

                  We’ll arrange something to auto-delete untranslated strings. We don’t want WPML to do this completely automatic, but we’ll arrange so that it’s a simple process and doesn’t require many clicks on paginated lists.

  2. Hi, just installed on my site. Everything seems to be going well. The problem is that it no longer translates the strings of my PHP code and others. However, there are translations in the string translator. Any suggestion?

    • Right after you install the beta, you should see a message asking you to generate .mo files (in the WordPress admin). Have you seen this message and followed its instructions?

      • I not saw any message like that 🙁 Is possible to re-enable it? I fix some strings translations with just to manually save translations

        • Hello,

          The message only appears if you’ve ever translated strings with String Translation.

          If you have translated strings, can you please try the steps explained in ”Generation of the .mo files” where it says ”You can regenerate the .mo if something goes wrong while testing the beta.” and let us know how it goes?

    • Did you update all plugins from the beta? Have you run the wizard to generate .mo files? It should display right after you switch to the betas.

  4. So, how do I install?

    Do I have to disable / delete the old plugins first or can I update the existing ones?

    • The right process is to:

      1. Download the necessary “beta” plugins from your WPML account.
      2. Upload them to the Plugins folder in WordPress.
      3. Disable (not uninstall) the current WPML plugins.
      4. Unzip and activate the beta plugins.

      After you activate the new beta plugins, you will see a popup on all the WordPress admin pages. This popup asks you to generate .mo files for your strings. This is a one-time thing and you have to run it. Otherwise, translations will not show for your existing strings.

  5. Installed WPML v4.3.0-beta5 together with the other two plugins but we keep getting an error “WPML needs to generate .mo files”.

    Trying to generate the files throws an error and there’s no way to permanently dismiss the popup.

    Annoyingly, this popup fires for all users on wp-admin

    • It appears this was caused by Rest API Toolbox and the fact we have disabled the REST API.

      There was no error shown on the popup however so i’d suggest that
      1. You add an error if the request fails due to the API being disabled (already implemented when toggling between Translator Editors under Translation Management
      2. Make this popup permanently dismissable or display it as a standard WP error instead

      • We have code that catches errors in the process of generating the .mo files. However, if there’s a Javascript error on the site, our code doesn’t run. Do you see JS errors in the browser console?

        I’d like to connect you with a supporter who can check what’s happening. How about opening a support ticket? We use chat today, so our supporters can solve the problem for you in real time.

    • This popup is pretty important. Without following it, translations for strings will not show. Can you tell what’s in the error?

  6. Hello, that’s is a great update !
    I want to share my database urage metric with you : https://i.gyazo.com/0af2368232377030faaf7859fd90a154.png

    As you can see, when i was install this beta, the memory usage was decreased by 70% and that is awesome !

    But i see the CPU usage increase a lot : https://i.gyazo.com/493cbcb3be20535794543dc5fe9b5b79.png
    So we need more time to know if the CPU usage will not explode when many people consulting the website.

    What do you think ?

    have a nice day

    • The new version of String Translation needs to run a 1-time process to generate .mo files. This requires CPU. The CPU load is not proportional to the number of visitors to the site. It only runs once, in the admin, when you translate new strings or edit string translation. When the site is “static”, there’s no additional load on the CPU, database or memory.

      Do you see CPU usage continue being higher, or is this indeed a one-time spike?

  7. Hello, to test this Beta version, how should I install on my page? Should I delete the current versions and then upload the Beta versions? Doing this I don’t lose any of my translations? Thank you.

    PD: Then, when there is a new update available that is not Beta, what will happen?

    • You don’t need to delete and replace pages. You need to update the plugins.

      The right process is to:

      1. Download the necessary “beta” plugins from your WPML account.
      2. Upload them to the Plugins folder in WordPress.
      3. Disable (not uninstall) the current WPML plugins.
      4. Unzip and activate the beta plugins.

      After you activate the new beta plugins, you will see a popup on all the WordPress admin pages. This popup asks you to generate .mo files for your strings. This is a one-time thing and you have to run it. Otherwise, translations will not show for your existing strings.

      This beta version of WPML preserves all your translations. The purpose of the process to create .mo files is to copy translations from the database to files (faster to serve).

      • 2. Can I upload it from the WordPress panel?

        4. What does unzip mean? If I install it from the WordPress panel the decompression is automatic, right?

        Then on each page I have to generate the .mo files? If I have 250 pages do I have to do this one by one?

        • Hello Diego,

          I’ve updated the post with clearer information.

          The post now contains directions on how to run a manual update (which incolves downloading the ZIP files, unzipping them and uploading to the server).
          However, I suggest you go through the automatic update process, which is also explained in the post.

          As for generating the .mo files, I’ve added a section which explains what to expect after upgrading String Translation: if you’ve previously translated strings, you will get a dialog which will generate the .mo files.

          After this process (or if you’ve never translated any string before this update) the .mo files will be generated or updated automatically every time you translate a string.

          I hope this makes things clearer.

          • No, sorry, the information requested is not clear to me. Wouldn’t it be better to wait for this beta version to become the final version?
            Will that process take a long time?

            • Diego,

              Installing the beta is not a requirement.

              You can, if you wish, install it to enjoy the performance improvements.

              If you don’t feel to give it a try, you can wait for the final release.

              As explained in the post, we want to let the beta run for a few weeks.

              During this time, we deal with the remaining issues (e.g. support for multisites), polish the code, and address any feedback we may get from those who installed the beta.

  8. You can delete my last 2 comments. I just realized that I hadn’t updated all 3 components to their beta versions, so it was throwing those error messages.

    Sorry about that!

  9. Please note that there is a NEW beta5 update. Very confusing.

    Used that and I got the Notices to update .mo files.

    Almost No change in speed though on my local system (DesktopServer).

    10% less queries which is good and 2-5% lower RAM use. Also less (almost none) slow queries from WPML.

    Igor is on it so we’ll see what the problem is with my site.

  10. It seems that this version can’t handle translation of certain UI strings in BeTheme. For example “Read more” went back to English and my translations to Polish no longer work. BeTheme uses quirky way to set such translations as there is a simplified built-in mode for UI strings which can be turned off if using po/mo and WPML. It used to work prior to beta but it no longer does. I tried translating all strings through my site that relate to “Read more”, cleaning LiteSpeed Cache and Cloudflare cache but it constantly sticks to English.

    • Hello Lukas,

      I asked Pierre, a WPML developer, to look at BeTheme.

      He will get in touch with you soon.

    • Hi @szmigieldesign,

      I installed and tested BeTheme but I could not reproduce your issue, the “Read more” string is properly translated on my end.

      Could you please open a forum support ticket where you share a Duplicator snapshot of your site? Then please share the link here so I can jump on it.

      Thanks,
      Pierre

      • Hi @Pierre,

        I think I figured it out. Somehow language domain got mixed after the update. It has to be English (admin_texts_betheme was set to Polish) and in BeTheme translation panel translations have to be turned on. It works fine now.

  11. I’ve just installed the beta version (including the betas of WPML itself and Translation Management) on a WooCommerce-based website and tested everything.

    I notice that in WP-admin > WooCommerce Multilingual the tabs “Multi-currency”, “Store URLs” and “Status” now generate the standard WP error for plugin issues:

    The site is experiencing technical difficulties. Please check your site admin email inbox for instructions.

    Is there an issue between the betas and the WooCommerce Multilingual plugin (v 4.6.5)?

    • Here’s the exact error message by WordPress:
      An error of type E_ERROR was caused in line 1119 of the file /home/www/test.myhostpoint.ch/wp-content/plugins/sitepress-multilingual-cms/lib/twig/src/Environment.php. Error message: Uncaught LogicException: A function must be an instance of \Twig_FunctionInterface or \Twig_SimpleFunction. in /home/www/test.myhostpoint.ch/wp-content/plugins/sitepress-multilingual-cms/lib/twig/src/Environment.php:1119
      Stack trace:
      #0 /home/www/test.myhostpoint.ch/wp-content/plugins/sitepress-multilingual-cms/classes/templating/class-wpml-templates-factory.php(120): WPML\Core\Twig\Environment->addFunction(Object(Twig_SimpleFunction))
      #1 /home/www/test.myhostpoint.ch/wp-content/plugins/sitepress-multilingual-cms/classes/templating/class-wpml-templates-factory.php(67): WPML_Templates_Factory->maybe_init_twig()
      #2 /home/www/test.myhostpoint.ch/wp-content/plugins/woocommerce-multilingual/inc/template-classes/class-wcml-menus-wrap.php(223): WPML_Templates_Factory->get_view()
      #3 /home/www/test.myhostpoint.ch/wp-content/plugins/woocommerce-multilingual/inc/template-classes/class-wcml-menus-wrap.php(173): WCML_Menus_Wrap->get_current_menu_content(‘mul

      • Hi Boris,

        Thank you for your feedback!

        This issue is currently being investigated and we’ll keep you informed as soon as possible.

  12. Hi Andrea (I can’t reply to your message above)

    Yes I meant ST for String Translation!!

    I will open a ticket about not being able to delete all of them, and a separate about the .mo file.

    OK, will wait for the latest Beta before I update my live site.

    We have actually met at WCE in Vienna a few years back. It was the discussions that we had and also talking to Amir that made us buy and use WPML and Toolset for all our more advanced sites.

    Cheers

    • Hi Kristian,

      I just a confirmation that my guess about the deleted strings was correct.

      We will fix this in one of the next updates (not today’s one, though).

      You will only need to regenerate the .mo files when the fix is ready.

      To regenerate the .mo files:

      1. Go to WPML > Support
      2. Click the “Troubleshooting” link
      3. Scroll towards the end of the page, and click “Show custom MO Files Pre-generation dialog box”.
      4. Reload the page
      5. You will get the dialog asking you to generate the .mo files

      Today, this will only fix the problem is you still have at least one string of the domain in String Translation.
      However, since you’ve deleted all the strings, it won’t have any effect until we release the fix for it.

      I’m glad our meeting led you to adopt WPML and Toolset! 🙂

        • Get this after updating to b6:

          “WPML Update is Incomplete

          You are running updated sitepress-multilingual-cms, wpml-media-translation, wpml-string-translation and wpml-translation-management, but the following components are not updated:

          woocommerce-multilingual

          Your site will not work as it should in this configuration Please update all components which you are using. For WPML components you can receive updates from your WPML.org account or automatically, after you register WPML.”

          • Kristian, you can ignore this message, or install also the beta of WooCommerce Multilingual.
            Either ways, you shouldn’t have side effects other than seeing this message.

            • There is no Beta of it!

              Also none of Beta 6 is available from the backend under Commercial plugins.

    • Hi @Val,

      This beta version does not change the way we deal with page builders. Without going too much into details, page builders are only using string translation when the page is edited or translated with the advanced or classic translation editor. It should not change the performance of rendering the page builder content on the frontend end (it’s already translated in the database).

      Of course, the overall performance might be boosted because of non-page-builder strings.

  14. I just update to the last beta. Now the .MO dialog box is displayed. When I try to generate .mo files I receiving this “There was a problem creating the .mo files”. Every time I reload an admin page I sill receive the dialog. How I can fix this?

    • We’ll need to check why WPML is having a problem generating these .mo files. The most likely reason is that WordPress cannot write to the Languages folder. Do you know how to allow write privileges to folders using an FTP program? Let us know so that we can send you relevant instructions.

      • Hi Amir, this folder already have the right privileges and there are some .MO files generated from the previous plugin.

        • Please tell me how to remove this dialog box… is displayed every page load and is annoying me. Thanks a lot

          • Marco, I’m not sure what you’re seeing and what problem we need to help you fix. It’s difficult to keep track of the comments here. Can you please create a support ticket and add another message with its link here? We’ll get someone from the dev team to take that ticket, so they can help you properly. Thanks

  15. install on our mirror site, we see the performance but we also have PHP 7.3.8 errors during visit fontend our site

    are you busy about that or I have to introduce a ticket

    Deprecated (Suppressed) Defining the initRuntime() method in the “core” extension is deprecated since version 1.23. Use the `needs_environment` option to get the \Twig_Environment instance in filters, functions, or tests; or explicitly implement Twig\Extension\InitRuntimeInterface if needed (not recommended). 1
    +
    wp-content/plugins/sitepress-multilingual-cms/lib/twig/src/Environment.php:753
    Plugin: sitepress-multilingual-cms
    Deprecated (Suppressed) Defining the initRuntime() method in the “escaper” extension is deprecated since version 1.23. Use the `needs_environment` option to get the \Twig_Environment instance in filters, functions, or tests; or explicitly implement Twig\Extension\InitRuntimeInterface if needed (not recommended). 1
    +
    wp-content/plugins/sitepress-multilingual-cms/lib/twig/src/Environment.php:753
    Plugin: sitepress-multilingual-cms
    Deprecated (Suppressed) Defining the initRuntime() method in the “optimizer” extension is deprecated since version 1.23. Use the `needs_environment` option to get the \Twig_Environment instance in filters, functions, or tests; or explicitly implement Twig\Extension\InitRuntimeInterface if needed (not recommended). 1
    +
    wp-content/plugins/sitepress-multilingual-cms/lib/twig/src/Environment.php:753
    Plugin: sitepress-multilingual-cms
    Deprecated (Suppressed) Defining the getGlobals() method in the “core” extension without explicitly implementing Twig\Extension\GlobalsInterface is deprecated since version 1.23. 1
    +
    wp-content/plugins/sitepress-multilingual-cms/lib/twig/src/Environment.php:1301
    Plugin: sitepress-multilingual-cms
    Deprecated (Suppressed) Defining the getGlobals() method in the “escaper” extension without explicitly implementing Twig\Extension\GlobalsInterface is deprecated since version 1.23. 1
    +
    wp-content/plugins/sitepress-multilingual-cms/lib/twig/src/Environment.php:1301
    Plugin: sitepress-multilingual-cms
    Deprecated (Suppressed) Defining the getGlobals() method in the “optimizer” extension without explicitly implementing Twig\Extension\GlobalsInterface is deprecated since version 1.23. 1
    +
    wp-content/plugins/sitepress-multilingual-cms/lib/twig/src/Environment.php:1301
    Plugin: sitepress-multilingual-cms

    • Hi Vincent. Thanks for this report.

      You don’t need to open a separate ticket in the support forum. On Monday, the right developer in WPML team will get this and we’ll see what’s causing these warnings. They are all coming from the same function, so it will be a quick fix.

      Can you share the performance changes that you’ve noticed?

  17. Hey, whenever I update to the beta channel and install the beta plugins, nothing happens. I try to force the prompt to show, but nothing is shown?