WooCommerce 8.4.0 Beta 1 Released

13 responses to “WooCommerce 8.4.0 Beta 1 Released”

1. 

   diego

   November 28, 2023

   
   Unfortunately, the commit #40983 introduces a conflict with a feature that I implemented years ago, and which has been working smoothly until now.
   
   BackgroundYears ago, I extended the Shipping Settings page, to allow merchants to enter currency-specific costs for the flat rate method, as well as a currency-specific threshold for free shipping.
   
   I implemented the UI extension with a clever, non-intrusive “hack”, which injected an HTML element that acted as the currency selector, without interfering with any other I added functionalities (good old jQuery, worked like a charm).
   
   The selector works by reloading the page, tracking the “settings currency”, so that a set of currency-specific parameters can be loaded and passed to WooCommerce. In layman terms, whereas WooCommerce would normally fetch “flatrate-1-settings” (hypothetical name), the logic would return “flatrate-1-settings-USD“, “flatrate-2-settings-EUR” and so on).
   
   This worked perfectly fine, and it’s transparent to the core shipping logic. All good, without any side effects, at least until now.
   
   Effect of the new UII was concerned that the introduction of a new UI, based on React, could cause issues. React is definitely FAR less extensible than plain HTML+JS, unless the components are explicitly designed to be extended from the start. It may be a modern tool, and it may be more elegant, but, without extensibility features, one can’t necessarily add alter a React page, like I did in the past with the “legacy ones”, without breaking things. It’s a known fact that I’m not a fan of React, blocks or JS functional programming, but that’s another story. 😄
   
   The good newsA preliminary test of the new UI seems to indicate that the selector I added still works, and it doesn’t even look too bad. For example:
   
   
   Region page: https://prnt.sc/RFF9N9cutXzw
   

   
   Shipping method settings popup: https://prnt.sc/w1t8-bgP0ZIW
   
   
   The functionality also works, which seems to indicate that, despite my UI extension being a “hack”, I was able to keep it sufficiently self-contained, and made it work at a level high enough to avoid conflicts with the core features. This is the good news.
   
   It also seems that the backend logic remained unaltered. This means that the existing integration is still able to load and save currency-specific shipping settings like it did so far, and calculate the shipping costs as it should. Example, just for the sake of understanding:
   
   
   Shipping in EUR: https://prnt.sc/6oW9gg8V_JHg. Checkout: https://prnt.sc/N67AbR5DNJlP
   

   
   Shipping in USD: https://prnt.sc/3DjJItV22aFK. Checkout: https://prnt.sc/6iVhOypQDSpc
   
   
   In both cases, the shipping costs in EUR and USD were loaded correctly, so we seem to be almost on track so far.
   
   Incorrect behaviour encounteredThe glitch I found is that the new shipping settings UI displays a currency symbol that doesn’t take into account the actual active currency. Example:
   
   
   EUR (correct): https://prnt.sc/lBsedLFEGeIa
   

   
   USD (wrong): https://prnt.sc/agxh1ju6Eorn
   
   
   The issue is that the currency symbol displayed on the settings page is always the same, i.e. the one from the shop’s base currency. This needs to be corrected, or it will cause confusion.
   
   The issues to address
   
   There are two issues that must be taken into account in the new UI:
   
   
   How can one change the currency symbol on the new shipping settings page? When the currency changes the page is fully reloaded (that’s by design), therefore I would just need a filter that I can intercept to set the currency symbol to be used for formatting. To be absolutely clear, I would rather NOT have to put together a React script for this minor thing, a simple one-line PHP filter would be preferred.
   

   
   The new UI doesn’t seem to take into account that one could be using custom currency symbols. Although the UI looks fine with a simple, single-character symbol, it doesn’t seem to adapt too well to longer symbols. For example, one could configure a currency symbol like USD$, CAD$, AUD$ to distinguish between the various “dollars” (very common). Here are a few example, which I created by editing the HTML manually on the rendered page, comparing a simple “€” with “EUR€” (which practically nobody uses, but it’s to illustrate the concept) and “USD$”:1. €: https://prnt.sc/4Qt9vlAJh1kA2. EUR€: https://prnt.sc/tTyW-JYFkjrT3. USD$: https://prnt.sc/84IAFrls8N_yCases #2 and #3 show that a longer currency symbol will make the number illegible.
   
   
   This is my feedback so far. If any core developers wish to discuss it “live”, they can reach out to me on Slack. I’m not always online, but you can ping me and we can organise to “meet” at a convenient time.
   

   Reply
   1. 

      psealk

      December 4, 2023

      hi Diego,

      Thanks for the heads up and detailed report. Let’s make sure there is a suitable solution here.

      When the currency changes the page is fully reloaded (that’s by design), therefore I would just need a filter that I can intercept to set the currency symbol to be used for formatting. To be absolutely clear, I would rather NOT have to put together a React script for this minor thing, a simple one-line PHP filter would be preferred.

      The currency value used to populate the symbol in the React based modal comes from the base WooCommerce currency and its formatting. Those can be modified with woocommerce_currency_symbol and woocommerce_price_format filters.

      For instance, with this code I can change the displayed currency:

      [code lang=”text”]
      add_filter('woocommerce_currency_symbol', 'custom_currency_symbol', 10, 1);

      function custom_currency_symbol() {
      return '$#&$';
      }
      [/code]

      See https://github-production-user-asset-6210df.s3.amazonaws.com/1922453/287872793-d1ab0337-a6a7-4f42-9722-4ccb78a59c8c.png

      However, this solution may be heavy handed – There may be unintended consequences by filtering the WooCommerce base currency even if just for the Shipping Settings screen.

      A better solution will be to create a JavaScript based filter specifically for this value. I will add one and create a bare bones implementation to share in a subsequent comment.

      The new UI doesn’t seem to take into account that one could be using custom currency symbols.

      It actually does by measuring the length of the symbol and adjusting accordingly. However, you won’t see this by manually editing the HTML because that JS has already run. Once you get a solution up and running, let me know if there are any problems with that spacing and I will look into it.

      Thanks again and I’ll be back real soon with a JS based solution and example.

      Reply
      1. 

         psealk

         December 5, 2023

         Here is a potential JavaScript fix with example plugin code. Let me know if this would be helpful.

         https://github.com/woocommerce/woocommerce/pull/41871

         Reply
      2. 

         Diego

         December 5, 2023

         If filtering the currency symbol can be sufficient, that would be a suitable solution. I already do that throughout the site, depending on the context (that’s a core aspect of the multi-currency solution), so adding an extra filter just for the shipping settings context would work, without affecting any other page.

         I would avoid any JavaScript-based solution, unless absolutely necessary, as they add too much maintenance and interdependencies. I rarely rely on JS for anything, actually. 😅

         Reply
2. 

   leewillis77

   November 29, 2023

   The changes in log viewing don’t appear to be in 8.4.0-beta.1 – see screenshots below:

   https://capture.dropbox.com/LX3aDWi2eV8gFKXE
   https://capture.dropbox.com/H8JQwLWAKU5bbptK

   Reply
   1. 

      Corey McKrill

      December 4, 2023

      @leewillis77 The logging changes are currently hidden behind a sort of “feature flag”. If you define the WC_Log_Handler constant to use the new log handler, like so:

      define( 'WC_LOG_HANDLER', 'Automattic\\WooCommerce\\Internal\\Admin\\Logging\\LogHandlerFileV2' );

      … then you should be able to see and try out the changes. There are more changes coming as well, including a UI to pick which handler you want to use, but those probably won’t be in 8.4.

      Reply
3. 

   Diego

   November 30, 2023

   I posted a comment yesterday, which is still “awaiting moderation”. I highlighted some important issues that we will need to deal with, could you please check?

   As a side note, it looks like the comment editor on this page lost most of the formatting that was clearly visible when I entered the comment. I can see that numbered lists, bullet lists and some “newlines” have been lost, making the comment a lot harder to read.

   I don’t know how that happened, but it wasn’t deliberate. Sorry about that.

   Reply
4. 

   Diego

   December 1, 2023

   Do the comments work on this thread? Mine keep disappearing.

   Reply
   1. 

      Beau Lebens

      December 4, 2023

      I think your previous one got caught because it contained so many links. I found and approved it above though.

      Reply
      1. 

         Diego

         December 4, 2023

         That could explain why the comment disappeared. The links are needed though, they provide the details to illustrate the issue.

         Thanks for restoring the comment, much appreciated.

         Reply
      2. 

         Diego

         December 5, 2023

         I posted another comment, again with some links, and it “disappeared” again. Sorry about that, unfortunately I do need to add the links for clarity.

         Could you please let the comment go through? Thanks again for your time.

         Reply
         1. 

            Beau Lebens

            December 5, 2023

            I’m not seeing any unapproved comments from you, so can you please double-check if it came through, or that it actually submitted? If that doesn’t work, you’re welcome to email it to me directly at beau@automattic.com

            Reply
            1. 

               Diego

               December 6, 2023

               I’m quite sure that I posted it, but it seems that it doesn’t matter. I had noticed an issue with the titles of the shipping methods “disappearing” until the user explicitly entered and saved a title for each instance, whereas before one could simply see the default titles. It looks like this was fixed in WC 8.4 RC1, so we can ignore my comment about that.