Changelog
Check out the latest releases from the WooCommerce project.
Subscribe to all release posts via our RSS feed.
-
Let’s face it, product images are a vital driving force behind sales. Combine that with thousands of WooCommerce-enabled themes out there and it can become difficult to have product images that look good out-of-the-box on all of them. WooCommerce 3.3 aims to improve that with some changes to image size settings and the rendering of images.
WooCommerce 3.3 introduces new image cropping settings. Store owners can now control the width and height of their main images, as well as the cropping with visual cues as to what the images might look like on the frontend. Apart from that we are also giving themes with explicit WooCommerce support more control over image settings to ensure that product images look good out of the box.
Theme Support
In the past, theme authors had to make updates to settings directly via
update_option
calls to change the settings in the DB. This resulted in store owners experiencing issues where they would change image settings in the admin area just to have it revert back to what the theme updates it to on each page load. With WooCommerce 3.3 theme authors can now declare image sizes via theadd_theme_support
function. Declaring image sizes this way will take priority over any other settings and also hide the image settings section in the admin area.add_theme_support( 'woocommerce', array( 'thumbnail_image_width' => 150, 'single_image_width' => 322, ) );
Thumbnail Cropping
A new thumbnail cropping section in the customizer will allow store owners to select one of three cropping ration settings with visual cues:
- 1:1 (Square scropping)
- Custom (Store owner can enter a custom aspect ratio)
- Uncropped (Preserve single image aspect ratio)
Image sizes are then calculated based on the cropping option selected and the image width. It is important to note that Single Product Images are uncropped and not affected by the cropping settings.
Automatic Thumbnail Resizing
Apart from the new theme support and cropping settings, we have also introduced automatic thumbnail resizing. In the past when you changed a product image WordPress would not actually resize the image and you had to install a plugin like Regenerate Thumbnails in order to have WordPress resize the images for you. In WooCommerce 3.3 we have now added on-the-fly thumbnail resizing as well as background thumbnail resizing.
How this works is when you change your image settings WooCommerce will kick off a background process that automatically resizes all your images for you to the correct new sizes. While the images are being resized or if for some reason the resizing did not run or complete, we’ve added on-the-fly resizing to the frontend, ensuring that your images will always look great to your customers.
The on-the-fly resizing also plays an important part in ensuring that you have a great experience when visually editing your site through the customizer. If your theme adds support for it you can play around with different image sizes and cropping settings from within the customizer and see the results instantly.
These changes are already in the master branch and will be going out with the WooCommerce 3.3 release in January 2018.
If you have any thoughts or feedback you would like to share, feel free to leave them in the comments.
-
It used to be that you had to find specific WooCommerce-compatible themes for your store. In the upcoming release we have made big improvements in how WooCommerce handles themes that were previously unsupported, so now you can run WooCommerce with any theme!
On themes that don’t formally declare WooCommerce support the templates will render inside the content. This keeps everything looking natural on the site while ensuring everything still works great. Here are some before and after examples using themes that do not formally declare WooCommerce compatibility:
Bassist theme with WooCommerce 3.2 Bassist theme with WooCommerce 3.3 Hamilton theme with WooCommerce 3.2 Hamilton theme with WooCommerce 3.3 In order to make sure everything looks as nice as possible and so customers can see products well on themes with narrow content areas, lightbox and zoom will automatically be enabled for themes that don’t formally support WooCommerce. If your theme currently declares WooCommerce support the theme will still have full control over whether lightbox and zoom are enabled on products.
One thing that you will notice is that the product reviews area is not present on these themes. In our testing the CSS used by most themes that do not support WooCommerce did not work well with WooCommerce’s CSS for review styles. These themes will use the regular comments form. Themes that declare WooCommerce support will still use the review template.
Column and row settings
We’ve also added the ability to select the number of rows and columns displayed in the shop to the customizer. Everything updates dynamically so you can preview how your shop will look while changing the settings. The width of the columns will automatically increase or decrease depending on your settings, so everything should look nice and fill the available area. This feature is available on all themes.
Theme developers can set the minimum, maximum, and default settings for the columns and rows when declaring WooCommerce support:
function my_custom_woocommerce_theme_support() { add_theme_support( 'woocommerce', array( // . . . // thumbnail_image_width, single_image_width, etc. // Product grid theme settings 'product_grid' => array( 'default_rows' => 3, 'min_rows' => 2, 'max_rows' => 8, 'default_columns' => 4, 'min_columns' => 2, 'max_columns' => 5, ), ) ); } add_action( 'after_setup_theme', 'my_custom_woocommerce_theme_support' );
Testing and feedback
These changes are merged into our master branch on GitHub if you want to try things out. If all goes well, they will be part of 3.3 release in January.
Thoughts and feedback welcome in the comments.
-
We have been talking a lot about CRUD since 3.0.0, and the reason is because we want move certain features from the WordPress post database table to new database tables. This improves the performance and scalability of those features. Starting with 3.3.0, our webhooks will not use the posts and comments database tables anymore, and we finally have our first feature migrated to custom tables!
New Webhooks CRUD
Webhooks are a feature that 3rd party developers do not use often or heavily customize, so this make it easy to start moving all of the necessary data for webhooks to a new table.
With CRUD it is now easier to manipulate webhooks too:
// Creating a new webhook. $webhook = new WC_Webhook(); $webhook->set_user_id( 1 ); // User ID used while generating the webhook payload. $webhook->set_topic( 'order.created' ); // Event used to trigger a webhook. $webhook->set_secret( 'secret' ); // Secret to validate webhook when received. $webhook->set_delivery_url( 'https://webhook-handler.com' ); // URL where webhook should be sent. $webhook->set_status( 'active' ); // Webhook status. $webhook->save(); // Updating webhook: $webhook = wc_get_webhook( $webhook_id ); $webhook->set_status( 'disabled' ); $webhook->save(); // Deleting webhook: $webhook = wc_get_webhook( $webhook_id ); $webhook->delete( true );
Webhook delivery logs
Delivery logs have been moved from the WordPress comments table to our logging system, which allows more options for handling them instead of having to access the webhook logs in the admin interface.
Note: Because of this change all REST API endpoints for webhook delivery logs are now deprecated and will always return as empty. This is because logs now can be saved in the database, as files, or anything else.
Use your favorite message queue tool to process webhooks
It is now possible to write custom code to process webhooks. We used to only have options to deliver a webhook as soon as it is triggered or by WP CRON, but that may not be good for everyone. Until we have a third option with our “event queue” you may want to use Redis, Amazon SQS or something else.
It’s possible to override the delivery like so:
remove_action( 'woocommerce_webhook_process_delivery', 'wc_webhook_process_delivery', 10 ); /** * Custom process webhook delivery. * * @param WC_Webhook $webhook Webhook instance. * @param array $arg Delivery arguments. */ function my_custom_wc_webhook_process_delivery( $webhook, $arg ) { // Your custom code here. // Just do not forget to trigger webhook with later: // $webhook->deliver( $arg ) // Or get the webhook payload as JSON and send with your own delivery method: // wp_json_encode( $webhook->build_payload( $arg ) ) // Note that custom delivery methods will require extra code to log deliveries with $webhook->log_delivery( $delivery_id, $request, $response, $duration ) } add_action( 'woocommerce_webhook_process_delivery', 'my_custom_wc_webhook_process_delivery', 10, 2 );
And that’s all folks 👋.
-
WooCommerce 3.3 will include a new download logging/reporting feature to track who downloads what from your store (when selling digital products). The issue relating to this was initially logged here.
This feature was contributed by @procifer during his trial (Automattic is hiring!). The pull requests for this can be found here and here. They add the following:
- A new
WC_Customer_Download_Log
class supporting data stores to store logs to a custom table in the database. - Revised how download ids are generated to no longer rely on md5 hashes of filenames. This means each download has a unique ID which can be tracked.
- A new report which lists downloads made by customers, along with information such as IP address.
- Permission checks utilise the download log/tracking functions to make them more robust.
Visually, when viewing a download permission inside an order you’ll see a new link to the reports:
When this is clicked you’ll go off to the reporting section to see logs filtered to this permission ID:
You’ll notice we track the following per download:
- Timestamp of download event
- Product/file that was downloaded, from what ID
- Logged in user name
- IP Address
The Reports > Orders > Customer downloads section allows you to filter logs by any of these properties.
Thats it 🙂 Just a small enhancement we hope you’ll find useful.
- A new
-
Managing the product stock status cycle in a store is something that many store owners spend a lot of time doing. Products are always coming in, getting purchased, running out of stock, and needing to be reordered. WooCommerce 3.3 has improvements aimed at making stock management less time-consuming and more natural and intuitive for store owners.
Products with stock management
If a product has stock management enabled, the product’s stock status will now be automatically managed. It will naturally go from in stock to out of stock or on backorder as the product’s inventory runs out. When more inventory comes in, it will automatically go back in stock. You can just focus on how many of a product you have and WooCommerce will make sure the correct products are shown to customers in the store.
Products without stock management
If a product does not have stock management enabled, you will still manually control the stock status for the product but are now able to select “On Backorder” as a status.
Products screen
To go with these new changes we’ve made some changes to the Products screen. It is now easy to find and identify backordered products. We’ve also made it possible to filter products by stock status so you can quickly see which products need to be restocked and which products have plenty of stock left.
Testing and feedback
These changes are merged into our master branch on GitHub if you want to try things out. If all goes well, they will be part of 3.3 release in January.
Thoughts and feedback welcome in the comments.
-
WooCommerce 3.2.5 is now available. This fixes a few compatibility issues with WordPress 4.9, and a conflict with themes using product shortcodes.
~25 commits made it into this release. The full changelog is below.
* Fix - WordPress 4.9 - REST API - Updated schema, sanitization, and validation callbacks to support correct data types. * Fix - WordPress 4.9 - Fix an issue saving variation attributes on new products and with attributes containing slashes. * Fix - Save fee tax lines to new orders on checkout. * Fix - Restore the post global after rendering product shortcodes. * Fix - Fix product filtering when searching for a string including quote characters. * Fix - Fix layered nav drop-downs containing unicode characters. * Fix - Fix an edge case rounding bug with shipping taxes, and another with non-integer quantities. * Fix - Set correct defaults when adding a new shipping class in admin.
Download the latest release of WooCommerce here or venture over to Dashboard → Updates to update your plugins from WordPress.
As usual, if you spot any other issues in WooCommerce core please log them in detail on Github, and to disclose a security issue to our team, please submit a report via HackerOne here. Comments on this post are closed.
-
WooCommerce 3.2.4 is now available. This is a security release for all previous versions and we strongly encourage you to update your sites as soon as possible.
-
As part of the 3.3 release cycle we’ve been working on adding some features to the order screen, and improving general appearance.
First let’s take a look at the current order screen and point out some issues.
Order screen in 3.2 Problems:
- Status icons are only used on this screen, and have little meaning or context.
- Action icons are similarly confusing, largely due to the icons having no real meaning and being open to interpretation.
- Showing addresses here is of little benefit since you cannot fulfil orders without knowing whats inside.
- Other data that isn’t really needed here (because you cannot do anything with it!); payment method, shipping method, columns for notes with nothing but an icon.
Additionally, viewing order items was something removed in a past version due to performance reasons, but was missed by some users gaining > 150 votes on the ideas board. We wanted to introduce something more performant in 3.3.
The new screen takes design cues from Store on WordPress.com (which was redesigned from scratch) and aims to simplify these views, as well as do code cleanup behind the scenes. This is the re-factored screen:
Proposed order screen in 3.3 Key differences:
- Revised which columns are shown by default. Shipping address/billing address can still be toggled on, but are hidden by default.
- Combined order number/customer name into a single column with the most important data.
- Hidden the actions column unless an extension uses it to add custom buttons. All previous order update actions are possible from the bulk actions drop-down.
- There is a new preview link for viewing order contents.
- Clicking any part of the row takes you to the main edit order screen.
- Statuses are text-based, and hovering the status reveals any important notes. Using words makes it clearer, especially for new users.
The new preview button you may have noticed brings back a view of items in the order, but does so without slowing down the page load. Order details are loaded via AJAX and display in a modal like this:
The order preview Now you get all the add-a-glance information needed to deal with new orders without needing to edit the order.
Testing and feedback
These changes are merged into our master branch on GitHub if you want to try things out. If all goes well, they will be part of 3.3 release in January.
Thoughts and feedback welcome in the comments.
-
The WooCommerce 3.2.3 fix release is now available. You can download it from WordPress.org or as an automatic update in your administration panel.
~13 commits made it into this fix release. The main reason for doing it is to fix a conflict we’ve been seeing with shortcode based plugins and the shop page due to sanitization. The full changelog is below.
* Fix - Fixed a conflict with some slider plugins due to sanitization of archive/term descriptions.
* Fix - Fixed a flexslider bug when there is only 1 image on the product page (no gallery).
* Fix - Prevent potential notices when someone extends product tabs wrongly.
* Fix - Fixed display of shipping calculator under some conditions.
* Fix - Fix discount calculation when customer is not within the base location and prices include tax.If you spot any further issues, please report them to us in detail on GitHub so the development team can review – comments on this post are closed.
-
The WooCommerce 3.2.2 fix release is now available. You can download it from WordPress.org or as an automatic update in your administration panel.
~81 commits made it into this fix release.This release fixes up a bunch of minor issues, makes some small verbiage tweaks and code improvements, and adds a few hooks for devs. The full changelog is below.
* Fix - Properly escape commas when exporting products to CSV.
* Fix - Fixed email template padding in Outlook.
* Fix - Flexslider support for RTL languages and fixes for zoom target in Chrome.
* Fix - Correctly sync prices for grouped products.
* Fix - Filter and remove invalid tax classes names.
* Fix - Stop showing "major" update notification for minor or patch releases.
* Fix - Allow scroll bar in untested plugins list on the bulk plugin updates screen.
* Fix - Fixed meta data cloning when duplicating products.
* Fix - Clean "Filter Products by Attribute" widget cache when updating attributes.
* Fix - Fixed warning messages when reseting passwords with an invalid key.
* Fix - Cart totals: Don't add shipping costs unless show_shipping is true.
* Fix - Cart totals: Calculate shipping after discounts so discount amounts are available.
* Fix - Cart totals: Fixed issue where VAT exempt users where still being charged VAT on the totals.
* Fix - Cart totals: Fixed the coupons user limit and calculations.
* Fix - Fixed "relevance" default sorting in search results.
* Fix - Use item tax class rather than product tax class when recalculating order totals.
* Tweak - Allow shortcodes and relative URLs for downloads in product CSV importer.
* Tweak - Save unsaved items first while deleting order items.
* Tweak - Only changenocacheheaders
when on a cart/checkout page.
* Tweak - Setup locale before generating settings placeholders in email templates.
* Tweak - On checkout, improved the field locale logic to work without clearing default values.
* Tweak - Change title of customer invoice email for clarity.
* Tweak - Use custom event instead of blur to trigger validation.
* Tweak - Various selectWoo usibility improvements and better support for keyboard controls on AJAX multiselect elements.
* Tweak - Various setup Wizard improvements.
* Dev - Fixed orders date query when querying by meta data.
* Dev - In the CSV exporter, added a filter to process meta values before export.
If you spot any further issues, please report them to us in detail on GitHub so the development team can review – comments on this post are closed.