WooCommerce 2.7 beta 3

Mike Jolley Avatar
Mike Jolley

•

Today we tagged WooCommerce 2.7 “Bionic Butterfly” beta 3. If you’d like to find out whats new in 2.7, you can read more about 2.7 in our first beta post here and our second beta post here.

Download WC 2.7 Beta 3

Changes since beta 2

Aside from many fixes and smaller improvements, here are some of the larger changes you may need to be aware of:

Release schedule

We’re still aiming to tag the release candidate on the 27th Febuary. The final release is expected to drop about 7 days from that on the 6th March. The final release will be sometime in March depending on the length of our RC. We’ll announce this when we tag the RC.

If you have not yet tested extensions or your themes, now is the time 🙂

We’ve been taking notes as we’ve updated extensions. For know issues and gotchas, please see this article on the wiki.

As for examples on how to update extensions to support 2.7, we’ve been publishing a series of posts on how we’ve done it ourselves.

Thanks for your support!

Keep yourself in the loop!

Sign up for the WooCommerce developer newsletter:
This field is hidden when viewing the form
This field is hidden when viewing the form
This field is hidden when viewing the form

27 responses to “WooCommerce 2.7 beta 3”

  1. Egbert Avatar
    Egbert

    This is going to be a huge step. Suppose I would like to apply beta3 to my test site, what is the impact on the database tables? Wil there be irreversable changes in the structure of the tables? Thanks Egbert, NL

    Reply
    1. Mike Jolley Avatar
      Mike Jolley

      I don’t think anything is irreversible but only test on a test site, not live.

      Reply
  2. Brent Avatar
    Brent

    In the last month with the previous two betas, I’ve found both major bugs (like Refunds being broken) and major issues with backward compatibility (like some hooks no longer being called).

    These have been fixed promptly, but based on the severity and frequency of those types of issues, which is much higher than I’ve seen before in a minor release, I personally don’t think 2.7 should be released in 2.5 weeks. From what I’ve seen, it needs a lot more testing, both by the Woo team, and community, before it’s safe to release.

    Beyond my personal experience working with the betas, there is some raw data to support this case. This release has 109,578 additions and 53,621 deletions. That makes it by far the biggest changeset for a minor version. For comparison:

    * between 2.5 and 2.6, there were 46,829 additions and 17,203 deletions
    * between 2.4 and 2.5, there were 32,913 additions and 20,594 deletions
    * between 2.3 and 2.4, there were 33,720 additions and 12,594 deletions

    WooCommerce 2.7 is introducing 2-3 times more changes than any previous version.

    Is it just me or have others been seeing similar issues with beta 1 and 2?

    Reply
    1. Mike Jolley Avatar
      Mike Jolley

      Found this comment in the spam 🙂

      The release is larger in part due to the introduction of the CRUD objects. The additions and deletions may be slightly skewed because some of that will be moving things around e.g. moving methods between the CRUD class and the legacy class.

      > These have been fixed promptly, but based on the severity and frequency of those types of issues, which is much higher than I’ve seen before in a minor release, I personally don’t think 2.7 should be released in 2.5 weeks. From what I’ve seen, it needs a lot more testing, both by the Woo team, and community, before it’s safe to release.

      Our extensions team are working through extension updates and patching/reporting things as they are discovered. We’ve caught a lot of issues this way. Core team has been doing the same. I’m hoping this covers *most* potential issues..

      We’ve been in beta since xmas. I’m not trying to deny the fact we missed some large issues as you pointed out, but it’s clear from this and past releases that the community usually does not start doing heavy testing until closer to final release – thats when we tend to have an influx of issues. Having a longer beta period doesn’t really change this, it just means that occurs a bit later.

      Past versions beta testing periods have been shorter, we’ve allowed for more time this time round:

      2.7 in beta from December, launching in March. 3 months.
      2.6 in beta from April, launched in June. 2 months.
      2.5 in beta from nov launched in Jan. 2 months.
      2.4 in beta from July and launched in Aug. 1 month.
      2.3 in beta from Jan to Feb. 1 month.

      What would you do differently? I’m not sure what else we can do from our side short of publishing more posts.

      Reply
      1. Brent Avatar
        Brent

        > What would you do differently?

        Good question. 🙂

        Firstly, I’d give more than 1 week for testing between tagging a release candidate and an official release. As you say, “the community usually does not start doing heavy testing until closer to final release”. That’s true enough that it’s almost a universal law of nature, but I also don’t agree with this part:

        > Having a longer beta period doesn’t really change this, it just means that occurs a bit later.

        That assumes when people will test is simply a factor of time. It also assumes its a fixed behaviour. It’s not. It’s in part a consequence of expectations around the stability of pre-release versions.

        With previous versions of WC, I’ve deliberately waited until closer to the RC period because there is usually so much flux in the beta period. I’ve been burned in the past for updating code to work with beta 1 or beta 2, only to find it’s broken again by the time RC1 is tagged, and I have to update it again. That wasted time is a compelling reason to wait. I’m sure I’m not the only one who has experienced this and acts accordingly now (though I started much earlier with WC 2.7 than I normally would given the severity of its changeset).

        An RC is really the first point in time when people can look at the code and feel confident its probably not going to change a lot before the official release. With that in mind, having 3 months of beta testing, but only 1 week for the RC, doesn’t make a lot of sense. It makes sense to give more time in that later stage after the RC (if deadlines are an issue, I’d give less time to betas to allow more time to RCs).

        Secondly, I’d give a public commitment that that the RC period will only change code to fix bugs. This is closely related to the first issue. It sets expectations on the stability of the codebase.

        Even if the RC period goes for a few weeks, it should not have any new:

        * functionality (like introducing a new logging system, as done in 2.7 beta-2)
        * enhancements (like updating Select2, as done in 2.7 beta-2)
        * major refactoring (there have been 40,245 additions and 18,417 deletions between 2.7 beta-1 and the current state of master)

        That gives people confidence that whatever is happening in their store with the RC is what will happen with the official release. This makes it less like that time spent testing code and clients’ stores prior to the official release will be wasted time.

        I personally would also give this public commitment on beta periods in future in the hopes that people would then be more inclined to start testing earlier. It’s too late for 2.7 to do that, but I still think making the commitment with the RC and giving more time for testing that would help achieve a smoother official release of 2.7.

        Thirdly, I’d publish all important docs about major changes at the same time that I want people to test & update their code. If I wanted people to test during the beta (which I would), I’d publish those docs before the beta to encourage them to test/update their code during that time.

        One of the major changes introduced in 2.7 is the introduction of data stores. This is a major new paradigm for WooCommerce codebase. The documentation on it was only published 12 days ago via the wiki: https://github.com/woocommerce/woocommerce/wiki/Data-Stores

        I spent a good amount of time trying to decipher how the data stores work during the early betas from the codebase alone. I can understand why many developers might look at that code, then decide to wait until there is some documentation on it before trying to work with it (or failing that, only work with it when they really have to, because their client/customer’s stores are broken after the official release).

        This pre-release period has had by far the best documentation being published of any WC release. But I do think many people only consider working with new code once docs are available to help them understand it. That’s also why I think a longer RC period will help now that more docs, and the blog posts on upgrading plugins etc. have been published.

        Finally, once RC is tagged, I’d ask developers, store owners and everyone else via WooCommerce Slack and elsewhere two questions:

        1. have you started testing your stores with WC 2.7 RC-1?
        2. if not, why not?

        Hopefully that would reveal more that could be done to increase pre-release testing.

        Those are 4 fairly simple things to do. I personally think doing them would influence my behaviour, so I’d hope they would help achieve that with other some other developers too.

        One final note to clarify why I think this all matters so much. When official releases are less stable, WooCommerce loses credibility and store owners have a bad experience with the software.

        Naturally the vast majority of the community won’t even look at pre-release versions. It’s unrealistic to expect everyone to test pre-release versions, but that doesn’t mean it’s not worth working hard to get more people, particularly developers, to test them and to find issues prior to release. Doing so helps everyone have a better experience with the official versions, rather than just using the early official versions as some kind of public beta testing period because it seems impossibly hard to get more people testing during the pre-release period.

        In the WooCommerce Community Survey, we found 3 relevant pieces of data on this topic:

        1. 60% of respondents said they update to new versions of WC either within a week of its release and/or as soon as I know its available. That means there is a lot riding on those early version being stable.
        2. 42% of respondents said they don’t test updates on a test/staging site before updating a live site, despite all the recommendations to do so. So the onus needs to be on WooCommerce to prevent issues on those live sites rather than expecting people will follow best practice in updating.
        3. 50% of people rank their confidence that their store will still work correctly after an update as 3/5 or lower (with 5 being the most confident). That means there is a lot of room to improve confidence with a lot of people, but also a lot of room to damage it given that 50% of store owner are very confident already.

        > Found this comment in the spam 🙂

        I figured it had been held for moderation. I assumed because I included 3 links in my comment (I’ll try to avoid doing that from now on).

        My comment was from a long lived WordPress.com account with previously approved comments, so it might also be worth looking into the comment spam policy.

        Reply
        1. Josh Kohlbach Avatar
          Josh Kohlbach

          Adding my voice as another extension developer.

          I agree with Manos when he says “Developers are teams/companies with their own roadmaps and resource constraints — they need a reasonably stable core before they start refactoring their own code”

          And I echo Max as well when he says “I think an RC also signals to the developer community at large (and merchants) that the release is ready for serious testing and QA”.

          Currently from our company’s perspective we’ve had to put other priorities on hold in order to put WC2.7 changes ahead. The 2.7 changes we were holding off on doing until RC (which is what we normally do).

          However when it was announced that there would be only 1 week between we figured that wouldn’t be enough time for proper testing and pushing updates on all of our products so we’re compatible on day 1.

          It just isn’t enough time so we, like many others by the sounds of it, started making our compatibility fixes around Beta 2 this time even though we knew there might be more changes coming down the pipe before RC gets here.

          I’m also concerned with the scope of the 2.7 release. There’s a lot of changes here and a lot of new features/paradigms to account for in testing.

          I’d propose two things for consideration:

          1. Extending RC time from 1 week to 2 weeks minimum. This can still be done for 2.7.
          2. For 2.8, locking down new feature scope after it goes into beta 1. We shouldn’t need 3-4 beta releases with new features every time. Enhancements/Improvements and Bug fixes only after beta 1 that would be more stable and allow developers to feel confident that by Beta 2, there aren’t going to be any more new surprises. Even if beta 1 takes twice as long I’m sure other devs that are working with WC would appreciate the stability.

          Really interesting discussion, I’m sure that the others are just as keen to hear back from you Mike as I am!

          Reply
      2. maxrice Avatar
        maxrice

        Ideally what I’d like is a longer RC period. While we’ve always started our testing early in the beta phase, there’s inevitably things that can change pretty dramatically from a Beta 1 to a Beta 3. That’s fine, but once an RC drops I’d expect nothing to be changed except for bug fixes. This is generally the best time for us to go through and really make sure that we’re 100% compatible and that changes that we put in place for compatibility won’t be broken later (as has been the case in the past when we’ve started testing/compatibility during the early beta period).

        I think an RC also signals to the developer community at large (and merchants) that the release is ready for serious testing and QA, but you can’t expect people to be able to accomplish that in a week or two. I think a month, at minimum, is the ideal timeframe. The side benefit here is that I think you’d see much faster adoption of the new version.

        Reply
      3. Manos Avatar
        Manos

        Agreed that a longer RC period would be a good idea. As voiced by Brent and Max, WC has a history of major changes happening during beta, which in turn makes developers wait for RC before they start any actual work. It’s a chicken and egg thing. Developers are teams/companies with their own roadmaps and resource constraints — they need a reasonably stable core before they start refactoring their own code, and that’s a process that can take months.

        It is difficult to get a reliable, critical mass of developers involved/interested in beta testing without involving them in the processes that shaped that code. The lack of interest you notice probably means people can’t easily follow what’s happening — so what’s lacking in the end is a shared feeling of ownership/participation that open source projects rely on in order to prosper.

        Reply
      4. Beka Rice Avatar
        Beka Rice

        To echo what some of the others have said here, I think a 1-week RC period is not appropriate given the scope of changes overall, but especially the level of changes in the beta period. And to echo what Manos said in terms of roadmaps, in terms of the 3rd party ecosystem, you never know when the beta, but especially, RC period will be, so it’s not like you can plan for it, especially given that as a company, you likely already have other things planned.

        There are several recurring themes we run into with compatibility updates:

        – The goal should be to submit extensions *before* the general WC release. For example, in the case of method visibility changes — I think this was WC 2.5 — this was imperative for smooth core WC upgrades (or some plugins could fatal), so that RC essentially becomes non-existent time for 3rd party devs.
        – In our case with WC 2.7, we’ve already had several extensions this round again that have been re-updated — some between beta 1 and beta 3, some that broke from being fully functional in beta2 to broken in beta 3 (Checkout Add-ons for example). As others have noted, we’ve all run into this as some point.
        – Because we end up duplicating work going back to re-test and fix numerous extensions, we end up having to delay any other bugs fixes or tweaks since every resource on our team gets devoted to several weeks of compatibility changes.
        – Due to the scope of work involved in compat and the fact that we may have to redo work, we end up trying to keep changes to a minimum and make larger changes (like moving to a data store fully) until after the release just because then we know what the code will actually look like — there’s not ample time to reliably do this work beforehand without just making more work for yourself later.

        To couple an in-flux beta with a 1-week RC means that essential you have no stable period to functionally make changes with. On top of it, to again echo Manos again, this coincides exactly with the one week a year SkyVerge is on our company retreat, and considering the months of planning and the resources that go into an annual company-wide meetup, we can’t very well just say, “well the WC developers on the team will skip this I guess, see you next year.”

        We are very happy to help with testing and review during the beta phase. Moreover, as Manos mentioned later, this doesn’t need to wait until a beta — we’d be happy to look at changes, planning, testing, or code reviews prior to this period 🙂 But essentially I think Brent hit this one on the head — shorter betas vs longer RC periods would be preferable.

        Reply
    2. Mike Jolley Avatar
      Mike Jolley

      To respond to all the voices in this thread, this is one of my worries:

      > The 2.7 changes we were holding off on doing until RC (which is what we normally do).

      If developers hold off any kind of updates until RC, if a design flaw was to be found whilst doing those updates we’re already in lockdown, which means we have to 1) fix it anyway and change a bunch of stuff in the RC, 2) delay the release by unknown periods of time. Neither of these scenarios reflect well on us, and both invite criticism from developers.

      This is the main reasoning behind the long beta period and changes in that period. More time for feedback and to react to extension issues, especially with changes on this scale.

      Brent mentioned a lot of changes in this release from beta 1 -> beta 4. This is largely due to updating extensions in house and finding things we could improve with CRUD/data stores. If those issues did not surface until RC, we’re be in deep trouble.

      We did cause from regression issues here however which could have been handled better in the betas.

      > It is difficult to get a reliable, critical mass of developers involved/interested in beta testing without involving them in the processes that shaped that code.

      Hopefully when we start our chats in slack with you folks we can stay more in touch and these concerns can be raised before dates are announced.

      > Extending RC time from 1 week to 2 weeks minimum. This can still be done for 2.7.
      > To couple an in-flux beta with a 1-week RC means that essential you have no stable period to functionally make changes with

      Good points. I think we can reasonably extend things “officially” when we make the announcement. 2 weeks sounds fair, but as was the case anyway, if issues are discovered and need fixing in that period, it makes sense to extend or do further RCs until everyone agrees it’s stable. @mattyza

      Reply
      1. Manos Avatar
        Manos

        Extending the 2.7 RC period is a rather painless decision to make, but aside from that, it would make a lot of sense to plan ahead and see how we can break this vicious circle. Some ideas:

        – Set a goal to release more stable betas in the future. This would send a signal that’s necessary to convince developers to dedicate resources into updating their plugins/extensions/code earlier than they do now. More people working with betas will result in earlier bug reports, earlier fixes and more stable RC’s.

        – To release more stable betas in the future, it might make sense to move plugin/extension testing to pre-beta, at least for some popular/demanding extensions. In-house extensions would be very good candidates for this. The 2.7 beta would have been more stable if some of the more complex extensions had been tested/updated during late-alpha, and some docs/guides written during that time. Many extensions in the official marketplace have their own unit tests which make it a lot easier to find showstopper bugs/issues in core early.

        – Documentation work on “what’s changed/new” and plugin/extension testing should be done earlier than beta. These processes can yield an unexpectedly good insight of issues hidden in the codebase. Docs are often seen as a chore but the preparation work involved can uncover major issues, especially when the code is written in an agile manner.

        – A more open, inviting way of defining and executing the core roadmap. Some things to consider: Communicate more on medium/long-term intent. Collect thoughts/feedback on high-level decisions. Provide more details in issues: Try to always include details (problem definition, suggested course of action, task lists) to encourage participation, even if you don’t expect anyone else to jump in and help (if you don’t let them, they won’t). Avoid gigantic commits. Identify and invite a “critical mass” developers you wish to participate in early beta / late alpha testing and maintain an ongoing relationship with them. Participation, loyalty, trust, love — these go hand-in-hand.

        Reply
  3. Egbert Avatar
    Egbert

    Hi. I cloned my site into beta.vandenbussche.nl. Checked the usual things and all seems OK. Then I downloaded 2.7 beta3, unpacked the zip and ftp-ed the woocommerce tree to the beta site. I gave appoval to update the database to the latest version. So far so good. I have some debugging switched and when I go to the orders submenu I get a load of notices of a message that claims to be added in 2.7. The following location is mentioned: /var/www/clients/client3/web10/web/wp-includes/functions.php on line 4136 (ignore the webroot please). First part of the message says: “Notice: id was called in a wrong way. Order properties should not be accessed directly. ” (translated back; first part was in Dutch).
    Dunno if it is of any use to you devs, but i’m a bit reluctant to blindly upgrade to 2.7… If you want access, just let me know. Beware: it is in Dutch.
    CU, Egbert Jan, NL,

    Reply
    1. Mike Jolley Avatar
      Mike Jolley

      Notices like this are just advirsories for extensions. Your live site should have such notices disabled.

      Reply
      1. Egbert Avatar
        Egbert

        Thanks. I better turn off debugging then until I really need it.
        Egbert

        Reply
    2. therealhelgatheviking Avatar
      therealhelgatheviking

      Egbert, anywhere you are accessing and object property directly (so things like `$order->id` or `$product->id` ) will throw the notice you are receiving. To cure that you have to switch to `$order->get_id()` and `$product->get_id()`. However, if you still need your code to be backcompatible you need to test which version of WC you are using because `$product->get_id()` with WC2.6 will throw a fatal error since `get_id()` doesn’t exist.

      Reply
  4. Joseff B Avatar
    Joseff B

    So we upgraded to the Beta 3 and ran into a fatal error right off the back:

    PHP Fatal error: Call to undefined method WC_Order::read() in /site/wp-content/plugins/woocommerce/includes/abstracts/abstract-wc-legacy-order.php on line 627

    We messed around with it and it seems to originate in the data objects abstract not eventually getting the global read object in woocommerce/includes/abstracts/abstract-wc-data.php line 469

    This being about a week off of RC and 2 – 3 from release we’ve operationally decided to wait until June-ish to get any patches that other brave souls suffer through before going 2.7.

    It’s just not ready.

    Reply
    1. Mike Jolley Avatar
      Mike Jolley

      It’s important that people such as yourself __do__ report these issues rather than leave to others. Why not report on Github? This one for example is from using a `->get_order()` method somewhere in your site. Core doesn’t use this method, so it’s not caught by unit tests.

      > It’s just not ready.

      Thats why we have beta. If you think we’d just push the button without a period of stability first you’re mistaken.

      Reply
    2. Mike Jolley Avatar
      Mike Jolley

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

      Reply
  5. Daniel Musat Avatar
    Daniel Musat

    I’m really concerned about negative fee (bug/feature), as I use this on my shop as well as on couple of shops I build for company that I work. How we will be able to achive the same results from now on?

    Reply
    1. Mike Jolley Avatar
      Mike Jolley

      We’re going to revert for now, possibly with a notice, https://github.com/woocommerce/woocommerce/issues/13325 but ideally this should be switched to coupon logic. We’re introducing a discounts API in the future. Since negative fees are not officially supports, if calculations were to bork up you’d be on your own to fix them.

      Reply
  6. Weekly Roundup: February 24, 2017 – Sell with WP

    […] has announced beta-3 for the upcoming version 2.7 release, which means any merchant with custom code should look to do some testing on a development […]

    Reply
  7. WooCommerce Multilingual 4.1 – beta 1 – WPML

    […] Up to date with important changes in WooCommerce 2.7 […]

    Reply
  8. WooCommerce Wochenrückblick #24: 360 Grad Bilder, Plugin-Entwicklung und Massenbearbeitung von Produkten | WooCommerce Blog

    […] Die Beta-Version 3 von WooCommerce 2.7 kann getestet werden […]

    Reply
  9. Oz Avatar
    Oz

    Please add searching a product using “product tags” for each product in WooCommerce. This is extremely important as none of plugin on the market can do that 1100% accurate and they all have compatibility issue.

    Thanks,

    Oz

    Reply
  10. WooCommerce 2.7 Release Candidate – Develop WooCommerce

    […] more information about what’s new in 2.7, check out the Beta 1, beta 2, beta 3 blog posts. We also have some compatibility example posts and posts about our new […]

    Reply
  11. Important update regarding the upcoming WooCommerce release; 2.7 will be 3.0.0 – Develop WooCommerce

    […] discussions and from feedback in our RC/beta posts it was clear developers would like a little more time to test and would appreciate longer RC […]

    Reply
  12. WooCommerce 3.0.0 RC1 – Develop WooCommerce

    […] more information about what’s new in 3.0.0, check out the Beta 1, beta 2, beta 3 blog posts. We also have some compatibility example posts and posts about our new […]

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *