As we approach the final release date of July 13th, 2022 here are the changes since the last major tag we gave you all.

There have been a significant number of bug fixes, but we wanted to call attention to some of the larger changes that might pose an issue for developers as they integrate with EDD.

Reporting Changes

We’ve made a few changes related to the reports to help give store owners an actionable set of information on the ‘Dashboard’ of reports. Many of these changes came after we’ve had a chance to use Easy Digital Downloads 3.0 on our own site, for our daily business operations.

The first thing you’ll notice is that we’ve consolidated some of the ’tiles’. We reduced the number of tiles in this Dashboard to make the overall view much more useful.

We’ve also been focused on fixing some issues around reporting with Timezones. As of EDD 3.0 all dates recorded in the database are in UTC. By doing this we gave ourselves a point of reference, so that we can always show the store’s reports based on the Timezone setting defined in the general WordPress settings.

Order status helper functions

As we started focusing on not just reporting on Gross and Net stats, we also found it necessary to define some ‘grouped’ order status keys. The following functions are helper functions to get specific order status that should be grouped. Each of these functions also contains a similar filter to allow extensions and customizations to add their own statuses.

edd_get_gross_order_statuses()

Returns an array of order status keys that should be used when wanting orders that should be considered part of a ‘gross’ report.

edd_get_net_order_statuses()

Returns an array of order status keys that should be used when wanting orders that should be considered part of a ‘net’ report.

edd_recoverable_order_statuses()

Returns an array of order status keys that can be used in the core payment recovery feature.

edd_get_complete_order_statuses()

Returns an array of order status keys that are considered ‘complete’. This means they have hit the end of any automated purchase process and no further action needs to be taken at this time.

edd_get_incomplete_order_statuses()

Returns an array of order status keys that are incomplete. This includes things like pending, abandoned, processing, failed or cancelled.

edd_get_refundable_order_statuses()

Returns an array of order status keys that can be refunded.

edd_get_deliverable_order_item_statuses()

Returns an array of order item status keys that should be considered when delivering files. Note that in EDD 3.0, deliverability should be handled at the individual order item level, since one order can contain multiple items with different statuses.

Enabled block editor on Download post type

The download custom post type is now available in the REST API, so your product pages can now be edited with the block editor.

Language files removed

We’ve removed all of our translation files from our package, in order to rely on the WordPress Translation community. We found a number of translation files that were out of date and causing fatal errors due to being incorrectly translated, so we felt it was best to remove them from our plugin entirely, and allow them to be downloaded from translate.wordpress.org.

On-the-fly Backwards Compatibility

We know that keeping stores accepting payments is important, and from day one of EDD 3.0’s development, we wanted to allow new purchases to be able to be completed, while the site was migrating existing payment data.

We’ve taken this a step further, so that when renewals are processed with Recurring Payments or licenses keys are interacted with (checking for updates, activating, deactivating, or checking), that these actions complete successfully with a ‘semi-backwards compatible’ layer of EDD that ensures critical functionality will still work.

We’ve also added the edd_v3_migration_pending option so that you can identify when a migration is either pending start or running. For instance, you may have seen this on our site a few weeks back while we were running this migration ourselves:

Other Bug Fixes and Changes

• Order details will now always show quantities for items.
• Improved performance getting cart total, by making tax calculations more efficient.
• Added a new Currency class, to help support multi-currency stores.
• Filters were added to the discount list table.
• Added a new edd_is_cart_empty() helper function.
• Improved performance of status calculations for downloads.

So what is next?

Well, now that we’ve tagged our final release, we’re going to be pushing this to WordPress.org as a ‘development version’ in order to allow translators to start translating all the new strings.

Shortly after that we will tag our final release on WordPress.org and we’ll go live on July 13, 2022!

As always with large releases like this, especially ones that are moving data around, we would suggest making backups of your site and database prior to any changes being made, as well as testing this out on a staging or local copy of your site first! We’ve tested it extensively and are already running this on our site, but it is always good practice to try it in staging first.

Thanks for your help and support!

Apple/Google/Microsoft Pay support

The long-awaited Payment Request Button feature has arrived in Easy Digital Download’s Stripe integration. Payment Request Buttons (or PRB, for short) is what Stripe calls it’s dynamic integrations for Apple Pay, Google Pay and the new Microsoft Pay.

Payment Request Buttons are supported on Single Download pages and Download lists using the [​downloads] shortcode as a “Buy Now” payment method. You can also enable the Payment Request Button on EDD’s Checkout page, where it will be the default payment method if the visitor’s browser supports it.

Visitors will be provided with the appropriate payment option, depending on their platform and/or browser. You can find the details about what operating systems and browsers are supported for each digital wallet service by viewing Stripe’s Payment Request Button documentation.

Stripe Checkout modal replacement

Almost a year ago, Stripe deprecated the ‘Stripe Checkout’ modal that some store owners preferred. This was in an effort to introduce the SCA features as well as their new Checkout experience. While there was nothing we could do about it’s deprecation, we chose to provide a similar purchase experience.

We’ve re-created the Stripe Checkout modal using Stripe Elements. While it is not a stylistic match for the Legacy Checkout product, the functionality remains similar so that store owners can once again use the modal to provide a fast and secure purchase experience, without the need of a cart or checkout page.

Split card fields

In version 2.7 of Stripe, we moved to using Stripe Elements to render the credit card fields. These secure fields, which are provided directly from Stripe’s library look like this.

While some people prefer the combined card field appearance which contains the card number, expiration date, and CVV, it does not work with everyone’s design preferences. In version 2.8 of our integration, we’ve added a checkbox, allowing store owners to have split card fields.

Other improvements

• Option to reject Pre-Paid cards.
• Automatically set the new card as the default if the customer has removed all cards.
• Updated Stripe Library to 7.47.0.
• Bump Stripe API Version to 2020-03-02.
• Send the EDD customer name when creating the Stripe customer object.
• Preemptive updates to allow for EDD 3.0 support.

Notable bug fixes

• Improved PHP 7.3 and 7.4 compatibility.
• Avoid Javascript errors on checkout when cart total is 0 or the page is loaded over http.
• When pre-authorization was allowed and SCA challenges were required, the charges could not be approved.
• Improved localization by fixing incorrect text domains and properly running error messages through translation functions.
• Expired cards did not display properly when managing payment methods and could not be deleted.

Using the beta

Easy Digital Downloads Stripe 2.8 Beta 1 is available to all valid license key holders either via direct download within your account, or you can receive betas in your WordPress admin by enabling updates to betas at Downloads > Tools > Beta Versions.

Taxes

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.

Reporting updates

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.

edd_get_gross_order_statuses()

edd_get_net_order_statuses()

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.

Customer updates

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
• Settings
• 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:

• Pre-Alpha
• Post-Alpha

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.

Software Licensing version 3.6.10

Our focus for this update was to address a large number of lingering issues. We made twenty separate improvements to Software Licensing in version 3.6.10.

The complete list of items addressed:

• Fix: When Apache forced trailing slashes, update packages could fail to be downloaded.
• Fix: When upgrading a bundle, the child licenses may not have gotten their price IDs updated.
• Fix: It was not possible to renew multiple licenses for the same product, at the same time.
• Fix: When using bundle licenses with children, the license list table had some performance issues.
• Fix: Child licenses could have a different activation limit than their parent.
• Fix: License counts on the list table for license statuses could be incorrect when child licenses were used.
• Fix: Some of the Readme information was not being parsed correctly after the latest parser update.
• Fix: Searching for a child licenses could give incorrect results, or no results.
• Fix: Updates could intermittently cause the ‘Too Many Redirects’ error.
• Fix: Searching for partial license keys and email addresses could cause PHP notices and/or warnings.
• Fix: When jQuery was being loaded in the footer, some JavaScript errors could occur when managing licenses on the front end.
• Fix: Searching for a non-existent license key, returned all license keys in the list table.
• Fix: Improved the reliability of the checks to make sure an update can be downloaded.
• Fix: When using custom keys, it was possible to use a key length that exceeded the database column’s allowed length.
• Sample Theme:
  • Fix: The sample theme was missing the theme_slug parameter from the API calls.
  • New: The sample theme now supports the item_id parameter.
• Sample Plugin:
  • Fix: The “View Details” link on the plugin list was not always present.
  • Fix: Sample plugin did not define the EDD_SAMPLE_ITEM_NAME string.
• New: Changelogs now support the “Read More” tag, to allow reducing changelog information stored in the get_version API calls.
• Dev: The license list table columns are now filterable and sortable.

Reviews version 2.1.11

Like with Software Licensing, our focus for this update of the Reviews extension was fixing minor issues that have lingered for some time.

We fixed six bugs in version 2.1.11. Those bugs were:

• Fix: Ensure custom code snippets cannot cause undefined index errors in the [downloads] shortcode
• Fix: Enable review request emails to be sent when now is the selected time period
• Fix: Compare version and only show admin notification for upgrade with outdated versions.
• Fix: Verify that orders are complete or published before request review emails sent
• Fix: Remove unused variable $post_id in class review widget
• Fix: Use timestamp $now to ensure review request emails are being sent at correct time relative to store timezone.

Along with a vast number of other improvements, one of our goals with 3.0 was to rebuild the way that orders (previously called payments) are stored, displayed, and interacted with.

When interacting with orders, there are a few important tasks store administrators typically need to perform:

• Create a new order manually
• Add or remove a downloadable product to an order
• Process a refund
• Resend the purchase receipt

All of these have been possible in the past, but some of them have either required an add-on (Manual Purchases) or been unintuitive. In 3.0, all four of these tasks are built directly into Easy Digital Downloads core and have simple, intuitive interfaces for performing them.

Watch out for additional previews in the coming weeks. We will be sharing more as we get closer to announcing our first alpha and beta versions of Easy Digital Downloads 3.0.

On February 2nd, an issue was discovered that caused subscription records to get assigned an expiration/renewal date of 00-00-0000 00:00:00.

The problem occurred anytime a renewal payment was processed for a subscription on sites running version 2.9.7 and 2.9.7.1 of Recurring Payments.

Subscriptions that had the problem occur will be corrected automatically when one of two actions is taken:

1. A renewal payment is processed
2. The EDD_Subscription object is instantiated in any context

The impacted versions of Recurring Payments were available for only a few days before the problem was discovered and fixed so there should be a very minimal number of impacted subscription records.

If you wish to determine if any of your subscription records were impacted, the following SQL query will locate them:

global $wpdb;

$subs = $wpdb->get_results( "SELECT * FROM $wpdb->edd_subscriptions where expiration = '00-00-0000 00:00:00' AND status = 'active';" );

Loading the details screen in WP Admin > Downloads > Subscriptions of any impacted subscription will correct the expiration date.

All Access version 1.1.2

This version included nine separate improvements.

A new report option has been added that allows site admins to view the most popular products based on the file download activity of customers.

The [edd_aa_customer_passes] shortcode has been improved so that it shows customers a history of their file downloads.

The [edd_aa_all_access] shortcode now accepts multiple product IDs, allowing you to restrict content to multiple All Access Passes.

The Process All Access Passes tool has been re-named to Backfill All Access Passes to better describe what it does.

The display of purchase buttons to customers that have lifetime all access passes has been improved so that they are not improperly shown a Renew option.

Behind the scenes we have also made a few improvements:

• Access passes are now properly migrated when a payment record is moved from one customer to another
• The user capabilities used for upgrade routines now match those used in EDD core
• Instances of EDD_Payment have been replaced with edd_get_payment() for improved compatibility with the upcoming Easy Digital Downloads 3.0 version

Along with the improvements above, we have also fixed four distinct bugs:

• License keys purchased for a product that has All Access enabled on it after the license key is purchased do not return the proper API responses
• Downloads per day not properly reset for customers that do not log in for more than a year
• Access Passes associated with a variable price do not sync properly with license expirations
• An error occurred when a payment record did not have a customer attached to it

Stripe Payment Gateway version 2.7.5

The processing logic that handles partial refunds detected via Stripe webhooks was previously held inside the Recurring Payments plugin. That logic has now been moved into the Stripe Payment Gateway for improved maintainability.

The Card Name field has been been updated to include placeholder text for improved user experience.

We have also fixed five distinct bugs:

• CSS was not properly loaded within the WordPress admin
• Purchases failed if a cart item title exceeded 1,000 characters
• “Buy Now” was still taking precedence even though the Stripe Checkout option is no longer available
• There were improperly localized strings in template-functions.php
• Creating a pre-approval with a new payment method failed

There are two plugin updates that you may need to install if you accept payments through Authorize.net with Easy Digital Downloads:

• Authorize.net Payment Gateway version 2.0
• Recurring Payments version 2.9.6

The biggest change in these updates is that we have moved the processing logic for automatic subscriptions in Authorize.net out of the Recurring Payments plugin and into the payment gateway plugin itself.

Previously the Authorize.net SDK and basic gateway logic was hosted inside the edd-authorize-net plugin and the logic for automatic subscriptions was in the edd-recurring plugin. There were some benefits to this but mostly it led to confusion and unnecessary development complexity.

By moving all of the subscription logic into the gateway plugin, we can now more rapidly and with more ease release updates and improvements to the Authorize.net integration.

With these updates, we have also introduced some significant improvements.

1. The Authorize.net SDK has been updated to the latest version
2. We introduced support for Webhooks, replacing the now-deprecated Silent Post feature in Authorize.net
3. We have fixed a significant bug with monthly subscriptions and free trial periods
4. We have replaced MD5 transHash with transHashSHA2 for webhook verification

If you use one or both of these plugins, please update to the latest versions to ensure full compatibility with all features.

Earlier this year, in January 2019, PayPal disabled support for multiple subscriptions on newer accounts. Merchant accounts that had been selling subscriptions prior to January 1, 2017 were grandfathered and permitted to continue selling multiple subscriptions in a single checkout.

Just under three weeks ago, PayPal sent the following email to affected merchants:

Unfortunately PayPal has now decided to cease supporting multiple subscriptions entirely. So now, regardless of when the account was created, PayPal merchants are no longer able to sell multiple subscriptions in a single checkout.

This change takes effect on November 1, 2019.

We have released an update to our Recurring Payments plugin. This update is to ensure your customers do not encounter an error during checkout. Please update to version 2.9.3 of Recurring Payments.

Customers that attempt to purchase multiple subscriptions through PayPal Website Payments Pro or PayPal Express will be shown the following message on checkout:

Only one subscription may be purchased through this payment method per checkout.

A lot of stores frequently sell multiple subscriptions in a single purchase and we fully recognize that this is not an ideal experience for customers. Unfortunately this is entirely outside the realm of our control and we’ve had no choice but to comply with PayPal’s sudden change.

To help the checkout experience when purchasing multiple subscriptions, we recommend disabling PayPal and, instead, using a payment gateway that continues to support multiple subscriptions. Our recommendation is Stripe.

If you’d like to continue offering PayPal alongside another gateway but also proactively prevent customers from having a poor checkout experience, we recommend installing this code snippet, which will automatically remove PayPal as a payment method when there are multiple items in a checkout.

New refund UI and APIs

In the past refunding items and orders didn’t quite follow basic tenants of the Generally Accepted Accounting Principles, or GAAP for short. This could create difficult situations in support when coming back to an order weeks, months, or even years later, to determine what was actually done with an order. Refunding an order was an all or nothing experience. If you wanted to remove a single item, it was completely removed from the order. As you may have experienced, this was less than ideal.

In EDD 3.0, we’ve completely changed how refunds operate. Refunds are now a specific type of ‘order’. Since a refund is similar to an order, they exist in the same database table with a type of ‘refund’. They also have related order items, which are the specific items refunded. You can refund some or all of the items from an order. Refunds can also have their own transaction IDs. We’ve worked up a user experience that I think will highlight this process here:

Next up for the refund process is getting gateway functionality baked in so that this new way of processing refunds works as seamlessly as possible with your enabled gateways.

Other improvements and bug fixes

• Fixed a bug in the get_average_refund_time method, which caused a MySQL error. (#7148)
• When creating a new order, tax calculations were failing when quantities were disabled. (#7072)
• Further improved the view/edit order details Customer information section (#7052)
• Fixed an issue that resulted in the status counts of orders to be incorrect when filtering the list table. (#7079)
• Improved the way the product dropdown works with bundles. (#6760)
• Improved timezone compatibility with PHP 5.5 and lower. (#7130)

Major updates yet to tackle

• Improve the upgrade routines for stability – A host of improvements are in the works to make the upgrade routines more stable and accurate as well as fault tolerant.
• Extension testing and compatibility – The time has come, to start working through extensions and make sure we can pre-release any known compatibility issues prior to 3.0 being released.

So those are the major changes since our last update. Keep looking for these posts until we hit the release date in order to make sure your upgrade to Easy Digital Downloads 3.0 is as smooth as possible.