The most significant update to Easy Digital Downloads is nearing its initial beta phase. The team has been focused on finalizing the last issues related to data integrity, backwards compatibility, and migration accuracy. We’ve made some updates recently that apply significant improvements to performance and compatibility with our extensions and the migration alike.
In a previous update we showed some improvements to our Tax UI. Since then we’ve made a few more significant changes and fixes that should be noted.
Deprecated the “Default Tax Rate”
As we moved forward with the improvements to the tax features of Easy Digital Downloads, we realized that the ‘Default Tax Rate’ was a setting that ultimately caused problems with our new method of reporting on taxes. It also proved to be a concern as taxes should be applied to a region, but a default tax rate has no region. As such, if Easy Digital Downloads detects a ‘Default Tax Rate’, we are letting stores know this is no longer supported and a region specific tax rate should be identified.
Tax rate improvements
We’ve worked towards making managing tax rates easier in 3.0. On top of the new UI for managing taxes we’ve fixed a few cases where users could add multiple active tax rates for an entire country both in the UI as well as during the migration process.
We’re also planning to include auto-saving tax rates, negating the need to ‘save changes’ after each tax rate modification. This will be done in our Post-Alpha phase.
We’ve also identified and fixed a bug in the migration where a tax rate was being incorrectly rounded up or down to meet the currency decimal point defined by the store’s default currency.
One of the most improved features of Easy Digital Downloads 3.0 is the reporting system. Thanks to a large amount of database changes and custom tables, the team has been able to improve reporting. The most recent focus was finalizing the UI around reports to make things consistent and accurate no matter what report you are viewing.
Gross/Net status functions
To assist in the accurate reporting in all aspects of Easy Digital Downloads, we’ve introduced two functions which return statuses of orders that would be considered to affect gross and net statistics.
These two functions also include filters to allow extension developers to include their own statuses in these calculations, if they are needed. The goal with these two functions is to use a Don’t Repeat Yourself (DRY) method of when to include an order when calculating statistics.
Date ranges in reports
As any developer knows, dates can be difficult. We’ve put some significant effort over the last couple months making sure that when viewing reports, that it is clear that the date ranges are clear and match the expected outcomes. This has caused us to make some significant updates to the filter handlers for reporting.
We’ve also worked on fixing some inconsistencies in the reports that caused the edges of date ranges to not be included in the requested reports. This was a bug that presented itself in current versions of EDD, and thanks to the new reporting APIs, was an easy fix with the new 3.0 data structure.
Improved customer statistics
In previous versions of EDD, our customer reporting statistics for lifetime value and lifetime purchase counts were all ledger based. As new orders were placed or refunded we would simply take the existing value, and add or subtract the modified amount. This could lead to inaccurate reporting and forced us to introduce a tool to ‘recalculate stats’ that needed to be used more frequently than we liked to see.
In 3.0, again thanks to the new database structure, it is an insignificant process for us to quickly, and accurately calculate a customer’s statistics without needing a ledger. When an order is modified for a customer, we quickly recalculate the entire lifetime value and purchase count of the customer, avoiding inaccuracies due to ledger inconsistencies.
The above change, however, does remove the ability to directly affect a customer’s lifetime value or purchase count. As of 3.0, the methods to increase a customer’s value or purchase count by an arbitrary amount are deprecated.
One of the most significant changes to the customer feature of Easy Digital Downloads comes in how both physical addresses and email addresses are managed. Both email addresses and physical addresses have custom tables instead of storing this data in meta, which significantly improves the performance of looking up customers.
Physical address improvements
In recent changes, we’ve introduced the concept of physical address ‘types’ as well as a way to identify what the ‘primary’ physical address is. While Easy Digital Downloads core only supports the billing address out of the box, extensions like Simple Shipping can add in shipping addresses, which will allow each customer to have multiple types of primary addresses, for use in future updates to both EDD and extensions.
Avoid duplicate address data
Our previous methods of storing physical address data resulted in a large number of duplicated addresses for customers. We’ve made some drastic improvements to the address validation before inserting new addresses into the customer record so that we don’t fill your database with duplicate data, including during the migration process.
UI and accessibility updates
After all of the work that was done in an effort to improve the performance and data structures, we needed to make some significant updates to the UI to reflect these changes. With that, we took the opportunity to improve not just the overall UI, but the mobile-friendly access, as well as accessibility. While we aren’t done yet we’ll be making further improvements as we near the 3.0 release, and shortly after it. Some of the areas where we’ve put in the most effort to improve the UI are:
- Order details
- Order list tables
- Tax rates
- Download Post Type Metaboxes
While we aren’t fully done with improving the accessibility of the UI and making things more semantic when it comes to our form inputs, you can follow along here. Note this is a living document and is subject to change.
What is next…
We’ve split the last part of this development into two projects:
At Sandhills development, we like to use our software internally prior to any beta release. This is so we can identify any issues we find internally before releasing them to our customers, even in a beta phase.
Our project for Pre-Alpha are changes that we have to complete prior to when we start internally testing on our sites, and getting all of our extensions updated to support Easy Digital Downloads 3.0. Upon completion of the Pre-Alpha project we’ll shift our focus to extension releases that make them compatible with 3.0 ahead of release, so you shouldn’t have to worry about your extensions working with 3.0 after release.
Once we’re running an alpha on our own data sets, we’ll be shifting our focus to Post-Alpha project issues, after which, we will be publishing our first beta for public testing.
Really appreciate the update. Keep up the great work, team 🙌🏼. I’m excited for what’s to come.
I don’t need these tax or reporting improvements, but sure there are many users out there that will.
But please get this 3.0 version out. Two and a half years is a long time.
Would be great, if you have time again, to improve your extenstions too.
I realize that these tax improvements may not be useful for everyone, but the way that taxes work is directly tied to the new adjustments API built into the brand new orders system, so things like this are critical to making sure compatibility is maintained.
The length that EDD 3.0 has taken is far longer than we had hoped, but as we near the end of the development, we are finalizing very important aspects of the data schemas, which will prevent any major issues with the data going forward after 3.0.
Extensions are our next priority after the alpha is ready, so that we can maintain compatibility for our users.
Mentioning customer addresses reminded me that it is currently a huge problem that the address for subscription payments is taken from the initial payment, not the last payment or the information the user left in their account. Legally, we should only update addresses at the time they change, not further into the past.
Another issue is that we actually need an “invoice” for (partial) refunds instead of changing the initial payment. WooCommerce handles that correctly. Is this part of EDD 3.0?
In 3.0, all refunds (partial and full) create new order records, so yes, that problem is fixed in 3.0 🙂
What about the address issue that Thomas mentioned?
That would not be a future or fix in Easy Digital Downloads 3.0, and will require some changes to our Recurring Payments extension to execute properly. We’ve logged an issue to look into the possibility of this, but we will need to look into what type of impacts it may have amongst other areas of EDD and Recurring.
Thanks for your interest.
Will the tax improvements in 3.0 be VAT Moss compliant?
Hi Pippin and Chris,
is there any progress in EDD 3.0.
Everytime I look into github pulse, there are more new issues than solved issues…?
There is quite a bit of progress on 3.0. What you are seeing are minor issues that we find popping up as we finalize the development of it prior to an internal Alpha. We choose to log every thing that needs to be fixed, big or small, so that we don’t lose track of it or miss something. Early in a larger project it is common to have a small number of issues that take a lot of work, but as we near the final stages, you’ll likely see a number of smaller issues creep up that we find in testing with extensions and in other environments, so we can make sure to address them.
Thanks for the update. I can hardly imagine what a huge undertaking this is. Looking forward to it.