WooCommerce 2016 core wishlist

With 2015 and 2.5 (almost) out of the way, we’ve started looking forward to 2016 and the next major release. WC 2.6 has already been partially roadmapped on Github and on our roadmap Trello board, but what we do after that is not yet certain

I asked some of our WooCommerce devs what they wanted to see realised in core through 2016 and these were the results.

I want to see the groundwork laid for the standardisation of all of the class/ID names in our CSS / JS.

– James Koster

I’d like to see us continue to refactor the core commerce screens (settings, order management, etc) with a focus on simple interfaces.

– Matty Cohen

I also want core to have end-to-end tests so if crucial things change we can have confidence if the tests passed.

– Akeda Bagus

For me the My Account page is almost the last thing that bothers me xD

My Account pages today are really confusing. We have just one page to show information and it is a huge table with all user orders (users can display 100 orders there xD) and more tables for other plugins like subscriptions and bookings, and finally address data.

It’s not just a problem because of lack of organisation, but it also does not facilitate integrations and is a heavy page.

– Claudio Sanches

Automated testing? I’m working on plugins right now, and that’s definitely something I’d like to see. Even if it’s just some rudimentary sanity checks that we can run before releasing code changes […] as a former SDET and (still an) automation nut, that’s definitely on the top of my list.

– Nabeel Sulieman

I am looking forward to seeing a better, more in-depth sales reporting.

– Roy Ho

A new base class for payment gateways that incorporates some frequently needed items like logging, “standard” options form fields (title, testmode, description), auth/capture concepts, etc. The existing base class can stand for backwards compatibility the new one would derive from it

– Allen Snook

For me, there are two pressing issues I’m really excited to work on this year if possible.

Next level shipping with zones

I’ve already begun development for this 2.6 feature – bringing shipping zones into core.

When you look at shipping now, you’re restricted by the fact that a shipping method can be used once. Take Flat Rate for example – it lets you add a flat rate for some customers, but only one rate. International Shipping is also available, but thats just a duplicate of the flat rate method and again, you’re limited because you can only have one of each.

Any availability restrictions also have to be handled per shipping method, for that shipping method only.

Shipping Zones flips this on it’s head. It lets you define where you want to ship (the zone) and then add multiple shipping method instances to each zone. Flat Rate shipping in this setup is way more powerful.

I feel this one will make core shipping much more viable for more stores, and less confusing when a store has a complex setup.

A new home for orders

As WooCommerce popularity increases we’re seeing larger, more popular stores choosing the platform. With these larger stores, performance and scalability becomes much more of an issue.

People need to know that the technology they use to start their own store will grow with them. That means we need to make some infrastructure changes in the backend to make WooCommerce as scalable as possible.

– Patrick Rauland

One such bottleneck is with our current order system (which uses custom post types).

Custom post types have served us well; there is no denying that the convenience and ease of their use has been great for development and ensuring WooCommerce is extensible.

But it’s not efficient. Take a sales report for a product as an example. To query this data you need to join posts on post meta on terms tables. These joins make querying report data terribly slow and inefficient – something a custom table would have no problems with because we’d have full control over the schema.

I see 2016 as the year we begin tackling this, but its not small task due to the backwards compatibility considerations we need to make. This was also one of Akeda’s wishes.

Abstraction on order storage, so users can opt-in to the storage adapter. By default it would be CPT, but can be stored on other tables or even other databases.

I envision this being a multi-step process spanning several releases to:

Replace get_post, get_posts, and post meta functions with custom functions designed solely for WC Orders so when the switch is made, code remains compatible.
Replace the order lists and order edit pages with custom ones, again future proofing for a switch over.
Creating a migration script from post types -> custom table and making the switch.

No small feat, but a neccessary one for sure.

If you had to choose one thing, what would you most like to see in WooCommerce core in 2016?

Keep yourself in the loop!

46 responses to “WooCommerce 2016 core wishlist”

John Carter

January 7, 2016

Great ideas, really looking forward to the future of WooCommerce, you are doing a great job!

Now the variations add to cart button is shown but disabled :), I would like to see a select box for quantity input throughout. Also I would love a manage addresses section for regularly used delivery and billing addresses.

Reply
1. jaykoster
  
  January 7, 2016
  
  > I would like to see a select box for quantity input throughout
  
  Why? That sounds fairly counter-intuitive.
  
  Reply
  1. John Carter
    
    January 7, 2016
    
    Well, in my opinion I would say select drop downs are:
    – quicker (less keyboard use)
    – less fiddly than html5 number input
    – work better on touch screens
    – can negate the need for a separate stock quantity display if the quantity options are filtered by stock level
    
    Reply
  2. Mike Jolley
    
    January 7, 2016
    
    Not a bad idea, however, it would limit the qty you can input/add to cart.
    
    Reply
jkenzer

January 7, 2016

It would be a huge help to have partial order shipments. When an order comes in with multiple items, sometimes they ship from different warehouses or ship at different times. On the back end, to be able to say these items shipped on this date and these items shipped on this other date would be extremely helpful.

Reply
1. Mike Jolley
  
  January 7, 2016
  
  This could be done with order notes, as those are private? Or is this for customers?
  
  Reply
  1. jkenzer
    
    January 7, 2016
    
    It would need to be fully integrated. So customers would get notification of multiple shipments. Orders could be filtered by those partially shipped. Items in orders would show which have shipped and which have not and in which shipments those items are in.
    
    Reply
    1. Mike Jolley
      
      January 7, 2016
      
      I think this will require 2 types of order status to implement. Shipped status and paid status. I want to look into this when we separate orders into a new table, since it will cause bw compat issues.
      
      Reply
motanelg

January 7, 2016

I wish to see a way to customize checkout forms (billing and shipping) without using a special plugin for that. To have the ability to hide, add, delete or sort some fields and make them required like in WooCommerce Poor Guys Swiss Knife plugin.

I wish to see all the romanian states added to core ( there are not many).

I wish to have the posibility to show the prices in multi currency not just one, without using special plugin. It is easy for the customer to see the price in USD if he is from America and/or Euro from other country.

If more people with much bigger stores are using Woocommerce you must thing of a advanced way of filtering products, stocks and prices ( and maybe products on sale ). It is important for the customers to find what they looking for very easy and simple. You can find inspiration in plugins like Advanced AJAX Product Filters or other like this

I like Woocommerce and I would like you to start seeing it from 2016 like a solution for big stores instead just for a small business. It has the potential, but it depends on the developer team where is heading and how big are the steps.

Reply
1. Mike Jolley
  
  January 7, 2016
  
  What would be the benefit of adding field editing to core? I’d argue this is not something all store owners will want or need, which is why it fits a feature plugin.
  
  There is an issue logged for new filters 😉
  
  Reply
  1. motanelg
    
    January 7, 2016
    
    Thank you for your reply Mike Jolley.
    
    In my case adding two new fields is a must. In my country, in order to realease an invoice for a company I need to have the VAT number of that company and a registration number from Trade Register. The zip code is not used to often in my country and for that I need to make him not required for not losing customers.
    
    The WooCommerce Poor Guys Swiss Knife helps me add these fields to Additional Informations and show the information that I need in the emails for now.
    
    Think about one day all that plugins are no longer free. Would you pay 49 USD for Checkout Field Editor or other plugin for one domain, only to add two fields and make one not requiered?
    
    There are countries where the laws are different. The benefit is for them.
    
    Reply
    1. Ninos
      
      January 8, 2016
      
      I don’t know why people always use plugins for such simple things. Just use the woocommerce-filters to create/delete checkout fields 🙂
      
      Advantages:
      1. Better performance (you don’t need to load a full plugin with x features you may don’t need + no gui for configuration needed anymore for such thing you only setup once time)
      2. Better security (less code to load, also may less tracking)
      3. Lighter Dashboard (no additional menu points, customization is done once time)
      4. Code is already free. You’re independent of the pricing policy of the plugin owners
      
      See also following documentation:
      https://docs.woothemes.com/document/tutorial-customising-checkout-fields-using-actions-and-filters/
      
      Reply
2. Diego
  
  January 7, 2016
  
  As the author of a multi-currency solution for WooCommerce, I would like to point out that adding such feature is not easy. I’ve been working on the topic for over two years, and I would love to help the WC team making that a part of the core, but it’s a significant paradigm shift.
  
  To make a comparison, it’s far more complex than transforming the orders data, like they are already planning to do, and that is already a huge task (I can already imagine the hundreds of compatibility issues that it could generate).
  
  Reply
leokoo

January 7, 2016

Scalability is always an issue that needs to be tackled in order to move WooCommerce into the enterprise market 🙂 Thanks for the great news!

Reply
pieterclaesen

January 7, 2016

Maybe I haven’t found the correct setting, but I’d love to see this feature:

For coupons, you can select ‘cannot be used with other coupons’. But the problem with this is the following:
If I create a discount coupon for 20% on selected products, it should not be used with another coupon (10% store wide for example). However, if the client purchased a giftcard, he or she should be able to use that giftcard AND the discount coupon.

So basically: split up giftcards and coupons :-).

Reply
1. Mike Jolley
  
  January 8, 2016
  
  Sounds like gift card extension could handle this? 😉 Core doesn’t have gift cards.
  
  Reply
Benjamin Bossu

January 7, 2016

And please always think about developpers and custom hooks and functions. think child theme and child functions.
thanks for woocommerce .
best 2016

Reply
Jens

January 7, 2016

Last thing really missing is wildcards in coupons’ email restrictions: https://github.com/woothemes/woocommerce/issues/9596 :-p

Seriously, end-to-end tests would be *really* great. Mayor problem for me is stability which – to be honest – mainly stems from plugins. Even after minor updates I have to manual do full checkout and order tests to see if all the add-to-car, shipping and payment is still working. Testing is done on a staging system of course, but with the agressive release cycle of WC and also of plugins itself (which is good) more stability would be great.

I have about 10 plugin (woocommerce-germanized, mailchimp, pdf-invoices, groups,…) and the virtue theme.

I imagine that end-to-end tests could be run not only on vanilla woocommerce but also with different plugin configurations. Does not mean that Woo needs to do this. But the plugin authors get then the chance to easily set up Travis and install WC together with their plugin and run the WC end-to-end tests. Each plugin author could then easily increase its own confidence.

Reply
1. Diego
  
  January 7, 2016
  
  As a plugin developer, I have to say that the stability problems actually stem from the many changes that are being applied to WooCommerce core at every release. Many of them are breaking changes and, in an environment (WordPress) where full backward compatibility is of paramount importance, to the point that it’s taken for granted, that is a critical issue.
  
  Besides, a plugin developer doesn’t have the luxury to say “latest version of WC only”, he has to make the plugin work with earlier versions too. When the changes are significant, the amount of work grows exponentially. Add other plugins to the mix (I wrote several cross-plugin solutions myself, and all elements must work in multiple combinations of versions), and you have a clear picture of why stability is so hard to achieve.
  
  Reply
  1. Mike Jolley
    
    January 7, 2016
    
    Example of a breaking change (one without deprecation) in 2.5/2.4?
    
    Reply
    1. diego.zanella
      
      January 8, 2016
      
      I don’t remember the whole list but in 2.4, the new logic to handle variations and to cache their prices was a significant change, which became stable in 2.4.8. Coupons also changed in a subtle way, now expecting the coupon value in an object property that, until WC 2.3, was marked as “maintained as legacy” (the main property was another one). From a UI perspective, the changes in the layout of the product attributes on the Product Edit page (from table rows to DIVs) caused some rendering glitches.
      
      There were more changes that caused some trouble (e.g. changes in how Ajax actions are passed in 2.4), I can’t remember all of them. The variations were the trickiest to address.
      
      With 2.5 almost everything works the same way. The only issue found so far has been the changes in the Tax Rates page UI code (Javascript), which became far more complicated and difficult to tweak.
      
      As for deprecations, there are several schools of thought about them. Mine is that soft deprecations should be documented (your development blog would be perfect), but the code should be “silent” and work as it always did, instead of raising a warning that alarms users. Hard deprecations (i.e. removal of code) should be kept to a minimum, and announced with a specific deadline (e.g. “function XYZ will be removed in version 1.2.3”), instead of a generic “soon”.
      
      All the above can be useful to improve the release process. It’s hard to innovate without leaving too much of” the past” behind, but carrying some legacy is inevitable (I know something about that).
      
      Reply
Ninos

January 8, 2016

ATM I’m very happy with WooCommerce, there are just small things I would love to see:
For big businesses:
1. Performance impact for products filters (See also: https://github.com/woothemes/woocommerce/issues/9041) Filtering should not be done on php-side. With a lot of products filtering is more slow than via sql-queries (also on php7). May this can be improved also somewhere else.
2. There are some plugins which extends your store to be ready e.g. for german law. I would love to see a better work between your companies so may custom template files are not required anymore.

For developers:
1. Exclude more html-output into template files. Best example: woocommerce_form_field(). You need to replace that function to change the html-output of your fields. Easiest solution here would be to create an own template file for every field type: /global/fields/text|email|textarea|(…).php
2. Would love to see default class support for bootstrap3. Lots of themes are already using bootstrap3. By adding general support for that framework, integration into themes and maintaining would be more easy. As small side effect such themes would load less css-files because not needed anymore.

Reply
1. Ninos
  
  January 8, 2016
  
  Forgot to say:
  For big bussinesses:
  3. Step-by-Step checkout feature as alternative to the one-Page chechout would be also great. Atm only possible via javascript (e.g. tabs).
  
  Reply
  1. John Carter
    
    January 8, 2016
    
    Please don’t make a step by step checkout, a one page is so much simpler. 👍
    
    Reply
    1. Ninos
      
      January 9, 2016
      
      “as alternative” to the one-page. Just to have the choise
      
      Reply
      1. Mike Jolley
        
        January 9, 2016
        
        To be honest, I’d rather focus on making one page checkout awesome than maintaining a separate flow in core.
2. Diego
  
  January 8, 2016
  
  Actually, I find the PHP filtering more flexible (and I’m a strong supporter of SQL based solutions, as a DBA). The limitation of filtering via SQL is that some of the data may not be in the database (e.g. dynamically determined prices), therefore SQL would not be able to read it. In such case, PHP code is the only solution.
  
  Reply
  1. Ninos
    
    January 12, 2016
    
    Thanks for feedback. So may I’ll create a plugin for that (for interested customers). ATM a js-solution is implemented in one of our themes (as alternative).
    
    Reply
emanweb

January 8, 2016

[quote]If you had to choose one thing, what would you most like to see in WooCommerce core in 2016?[/quote]

Multisite integration. Shared backend for multiple front end stores. This was on the road-map. Did get pushed back?

Reply
1. Mike Jolley
  
  January 8, 2016
  
  Not pushed back, just deemed more as ‘extension territory’. Especially since there were multiple POVs of what multisite integration should do.
  
  Reply
Manos

January 8, 2016

Great ideas, really interested to see the new shipping workflow in action.

Probably on the way already – I’d love to see more flexibility when manually adding products to orders. Make it possible to configure/modify order content (line items + meta) via hooks when manually adding products to an order. Allow extensions to display custom fields and validate them before actually adding line items. Then, refresh the entire order contents to correctly display any additional line items / fees / item meta added in the background.

Examples:

– Select Add-ons when manually adding a product to an order.
– Configure and validate Variable product attributes when adding the parent product to an order.
– Configure and add Bundles/Composites when manually adding them to an order.
– Configure Booking settings when adding a booking product to an order.

Basic working example at https://github.com/woothemes/woocommerce/pull/9846 – ideas / feedback welcome as always. Background discussion: https://trello.com/c/UlW3M1Ha/69-configurable-product-fileds-in-orders-backend

Reply
Muhammad Arslan

January 8, 2016

Great ideas, glad to see that WC is moving towards a very bright direction.

Reply
Gerd

January 8, 2016

Better multilingual support: That is the only thing I am missing from my german webshop: an english version.

I know of https://wordpress.org/plugins/woo-poly-integration/ or https://wordpress.org/plugins/woocommerce-multilingual/ but adding these is like doubling the technical complexity of the whole system (as stability totally decreases with this configuration and it is much more testing).

If you are in Europe or Asia: Sooner or later you want to have an English fallback. In some countries (almost every one in Asia/Africa) you have several languages by default, at least in Belgium or Ukraine you have two languages anyway…

But this seems to be one of WP weak points: https://make.wordpress.org/core/2015/06/29/wordcamp-europe-2015-multilingual-discussion/

Easy, usable multilanguage support would WooCommerce set apart from shopify, jimdo, magento.

Reply
Solona

January 8, 2016

I second Claudio Sanchez’s comment about My Account. I heavily altered the template files and CSS to make it more user-friendly. I would love to see tabs like Account Info | Subscriptions | Downloads

Excited to see the new release in action.

Reply
Jan PIngel

January 14, 2016

In addition to standardizing the class/ID names I would suggest decoupling the HTML structure from the jQuery/JS as much as possible and making the blocker/select plugins optional. It would also be amazing if we could hook into the existing validation to play nice with different frameworks. Right now replacing all the markup in the templates to be friendly for Foundation or Semantic UI is a huge chore and requires maintaining our own versions of wc-checkout.js, wc-address-i18n.js and wc-country-select.js to work around the issue.

Reply
Renato Frota

January 14, 2016

I would love to see a responsive cart.. This is an important thing to make WooCommerce more “turn key” solution, that works with every theme.
I have to add these custom CSS, whenever a store is setup: http://www.jeremycarter.com.au/optimising-woocommerce-checkout-for-mobile/

Kudos to Claudio “Woo” Sanches for all the work toward making WooCommerce THE e-commerce solution in Brazil, with tons of (mainly free) plugins!

Reply
Simon Watson

January 27, 2016

I would love to see improvements in performance especially when a site is under load with multiple people trying to checkout. Throw in a couple of plugins (like Follow Up emails) adding in data and the checkout process can take 30+ seconds (and we are spending $400+ pm on hosting with a decent company).

Also reporting is poor. And slow. Even a basic CSV export for one month has to be done (almost) on a day by day basis and then stitched together for our accounts team.

Reply
Rees

January 27, 2016

Definitely performance issues guys. Searching orders on large sites (which I look after) is painfully slow and embarrassing to be fair. Clients don’t need and explanation of why order search takes so long – they just want to search for an order or customer quickly. It can’t too soon and I’ll personally lick your collective toes when it comes 😉

And…

Keep up the good work and definitely launch a premium version of WooCommerce. Even charge for a basic version so you can hire more support staff and invest in development. I just spent over $500.00 on a basic suite of Woo plugins because I want compatibility and support. Other sites I work on have post $1000.00 of plugins. Competitive renewal plans are key. Not 50% but 60% or 70% discounts so we all remain loyal.

Finally, on support, I was waiting for over four days from Woo on a currently live ticket. When you purchase premium software a four day wait is not acceptable. We know there are support issues but this went a little too far.

Reply
Jeff Kyle

January 27, 2016

I would like to see the ability to process payments added to the backend for phone orders. As it stands now, we can create an order in the WC admin but we must use a separate interface to actually process payments. This would be a HUGE time saver.

Also, the ability to calculate shipping charges when adding a new order would be another time saving benefit. We can currently add shipping charges but we can’t actually calculate them on the Orders screen.

Reply
Tiago Dias

January 27, 2016

to be honest, my biggest issue I’ve experienced with multiple clients is the UI at the moment the one thing that people look at baffled and (of course its e-commerce) but that would be one of those things I would consider doing, but of course after all the work has been done on making it running a bit faster on large stores.

Reply
Jeff Kyle

February 2, 2016

Well, go figure. As of version 2.5.0 released on January 18th, they DID add a feature to take payments in the backend when adding an order. I didn’t notice it until today when I was adding a manual order. After you save the order for the first time, a small Pay link appears near the order status selector. Once you’ve totaled the order, click the Pay link and you’ll be taken to the front end temporarily to complete payment. Thanks for adding this!

Please also add the ability to auto calculate shipping charges in the backend on manual orders and this will make our manual order process so much faster. Thanks again!

Reply
1. Jeff Kyle
  
  February 2, 2016
  
  I have just discovered a BIG issue with the new Pay option in the backend order section. I am currently using the WooCommerce Stripe gateway plugin from WooThemes. We have the Saved Cards option enabled to allow Stripe to store the customer cards for reuse on future orders. With this option activated, entering payment via a credit card using the new backend Pay option saves the customer’s card to the account of the ADMIN WHO IS LOGGED IN placing the manual order. This is obviously a huge security issue because admins should not store customer cards in their own accounts.
  
  I did a test order as a guest. The card I used was saved and shows under My Account section when I’m logged in as the Admin. While I can delete any cards listed under my admin account, the cards should not be saved to admin accounts by default when using this backend Pay option.
  
  Placing an order for a customer who is already a registered user also does the same thing. When I reach the screen to pay for the order, the cards saved in my own admin account are displayed and not cards from the registered customer.
  
  I will report this to WooThemes through the appropriate method but I wanted to make anyone who is reading about the new Pay option here aware of the issue.
  
  Please address this problem as soon as possible. Thank you.
  
  Reply
  1. Jeff Kyle
    
    February 2, 2016
    
    In addition, I refunded the amount for the test card back to the credit card I used as a guest. I used a different email address on the test order than the one registered with my Admin My Account. The Stripe payment receipt and Stripe refund notification emails I received from Stripe were sent to my email address for my Admin WP account and not to the email address used on the test order. That being the case, it appears that customers won’t receive the Stripe receipts after an order is placed.
    
    WooCommerce order notifications were delivered to the address used on the test order so that was OK. When a new card is used and saved to Stripe, Stripe apparently associates the card data with the logged in user’s email address and not the email address entered on the order in the backend.
    
    Reply
2. Mike Jolley
  
  February 2, 2016
  
  Jeff, I think you’re missing the point of that pay link. It’s a shortcut to copy/paste to give users a link to pay directly. Was a user request. You cannot pay ‘as a customer’.
  
  Reply
Jeff Kyle

February 2, 2016

I see. I’m aware that others have been also asking for the ability to process payments in the backend for years. I didn’t see any documentation for this new feature anywhere.except in the changelog which says “Feature – Added ‘pay’ link to order screen.” That’s why I assumed this was the initial implementation of being able to process payments in the backend. My apologies for misunderstanding the new feature.

My organization really needs this ability to help speed up workflow. We hope this can be added in the future. If you have any suggestions on how to accomplish this with an existing plugin that we may not be aware of, we’d be grateful. Thanks Mike.

Reply
Say hello to WooCommerce 2.6 “Zipping Zebra” – Develop WC

June 14, 2016

[…] This time round there has been a major focus on APIs, shipping, and account pages which ticks some items off of our 2016 core wishlist. […]

Reply