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.

2016-01-06 at 14.36.png
Zones in action

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:

  1. 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.
  2. Replace the order lists and order edit pages with custom ones, again future proofing for a switch over.
  3.  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?