You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When I have an individual license key activated (not a pass), I expect EDD to always recognize that.
Actual behavior
If the global $edd_licensed_products is referenced outside of the wp-admin context (is_admin()), then EDD can think I have no license keys entered, when actually I do have one entered.
The problem is that some of our extensions, like Software Licensing, only instantiate the EDD_License class if is_admin(). That means the results of $edd_licensed_products can be inconsistent when checked in a non-admin context.
This is a blocker for #8941. There are two cases where I'm using that variable and getting inconsistent results:
When cron is running.
In a REST API response.
Information (if a specific version is affected):
PHP Version:
EDD Version (or branch):
WordPress Version:
Any other relevant information:
In the long term we should refactor how add-ons initialize that class, but we cannot rely on updating all add-ons prior to releasing #8941. So I'm making this issue to work on a semi-gross patch, and I'll make a separate issue for a better long-term solution.
The text was updated successfully, but these errors were encountered:
Bug Report
Expected behavior
When I have an individual license key activated (not a pass), I expect EDD to always recognize that.
Actual behavior
If the global
$edd_licensed_products
is referenced outside of the wp-admin context (is_admin()
), then EDD can think I have no license keys entered, when actually I do have one entered.The problem is that some of our extensions, like Software Licensing, only instantiate the
EDD_License
class ifis_admin()
. That means the results of$edd_licensed_products
can be inconsistent when checked in a non-admin context.This is a blocker for #8941. There are two cases where I'm using that variable and getting inconsistent results:
Information (if a specific version is affected):
PHP Version:
EDD Version (or branch):
WordPress Version:
Any other relevant information:
In the long term we should refactor how add-ons initialize that class, but we cannot rely on updating all add-ons prior to releasing #8941. So I'm making this issue to work on a semi-gross patch, and I'll make a separate issue for a better long-term solution.
The text was updated successfully, but these errors were encountered: