Develop WooCommerce

The official WooCommerce development blog

WooCommerce 3.2 Beta is here! — August 30, 2017

WooCommerce 3.2 Beta is here!

Today we’re pleased to announce that WooCommerce 3.2 is available for beta testing! You can download it here.

Release highlights

3.2 is our second minor release this year. There should be no breaking changes, new functionality should exist in a backwards-compatible manner, and updating from 3.1 or 3.0 should be a hassle free! Here is what to look out for in the update.

New: Adding and removing coupons from orders

Up until now, coupons have been deeply coupled with the cart making reuse (and testing) extremely difficult. In 3.2 we’ve refactored the cart and coupon classes to improve this.

Due to these changes, we were able to implement a new admin feature – the ability to apply coupons (and remove coupons) from placed orders.

2017-08-23 13.52.08 2

This was a popular feature request on the ideas board. To use it, simply edit an order, click the “apply coupon” button and enter a coupon code. The rest will be done automatically.

You can read more about these changes here.

SelectWoo; better enhanced select boxes

screen-shot-2017-08-08-at-1-06-34-pm.png

In order to improve accessibility (particularly in screen readers) we’ve forked Select2 into a custom version called SelectWoo. This is used for things like state/country select boxes and extensively in the admin area.

We’ve also rolled SelectWoo out in 2 new areas; for the fields in the shipping calculator on the frontend, and for layered nav when using “or” type queries.

You can read more about SelectWoo here.

Pre-update extension version checks

WooCommerce 3.2 adds support for a new plugin header (text added to your plugins readme.txt) to determine which version of WooCommerce a plugin is tested up to. This header is named WC tested up to.

Before minor and major updates, WooCommerce will check these versions and display either an inline warning, or modal window warning (for major updates) to advise the user.

Screen Shot 2017-08-25 at 1.35.46 PM

You can read more about this feature, including instructions on what headers to add to plugins, here.

Subscription management improvements

In order to make it easier for customers who use a large number of extensions on their sites we have added some new filters to allow you to filter your WooCommerce.com extensions by installed/activated/download/update available etc. along with notification icons in the both then Extension menu item, as well as the ​​​My Subscriptions tab, making it easier for you to see when your WooCommerce.com extensions have updates available.

A new ‘share by’ label for shared subscriptions has also been included, which is part of a bigger project being worked on for the sharing of multi-site subscriptions bought on WooCommerce.com.

A dedicated products shortcode

We’ve unified the product shortcodes into one single, consolidated products shortcode which supports the options of all legacy product shortcodes. This replaces [product_category][featured_products][sale_products][best_selling_products][recent_products][product_attribute], and [top_rated_products].

You can read more about the new shortcode here.

Everything else…

Other features include:

  • Like the search helpers introduced in 3.1, we’ve done the same for products. You can see our usage wiki here.
  • We’ve simplified the ability to resend order details to customers by including one option to “resend”.
  • We’ve added store street address, city and postal code to settings for use by plugins. This is a minor change, but a feature nevertheless, and something important to extensions.
  • Wrapping values in quotes now let’s you use commas in the product CSV importer. This is an enhancement.
  • If a fatal error occurs, WooCommerce will catch and log it to be viewed in WC > Status > Logs. This can be useful in debugging.
  • We added drag and drop sorting on the grouped product field to control display order of products.
  • The product category filter on the products screen has been AJAXified for faster loading.
  • Added a new option to control the maximum depth of categories shown in the product category widget.
  • Allowed sorting options to be shown when viewing search results. This defaults to sorting by relevance.

On top of the new features, there are a variety of minor tweaks, new hooks, and fixes in this minor release. We won’t go into detail here, but you can see the full list of changes in the readme if you’re interested!

Template file changes

When editing core template files we bump the version so themes know they need to update custom versions. The following files were updated in 3.2:

  • mini-cart.php – Changes to support AJAX remove from cart buttons.
  • shipping-calculator.php – Fix to state field naming and support for select2.
  • order-receipt.php – New. Moved from template function.
  • downloads.php – New table of customer downloads.
  • thankyou.php – Download displays made consistent.
  • order-downloads.php – Download displays made consistent.
  • email-downloads.php – Download displays made consistent.
  • order-details-customer.php – Download displays made consistent.
  • email-order-details.php – Download displays made consistent.
  • email-order-items.php – Download displays made consistent.
  • email-addresses.php – Download displays made consistent.
  • order-details.php – Download displays made consistent.
  • my-account/orders.php – Action buttons moved to filter.
  • form-tracking.php – Improved error handling.
  • single-product-reviews.php – Fixed invalid markup.

Deprecated functions and methods

  • Accessing internal meta keys from a CRUD object will throw a usage notice in 3.2.0.
  • WC_Query::search_post_excerpt is no longer needed or used. WordPress handles excerpt searches.
  • WC_Query::remove_posts_where is no longer needed or used. WordPress handles excerpt searches.

Release schedule and testing

We’re hoping to keep WooCommerce 3.2 in beta for the next 3 weeks. If you’re a developer please check extensions and themes are compatible to be safe.

Release Candidate 1 will be tagged on September 20th and will remain in RC for a further 2 weeks until October 4th which is our target launch date.

If you’d like to help us test, you can download the release from Github. We posted a nice little write-up on beta testing here which should get you started. Please read that and jump right in!

If you’re like to help translate 3.2, you’ll find it on the development branch on translate.wordpress.org.

Thanks to all of our testers and contributors.

New version check in WooCommerce 3.2 — August 28, 2017

New version check in WooCommerce 3.2

WooCommerce 3.2 will be released with a new version check feature. If you have active plugins that have not declared compatibility with the latest version of WooCommerce a variety of helpful warnings display when you try and upgrade WooCommerce. These messages will advise you about how you can safely upgrade in a way that prevents plugin errors that lead to broken features and store downtime. WooCommerce will also prevent itself auto-updating if there are incompatible plugins.

You have to already be on WooCommerce 3.2 to get this feature, so the first time you may see these sorts of messages will be when upgrading to WooCommerce 3.3.

Adding version check support to your plugins

The feature works by checking the active plugins’ headers to determine compatibility with WooCommerce. This requires the cooperation of the plugin development community. If you are a plugin developer it is simple and straightforward to add support for the version check to your plugins. There are just two new headers you need to add:

/*
 * Plugin Name: WooCommerce Barter Gateway
 * Plugin URI: https://wordpress.org/plugins/woocommerce-gateway-barter/
 * Description: Take payments by bartering crops and livestock.
 * Author: WooCommerce
 * Author URI: https://woocommerce.com/
 * Version: 3.0.7
 * Text Domain: woocommerce-gateway-barter
 * Domain Path: /languages
 * WC requires at least: 3.0.0
 * WC tested up to: 3.2.0
 */

There are some great benefits to adding the headers and keeping them current:

  • You will have to field less complaints from users that the new WooCommerce version broke your plugin. They will have clear warnings about the dangers of upgrading when the plugin is incompatible. This should reduce your support load when new versions of WooCommerce are released.
  • You will not have to rush updates to your plugin. If a user upgrades WooCommerce and your plugin breaks you are under a lot of pressure to release an update fast. If the user waits until a compatible version of the plugin is released before updating WooCommerce you do not have this problem.
  • Users will trust your plugin more. By adding the header you are letting the user know that the plugin has been tested, works with their version of WooCommerce, and is actively maintained to be compatible with WooCommerce.

The headers should be updated after each major (4.0.0) and minor (3.2.0) WooCommerce release. They do not have to be updated after patch releases (3.2.1). You should ideally have these headers in your plugins by WooCommerce version 3.3.0 to get the benefits.

August 29th: Dev Chat #10 — August 25, 2017

August 29th: Dev Chat #10

The next chat will be on August 29th at 16:00 UTC in the #core channel of the WooCommerce Community Slack. If you don’t already have access to the group, you can request an invite at the bottom of the WooCommerce developers page.

Here is the agenda:

  • 3.2 beta
  • Coupon & cart improvements
  • Extensions version check
  • SelectWoo beta 2
  • Roadmap

If you have anything to propose for the agenda or related to the above, please leave a comment below.

See you there!

p.s. if you missed something in the last dev chat, you can recap our summary here.

Coupon and cart improvements in 3.2 — August 24, 2017

Coupon and cart improvements in 3.2

For WooCommerce 3.2 we set out to tackle some long-standing issues with our coupon and cart classes to both improve test coverage, and make calculations more stable. For anyone who has looked under the hood at the cart and coupon classes in core you’ll know that they are very deeply coupled and coded in a way which makes writing unit tests very difficult.

To solve this, in 3.2 we’ve introduced a few new classes and refactored our cart.

  • WC_Cart_Totals class takes a cart object, performs calculations, and sets the totals once complete.
  • WC_Discounts class takes a cart/order object and lets you apply coupon discounts programmatically, returning the discount amounts.
  • WC_Cart_Fees class houses the cart fees API. Interaction with this is unchanged.
  • WC_Cart_Session class houses the cart sessions code.

We’ve also changed where coupon validation and discount logic is found to make things more reusable and to make coupons less reliant on the global cart; WC_Discounts handles validation (I.e. is the coupon valid for the given items), and also handles the discount amount calculations.

To maintain backwards compatibility, the old discount methods are left in place (deprecated) and any filters/actions from those methods have been moved to the new methods.

With the new classes, we can now run unit tests on each component, for example, we can pass some items to the WC_Discounts class and see if it calculates the correct expected totals. The same applies to WC_Cart_Totals—these are now testable independently from the global WC_Cart object.

This is great news for everyone; we can now test many more test cases, add new tests if calculations fail for a certain use case, and we can ensure test cases continue to pass making everything much less brittle.

New! Apply discounts outside of the cart 🎉

A huge advantage with the new system is that we can now easily apply discounts for non-carts. I’m talking about orders!

Users can now add/remove coupons in the admin backend without doing manual calculations like in older versions.

2017-08-23 13.52.08 2.gif

Adding and removing coupons still tracks usage counts, and handles all calculations for you. This was one of the larger feature requests on the ideas board. ✅

Fixing fees

Fees are applied in similar fashion in 3.2; just enter the fee amount (percent or fixed) and it will apply.

We also know that some users are currently exploiting fees to apply negative amounts, so we’ve fixed the way in which taxes get applied in those cases. Negative fees will now apportion taxes between all other items, and will not make the cart total go below $0.

Coupon logic improvements

Rounding can be difficult for coupons, because in most cases, to keep taxes correct we need to split the discount across all items in the cart rather than simply remove an amount from the total.

When you split a discount across the cart, naturally, half cent values could occur which in turn can cause rounding issues once everything is summed up.

To help mitigate this we’ve tweaked the discount logic to only deal with cent values. Once split between items, any remainder is applied one line item at a time until exhausted. The final total will then equal the applied discount total. This is most important for fixed cart discounts.

If you’re interested, you’ll find the code here. Again, this is all covered in unit tests to ensure the logic makes sense!

Ready for testing

The above changes are now live in master and will be part of 3.2. Please give them a test and let us know your feedback!

If you do spot a backwards compatibility issue, please let us know immediately. 3.2 is a minor update so we must keep things backwards compatible at all costs 🙂

Dev chat summary – August 15th 2017 — August 16, 2017

Dev chat summary – August 15th 2017

This post summarizes the dev chat meeting from August 15th (agenda, Slack archive).

WooCommerce 3.2 update:

  • Last thing to work on is the Webhooks CRUD
  • The discounts/coupon API work is merged into master. Dev blog post coming this week.
  • Asked developers to check against master coupons for compatibility due to the refactors.
  • Asked for more feedback (user feedback) on SelectWoo which is also in master.

Roadmap update:

  • Still looking at tools. Likely going with Trello for the public roadmap.
  • The setup should be columns for each quarter, card per item, with user-friendly, non-dev speak descriptions.
  • vs Github, Github is dev-speak. And github is for the technical implementation details. Roadmap is user facing/high level.

Separate payments from orders:

Other:

  • WC Dashboard idea to house messages/notices.
  • Frontend things like checkout not getting much attention. To be worked on later in the year.
  • Re-opened the checkout issue for feedback.
  • Stock add/subtract from CSV import accepted. Needs logging on github.