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.
WordPress core offers plugin developers a certain endpoint which they can use for AJAX requests. This endpoint is wp-admin/admin-ajax.php. Despite it’s naming, it can be used for both frontend and admin ajax requests, and can even be used for non-logged in users.
We have found one drawback with the use of this endpoint however. It loads WordPress admin, and in certain cases this can be a huge performance issue because of that extra overhead.
To help improve performance of frontend AJAX requests (such as add to cart and checkout) we’ve implemented Custom AJAX Endpoints in WooCommerce 2.4.
These use a new endpoint: /wc-ajax/request-name
Because this endpoint is not within admin, it will not load the WP administration area, resulting in a faster request. As an example, in testing, adding items to the cart was around 40% faster using the new endpoints.
There are two possible gotchas which users need to be aware of with the new endpoints.
1. If using caching plugins, the wc-ajax endpoint, like the wc-api endpoint, needs to be excluded from cache.
2. If forcing SSL or non-SSL for certain URLs, /wc-ajax/ should be allowed to work with either. Because this is an AJAX request, secure pages will need to use a secure ajax endpoint, and non-secure pages will need to use a non-secure ajax endpoint to avoid “Access-Control-Allow-Origin” errors.
Check with your web host if you’re unsure of either of these points.
One final note, if you need to detect AJAX requests for any reason via code, our AJAX endpoint will ensure the standard DOING_AJAX constant is set, as well as a custom WC_DOING_AJAX constant.
WC 2.4 beta 4 was tagged yesterday evening and is ready to test. Beta 4 should be the final beta before a release candidate is tagged later this week. If you’re an extension of theme author make sure you test as soon as possible.
Beta testing is vital to ensuring our releases are as bug free as possible, and to ensure we hear user feedback before putting changes live. Anyone can beta test; shop owners, plugin developers, theme developers, translators.. any and all help is welcome.
We do understand however that the process of testing can be a little bit of a hassle since you need to download a tagged release and then upload it to your testing site manually. Sometimes this can also cause issues with plugin directory naming as well, because tagged releases won’t have a directory named ‘woocommerce’. This can break extensions.
To make this process easier, we’ve released a new beta testing plugin to help install the WooCommerce beta versions, and to ensure the directory names are kept correct.
Please ensure you test responsibly, its not a good idea to run beta versions on a production site unless you know what you’re doing!
Installing the Beta Tester Plugin
To get started, go to Plugins > Add New, and find and install the following plugin:
Sometimes we may also ask for feedback via other means, such as the survey for 2.4. We’d appreciate if you fill this in too as it will help us judge how well received our releases and betas are and help us shape future versions.
Beta 1 is out today, July 13th and the beta testing period will run for 2 weeks unless anything major comes up. Subsequent betas may be released if needed.
If all goes to plan, Release Candidate 1 will be tagged sometime between July 24th–27th, with the final release dropping a few days after.
The Product Variation Editor in the backend has been significantly changed to make full use of AJAX, as has the frontend. We have a dedicated post about this change here: Improving the Variations Interface in 2.4.
Custom AJAX Endpoints have been introduced to improve loading times on the frontend during events such as adding to cart. Previously, admin-ajax.php (the standard WordPress ajax endpoint) was used but this had the disadvantage of loading the entire WP admin just to make a request. The custom endpoints work around this.
A Visual API Authentication Endpoint has been added. Services which integrate with the REST API can now use the visual authentication endpoint so a user can login and grant API permission from a single page before being redirected back.
Shipping Method Priorities have been added to give more control over which shipping method is selected by default for customers. Each method can now be given a numeric priority.
Flat Rate Shipping and International Shipping were both refactored to remove unnecessary, confusing options. An upgrade routine will change old settings to new post-upgrade. See more here: Simplifying Flat Rate Shipping in WC 2.4
And finally, we added an onboarding wizard for new users.
Onboarding New Users
Lets face it. eCommerce is hard. If you’re starting up a business for the first time, there are things you need to at least understand before you can start selling. Taxes and shipping to name but a few. But we don’t need to overload the user with this.
In WooCommerce 2.3, upon installing the user is greeted with a ‘welcome’ and then boom. Here are the settings. Have fun. The user has no idea what to do next, and all they see are several notices and a whole bunch of tabs which they may or may not fully understand. This is not good onboarding.
We set out on the journey to improve this back in November during the WooTrip/WooCommerce Conference where we hosted a “Hackithon”. Several teams put together MVPs and pitched ideas, with the winner to be given time and resources for implementation. We didn’t win, but that didn’t stop us :)
The idea for the onboarding wizard was logged on Github. The goal; by the end of the onboarding wizard the user should have a working ‘store’ ready to populate with products. The decision was made to make it one of the key focussing in 2.4 (hence the name, Helpful Hedgehog).
For a new user installing WooCommerce for the first time, rather than see our ‘welcome’ page, they will instead be redirected to the setup wizard. It’s a quick 5 minute process to get the main store settings setup complete with geolocation to offer locale specific options by default.
Here is a quick run though the wizard for a UK based user.
There is an introduction which explains what is going to happen
It is optional
It sets up all requires WooCommerce pages for the user
It geolocates the user to offer them suitable currency + symbol + weight unit options
It lets them quickly setup flat rate shipping
It can install some basic tax rates if available
The final step tells the user what they can do next
We hope this will help immensely, but it doesn’t stop there. Additionally:
If a user clicks the ‘create your first product’ button, the create product screen will show a series of admin points to guide them through the process
All admin screens now have contextual tutorial videos in the help tab
We’d appreciate any help in testing 2.4 to ensure a pain free final release. If you are testing extensions, or you’re an extension developer, please take note of the following.
The main point of conflict will be around the variations improvements. If you have a plugin which adds fields to variations, or alters the display of variations in anyway you need to check your code. That includes the frontend testing with variable products with 20 or more variations which will use the new ajax loader.
Template Changes for Themes
The following changes have been made which affect themes. Please note; template versions have been bumped for any changed files.
To improve display in various email clients (such as outlook) many email template files have been tweaked. For the most part this just meant the addition of some classes.
The product category template file calls the new wc_product_cat_class() function to apply css classes, rather than including that logic in the template.
To make editing the proceed to checkout button that little bit easier we created a template for it.
In WooCommerce 2.4 we wanted to give users a better experience whilst working with variable products. Variable products have been a headache for some users whom needed to deal with many variations at the same time, mainly due to problems saving, or admin screens and product pages taking too long to long to load.
We’ve made changes to improve this experience, changing the way that variations are saved and displayed within the edit product screens.
Variations will be created, listed, saved and deleted using AJAX. This reduces the volume of data posted when saving and loaded when loading the page, which were the two main problems for performance in 2.3.
The interface was also tweaked to support this, with pagination being introduced to make large numbers more manageable.
The pagination restricts editing and saving to 10 variations at a time. But you can change the amount using the woocommerce_admin_meta_boxes_variations_per_page filter if needed:
Too many buttons spoil the broth, so we moved “Add variation” and “Link all variations” buttons to the bulk actions drop down:
Only the variations that had some changes will be saved when you hit “Save Changes” which prevents sending tonnes of data to the database. And of course, the Bulk Edit options will still apply to all variations, even on other pages.
In the frontend, if a variable product has more than 20 variations, the data will be loaded by ajax rather than handled inline. It is possible to change this quantity using the woocommerce_ajax_variation_threshold:
In the following video you can see the creation of a variable product and how the variations tab works.
If you use actions such as woocommerce_save_product_variation, woocommerce_variation_options and woocommerce_product_after_variable_attributes you have nothing to fear. Your options will be displayed and saved as before. We’ve spent a great deal of time ensuring the save system works in a backwards compatible way.
In addition the bulk actions are saved by ajax, so if you have any plugin that adds new options you’ll have to change the way it’s saved using thewoocommerce_bulk_edit_variations_default hook.
On the frontend, if you modify the add to cart form/variations you will also need to revise your code since matching variations will be pulled in via ajax. There are still hooks present, so this mainly affects plugins which adjust the entire ‘array’ of available variations, since this no longer exists. If you need more time to resolve this, or cannot make a plugin compatible, you can disable the threshold with the woocommerce_ajax_variation_threshold filter.
We’ll be in beta in the next few weeks, so please let me know if you need new hooks or events to your plugins.