Recent Updates Toggle Comment Threads | Keyboard Shortcuts

  • Mike Jolley 9:57 am on July 2, 2015 Permalink | Reply
    Tags:   

    Making Geolocation Static Cache Friendly in 2.4 

    WooCommerce 2.3 introduced a neat feature which allowed you to geolocate your customers to set their initial location, showing correct taxes and shipping values without the customer needing to input their address.

    Although this worked well, we discovered that it was not fully compatible with static caching plugins. Here is an example of the problem:

    1. Hans from Germany visits the store and looks at a product.
    2. Hans sees the German taxed price.
    3. The page is then cached.
    4. Charles from the UK visits the store and looks at the same product.
    5. As the page is cached, he sees German prices, rather than UK prices.

    Additionally, if the entire site was cached, the geolocation would never actually take place because its powered by a PHP script which won’t run on cached pages. This can be confusing to customers.

    We looked at possible solutions and came to the conclusion that JavaScript would be needed, in combination with a way of making pages unique based on user.

    Geolocation, with a hint of Ajax

    To solve this issue, we’ve added a new option to set the user’s location called “Geolocation with page caching support”. Here is how this works:

    1. When a customer visits a page on the site, an ajax call is fired in the background which geolocates that user via ajax and returns their location.
    2. The returned location is compared to the users known location. If the location is not yet known, or the location has changed, the page redirects back to itself with an extra querystring. e.g. v=12345 This is a hash based on the user location.
    3. The hash causes cache invalidation – the new page (with querystring) will be cached separately.

    If a customer from Germany visits a page, he will get a hash based on Germany – he will only see cached versions of pages from other German customers. This works around the caching issue, without needing to disable it completely.

    The negative from this is the extra ajax request per page, however, this is necessary – without this, no geolocation would take place on a cached page.

    This new feature will be available in WooCommerce 2.4 and can be tested by using our master branch on Github. The issue was reported here.

     
  • Mike Jolley 12:59 pm on June 16, 2015 Permalink | Reply
    Tags:   

    Simplifying Flat Rate Shipping in WC 2.4 

    One of our main goals with the upcoming 2.4 release has been usability, particularly for new users. A good example of this being the new onboarding wizard which should help new users get started without seeing complex settings screens.

    Shipping has always been problematic in terms of complexity, but has gotten worse over the year(s) due to feature requests and trying to account for more advanced use cases. Flat Rate Shipping is supposed to be simple. But lets look at the 2.3 UI for this a moment:

    2015-06-16 at 12.15

    Rather than having just a ‘flat rate’ we have additional costs (that can be per order, class or item), shipping classes with more costs and fees, add-on rates… A new user, or user new to eCommerce in general, is not going to understand all of these options. It’s just overwhelming. And using the various options correctly is not easy and mistakes are easy to make.

    In support we see flat rate troubling users often. In our premium support area, at least 15% of all shipping tickets have been related to flat rate shipping. And so with 2.4 we challenged ourselves to simplify this shipping method.

    Lets look at what we can do with the current UI. We can:

    1. Set a cost for the order (flat rate)
    2. Set a cost for each type of product by shipping class
    3. Set a handling fee per type of product, with a minimum fee if needed
    4. Charge the additional costs per order, class, or item.
    5. Offer extra rates with a small increase in cost (add-on rates)

    With any simplification points 1 to 4 need to be ‘supported’ to prevent breakage to existing flat rates. Also:

    • Point 1 is the most important field as its key to having a flat rate.
    • Point 2 should only be shown when needed i.e. when the user has product shipping classes, not beforehand.
    • Point 3 should not be a separate field; the costs are merged anyway, so extra fields will cause confusion when it behaves no differently in use.
    • Point 4 only applies to point 2 and 3 and should somehow be reworded or moved to prevent confusion with the main cost field (1).
    • Point 5, which is for extra rates, should be supported if in use, but is too hard for new users to make use of and thus should be dropped from the UI (with a code fallback to keep it possible and easy to implement if needed).

    Here is our solution.

    Removing all the things

    This may shock users at first, but lets look at our new Flat Rate UI for a new user without shipping classes setup yet, and no existing settings.

    2015-06-16 at 12.41

    That’s it. Nothing scary – just a cost field to add a flat rate, as it says on the tin. This covers point 1.

    Now lets assume the user creates a product shipping class. This is what they will see:

    2015-06-16 at 12.44

    Still not overwhelming. The user has created a shipping class and thus knows what they are. There is also only one cost field; no extra fee field. Finally, the calculation type field which applies only to shipping class costs is visible at this point. This covers points 2, 3 and 4.

    What about backwards compatibility?

    If a user of 2.3 flat rates upgrades, an upgrade routine will map their old settings to the new settings.

    What about add-on rates?

    Users of the overly complex add-on rates will still see this field and it will continue to function. New users will never see this field – it will remain hidden. We’ll eventually deprecate this fully.

    Hooks will allow easy flat rate additions though usage of a few lines of code, such as:

    This gives full control over the extra costing too.

    What about power users?

    What if you want to charge a flat rate per item? Or a percentage based cost? Or enforce a minimum ‘fee’? You could in the old version, and you can in the new version. The cost fields support sums.

    100 for the order, and 10 per item

    100 for the order, and 10 per item

    There are also cost and fee placeholders:

    100 cost and a 10% fee of at least $2.

    100 cost and a 10% fee of at least $2.

    Again, new users don’t need to worry about this, but it’s there when needed and will work after upgrading.

    What about international shipping?

    The international delivery shipping method, loosely based on flat rate shipping, will be identical bar some extra availability fields to limit countries that can use it.

    Trying it out

    Want to experiment with Flat Rates? Until merged into master, the branch is here. The code is now in our master development branch.

    Thanks for reading!

     
  • Mike Jolley 8:43 pm on June 10, 2015 Permalink
    Tags:   

    WooCommerce 2.3.11 Security and Maintenance Release 

    The WooCommerce 2.3.11 release is now available via WordPress.org or automatic update in your administration panel.

    A total of 32 commits made it into this release.

    This release includes several bug fixes which you can read about in the changelog, and a security fix discovered by the Sucuri team. This issue was within the PayPal payment gateway. Full details can be found on the Sucuri blog here.

    (As always, the comments on this post are closed because this is not the right platform for support requests.)

     
  • Mike Jolley 4:13 pm on June 1, 2015 Permalink
    Tags:   

    WooCommerce 2.3.10 Security and Maintenance Release 

    The WooCommerce 2.3.10 release is now available via WordPress.org or automatic update in your administration panel.

    A total of 71 commits made it into this release.

    This release includes several bug fixes, and extra escaping/hardening/security fixes following a security review. Read more about the fixes in the changelog.

    This release also includes some improvements to the transients caching system in order to reduce the amount of rows created in the options table. These changes include:

    1. Flushing expired transients during upgrade
    2. Flushing version transients when a transient version is increased e.g. during product save
    3. Reducing the amount of transients per product by combining rating and review transients.

    (As always, the comments on this post are closed because this is not the right platform for support requests.)

     
  • Mike Jolley 8:33 pm on May 19, 2015 Permalink
    Tags:   

    WooCommerce 2.3.9 Fix/Security Release Available 

    The WooCommerce 2.3.9 release is now available via WordPress.org or automatic update in your administration panel.

    This release includes fixes for several minor issues, and updates PrettyPhoto to 3.1.6 which resolves an XSS issue reported here. Read more about the fixes in the changelog.

    A total of 25 commits made it into this release.

    (As always, the comments on this post are closed because this is not the right platform for support requests.)

     
  • Mike Jolley 2:19 pm on April 20, 2015 Permalink
    Tags:   

    WooCommerce 2.3.8 Fix Release Available 

    The WooCommerce 2.3.8 release is now available via WordPress.org or automatic update in your administration panel. Thanks to all of our contributors who’ve been helping out.

    This release just fixes some minor issues. Read more about the fixes in the changelog. A total of 42 commits made it into this release.

    (As always, the comments on this post are closed because this is not the right platform for support requests.)

     
  • Mike Jolley 12:53 pm on March 18, 2015 Permalink
    Tags:   

    WooCommerce 2.3.7 Fix Release Available 

    The WooCommerce 2.3.7 release is now available via WordPress.org or automatic update in your administration panel. Thanks to all of our contributors who’ve been helping out.

    This release just fixes some minor issues. Read more about the fixes in the changelog. A total of 16 commits made it into this release.

    (As always, the comments on this post are closed because this is not the right platform for support requests.)

     
  • Mike Jolley 1:53 pm on March 13, 2015 Permalink
    Tags:   

    WooCommerce 2.3.6 Fix/Security Release Available 

    The WooCommerce 2.3.6 release is now available via WordPress.org or automatic update in your administration panel.

    This release includes fixes for several minor issues, including some edge case issues such as redirect loops when using memcache, and 2 potential security issues within admin. Read more about the fixes in the changelog.

    A total of 215 commits made it into this release.

    (As always, the comments on this post are closed because this is not the right platform for support requests.)

     
  • patrick 6:43 pm on March 5, 2015 Permalink  

    How to Test Your Extensions the WooThemes Way 

    There seems to be a bit of confusion in our community about how and when you should test your extensions against a new version of WooCommerce. There is no right or wrong way to test extensions so I’ll tell you what we do here at WooThemes.

    1. Subscribe to this blog and pay attention to the big changes as they come out. Ex. in 2.3 the coupon system was refactored. If you have an extension that deals with coupons then it’s advisable to test right then and make any updates you have to make.
    2. When the first beta is announced on the develop blog it’s time to test your extension. Betas are usually very similar to the final release. In rare exceptions features are added or deleted here but usually after the first beta there are only bug fixes.
    3. When the first release candidate is announced do another quick test to make sure your extension works. If something did make it into the beta to affect your plugin this is where you catch it. The release candidate is strictly bug fixes. If it works during the release candidate phase it should work when the new version of WooCommerce is released.

    We do all of our development on the master branch so whenever you want to test WooCommerce it’s best to use the master branch.

    There are a couple of our extensions that are quite large and extra testing goes into these plugins. Plugins like Subscriptions for example usually has several weeks or months of testing to make sure that everything will work against the newest version of WooCommerce. If you have a very large or complex extension then it’s worth testing as we add features into WooCommerce before we release the first beta.

    I hope this clears up how we do our own testing and hopefully it should help you do yours. :)

     
    • Caspar Hübinger 12:34 pm on March 6, 2015 Permalink | Reply

      We do all of our development on the master branch so whenever you want to test WooCommerce it’s best to use the master branch.

      Awesome! I had been told the direct opposite during development of 2.3. Good to know which branch to pull for early testing now. 😉

      • claudiosmweb 2:32 pm on March 6, 2015 Permalink | Reply

        Use the master branch just for now. Soon the master will be for 2.4 and will have a lot of issues. But will have the 2.3 branch, where you can test the current support and master will be stable just close to a beta version as I said before.

  • claudiosmweb 4:44 pm on February 20, 2015 Permalink  

    WooCommerce 2.3.5 Fix Release Available 

    The WooCommerce 2.3.5 release is now available via WordPress.org or automatic update in your administration panel. Thanks to all of our contributors who’ve been helping out.

    This release just fixes some minor issues. Read more about the fixes in the changelog. A total of 45 commits made it into this release.

    (As always, the comments on this post are closed because this is not the right platform for support requests.)

     
c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
shift + esc
cancel