In Easy Digital Downloads version 2.5, we introduced a new class called EDD_Payment. This class provides easy-to-use methods for interacting with payment data in Easy Digital Downloads. It covers retrieving payment records, creating new payments, updating payments, and deleting payments. It is a complete abstraction for the underlying data structure of the payment records.
There are two primary purposes of EDD_Payment:
- Provide an easy way to interact with payment data
- Abstract interaction away from the data layer
The second point is extremely important, primarily because it provides Easy Digital Downloads with the flexibility to change the data layer.
Why is this so important? It’s actually quite simple: the main database structures in Easy Digital Downloads were written four years ago and are really beginning to show their age. When I first built Easy Digital Downloads, I had no idea it would scale up to what it is today and, for that and many other reasons, not as much careful thought was put into the creation of the database layer. There were design decisions made four years ago that have inhibited our growth and flexibility since.
In the next 6-12 months, we plan to make some truly significant improvements to many of the underlying data structures in Easy Digital Downloads, and in order to do that we need everyone to move away from directly accessing the database and adopt the abstraction layers we have provided.
The EDD_Payment object provides everything needed for interacting with payment data. If you have written an extension or done any kind of custom development that involves interaction with payment data in Easy Digital Downloads, please ensure you are using the EDD_Payment class.
Within the next 6-12 months we will be migrating all of the payment data, which is currently stored in the wp_posts and wp_postmeta tables, to a custom table structure that will significantly improve the performance of Easy Digital Downloads and allow us to build much greater reporting capabilities in the future. On top of the migrating the data, we will also be building a series of backwards compatibility layers to help the process be smoother.
In order for us to do this with as few pain points as possible, it is paramount that all Easy Digital Downloads users be using the abstractions layers that we have provided. The abstraction layers allow us to change the database layer of Easy Digital Downloads without affecting the functionality in any way, and allows us to make this change without disrupting the functionality of custom applications that have been built on top of Easy Digital Downloads.
As we gradually make the migration to storing data in custom tables, the abstraction APIs provided will become more and more important for extension developers and those developers building custom solutions on top of Easy Digital Downloads. In the interest of preventing future problems, please ensure you are using them.
If you have any questions or are unsure of any aspect of how to use EDD_Payment, please use the comment area below. It is in our interest, as well as the interest of everyone else, to ensure the transition over the next 6-12 months goes smoothly.
You can learn more about our plan for the new database structure and the current status of the project on GitHub.
Great move! Scary, but needed! Finally custom tables for payments, that’ll be amazing. Thanks for the heads up! 🙂
Just exactly what does it mean for me, an EDD user, to “start using the abstraction layers”???? What is it, exactly, that I need to do so that I don’t have problems later on down the line when these changes are made? Thanks
As an Easy Digital Downloads user, you won’t need to do anything beyond ensuring your EDD plugins remain up to date. These changes are for EDD extension and theme developers.
OKay, thank you for a very prompt response! I appreciate that very much. I always update my plugins as soon as I find out about them, so that works for me …
Good initiative. I agree that while using WordPress’ standard tables can work in a lot of cases, certain specialized uses will work better with custom tables. It’s good that you’re getting the advance notice out _now_ to be using the appropriate functionality to ensure forward compatibility. I’m going to be working on a plugin for EDD in the not-too-far future, so I have been gathering notes on working with EDD’s functionality.
Hi, any new about this improvement? I think it is a must, even on a dedicated server it’s starting to be impossible to have the site running without daily crashes.
The migration to custom tables is progress and will be released with EDD 3.0.