Our goal this time is to have the WooCommerce Deposits extension work with both WooCommerce versions 2.6.x and 2.7.x, display no notices, and use the CRUD abstraction to future-proof our code. Like in our original 2.7 extension compatibility post, I used the WordPress debug log and the Query Monitor plugin to any errors and deprecated notices.
WooCommerce brings many improvements to the WP-CLI powered command-line interface we introduced back in WooCommerce 2.5.
WP-CLI is a set of command-line tools for managing WordPress installations Our WC-CLI layer adds tools for managing products, coupons, payment gateways, shipping zones, and much more.
In WooCommerce 2.5 and 2.6, the CLI was powered by it’s own separate code. This code was separate from the REST API or WC core, meaning code could end being duplicated across the code base, or it meant that certain things possible in the REST API were not possible at all with the CLI.
2.7 introduces a new CLI powered by the REST API. We did this by forking Restful. This reduced the amount of code be need to maintain, provides a lot more power and commands, and means that the commands will always be current as we improve our REST API in the future.
Currently, following commands are available with list, get, update, and create operations:
wp wc customer wp wc customer_download wp wc order_note wp wc payment_gateway wp wc product wp wc product_attribute wp wc product_attribute_term wp wc product_cat wp wc product_review wp wc product_shipping_class wp wc product_tag wp wc product_variation wp wc shipping_method wp wc shipping_zone wp wc shipping_zone_location wp wc shipping_zone_method wp wc shop_coupon wp wc shop_order wp wc shop_order_refund wp wc tax wp wc tax_class wp wc tool wp wc webhook wp wc webhook_delivery
There is a wiki page containing more information and examples. We’ll also work on generating documentation similar to our REST API documentation for each command. You can also use the
—help flag to find out each commands parameters.
Please test out the new CLI commands and provide feedback or bug reports on GitHub!
WooCommerce 2.6 will ship with a payment tokenization API. This makes it easier to store, manipulate, and retrieve payment info in a standardized way. Payment methods saved using the API can be managed from the user’s account settings and are displayed as options during checkout. The Simplify gateway also now has support for tokens meaning users can save their payment information for future purchases.
Sound good? Check out the docs to learn more and get started.
What are Payment Tokens?
Payment tokens in WooCommerce allow you to save the tokens/keys you use for communicating with various payment processors. They also store the other meta information needed to process a payment. For example, credit card tokens store the four digits of a card, the card brand/type, and expiration information. eChecks store their last four digits. New types of tokens can be easily built and used with WooCommerce.
When can I use it?
The Payment Token API will ship with WooCommerce 2.6 which is due for release in Q2 2016.
Please feel free to experiment and test with this functionality from Github master branch and provide feedback on GitHub. The Payment Token API documentation should contain everything you need to know. You can also look at examples in the unit tests, or by looking at the Simplify Commerce gateway code.
Can you give me an example?
The Payment Token API docs cover examples and the available classes comprehensively, but here is an example of how easy it is to build and save a token to a user’s account:
// Build the token $token = new WC_Payment_Token_CC(); $token->set_token( $payment_token_from_gateway ); // Token comes from payment processor $token->set_gateway_id( 'paypal' ); $token->set_last4( '1517' ); $token->set_expiry_year( '2018' ); $token->set_expiry_month( '06' ); $token->set_card_type( 'visa' ); $token->set_user_id( get_current_user_id() ); // Save the new token to the database $token->save(); // Set this token as the users new default token WC_Payment_Tokens::set_users_default( get_current_user_id(), $token->get_id() );
A new version of the Google Analytics plugin for WooCommerce is now ready for testing. You can download beta 1 here: https://github.com/woothemes/woocommerce-google-analytics-integration/archive/1.4.0-beta-1.tar.gz
Enhanced eCommerce The new plugin now supports enhanced eCommerce tracking. Enabling enhanced analytics allows you to gather information every step of the way. You can now track: Purchase transactions, when an item is added to the cart, when an item is removed from the cart, product impressions from listing pages, product clicks from listing pages, when a product is viewed from its page, and when the checkout process is initiated.
Setup Tips The Google Analytics plugin can take a few steps to configure correctly since you need to configure things from the Google Analytics dashboard as well. The new release tries to make this as clear as possible by offering tips after installing the plugin, and clearer explanations around the different settings.
The plugin has also been refactored to make adding features like enhanced eCommerce possible (and to make it easier to potentially track more information in the future). Since the code has shifted a bit, we wanted to get some feedback on a beta version before releasing to everybody. If you find a bug, please post an issue on GitHub.
The Handsome Hippo is strutting along nicely and the release is beginning to take shape. As the name suggests the main focus for this release is UI and UX beautification which will result in some significant changes to the frontend design.
Depending on how your theme integrates with WooCommerce, this could have a big impact on your product so we strongly recommend that you begin testing/playing with the bleeding WooCommerce version ASAP.
In this post I’ll list many of the changes we’re making, but keep in mind that it’s not final. More things might change before release so please keep up to date. Check early and check often!
For themes that provide a deep integration with WooCommerce (IE remove our CSS in favour of enqueueing their own) things will be simpler. But you may still wish to add some styles for new / tweaked elements.
For themes that simply overwrite our bundled CSS (please stop doing this, guys) and/or template files, things could be more complicated. You will need to work through your theme accordingly paying close attention to all details.
- All design elements now feature a ‘flat’ design ensuring WooCommerce provides a modern aesthetic that blends nicely with many theme styles. Check:
- Demo store notice
- Sale flashes
- Price Slider widget
- Payment box at checkout
- Frontend style settings (allowing folks to change button colors etc) have been removed in favour of a separate plugin. If your theme interacted or relied on these settings keep an eye out for the upcoming plugin.
- The increment and decrement buttons attached to quantity inputs have been removed now that support of
input type="number"is more widespread. A separate plugin will be released for folks who want to add this back in.
- The ‘Proceed to checkout’ button on the cart has been moved and is now located beneath the cart totals. Obviously this is a crucial design element so if your theme overwrites any cart template files please double check this. We’ve tried to make this change as backwards compatible as possible, though.
- In the cart widget, it is now possible to remove products.
- WooCommerce now loads dashicons for the animated loading graphic used by blockUI. Feel free to utilise this without enqueueing it separately.
- Some tables have been made responsive such as the orders table on the my-account page. If you want to add style for this to your theme, activate Twenty Twelve and check the core CSS used to achieve responsive tables. The class
.shop_table_responsivehas been added for this purpose.
Hopefully this gives you guys a heads up on what’s happening on the frontend of WooCommerce 2.3. I highly recommend that any theme authors start looking at this as early as possible, even before we enter the beta stage.
As I said earlier, themes that simply overwrite our own CSS will be most affected by these changes. To re-iterate, this is a bad practise that we do not recommend. Why not make the switch and do things properly now? 🙂