get_transient() is now more strict in 4.3

WordPress 4.3 includes a change to get_transient(). As reported in #23881 and #30380, get_transient() had a check for get_option( $transient_timeout ) < time().

Because get_option() can return false and false is always < time() 😖, get_transient() could delete transient timeout options in an unexpected way or cause two more unnecessary queries.

WordPress 4.3 now checks the return value first before comparing with the current time. This means that WordPress will no longer delete broken transients via get_transient() if you have only deleted the timeout option. See [33110].

If you have to delete a transient manually, please make sure that you’re deleting _transient_timeout_$transientand'_transient_' . $transient. (Hint: Transients can be stored in an external object cache too.)

@ocean90 – just letting you know (if you do not already) that the change to get_transient is a very big problem for Premium Plugin and Theme developers and a potential timebomb for WordPress users of Premium products.

Our plugins like most Premium Licensed plugins and themes auto check for new versions using transient to call to the a3api once each 24 hours.

The obscure change to the transient has deleted that. We alone now 9,000 plus licensed plugins that no longer call to the a3api (if they have upgraded to WP 4.3) and can never know that there is a new version. I know that this affects many developers premium plugins.

That is not the issue – because adding that in a new version is of no help as the user never sees an upgrade notice to get the code if they have already upgraded to WP 4.3

I do not know how many WP users will be affected by this as just about every Premium Plugins has the issue now – example Gravity Forms and All WooThemes WooCommerce plugins

There is not much point in emailing customers to tell them about it and ask them to deactivate and reactivate the plugin or theme (which will trigger a manual call to the a3api and get the new version for auto upgrade via core updates) as email open rates on mass mail outs are low.

I have absolutely no idea what you can do about it or if you are even interested in rectifying the situation – but just be aware that there will be many 100,000’s of thousands of Premium plugins and themes sitting on WordPress sites that will never be updated again and that is a massive security issue.

I think @mordauk may be better equipped to explain it, but can’t you hook into wp’s update checker and just add your own API to it? That was always the preferred method as I understood it, and uses WP-cron. I know EDD does that to look for updates to my add ons.

Hi Mika and Pippin – thanks for your replies. We used to use the standard update API of WP but it caused issues as the API call not only checks for new version but also checks the “SERVER_ADDR” to verify the License key. This was failing due to a known and unresolved WP_CLI bug – wp doesn’t fully populate $_SERVER array https://github.com/wp-cli/wp-cli/issues/1734

As a work around for the issue we created a fall back cron that if the “SERER_ADDR” fails then the call is scheduled for every 2 hours for 10 retries. Doing this completely resolved the issue.

This is the code
//Getting version number
$respone_api = get_transient(“wc_psad_update_info”);
if ( ! $cache ) {
$respone_api = false;
}
// If transient is expired or is not existed then connect to a3api server to get new version and save to transient as cached with timeout is 24 hours or 2 hours for some way can’t connect to a3api server
if ( ! $respone_api ) {
//connect to a3api server to check new version
}

on WP 4.2.4 or older
if ‘_transient_timeout_wc_psad_update_info’ is deleted by any reason
$respone_api = get_transient(“wc_psad_update_info”);
will return ‘false’
and is correct to our plugin connect to a3api server for check new version

With WP 4.3
if ‘_transient_timeout_wc_psad_update_info’ is deleted by any reason
$respone_api = get_transient(“wc_psad_update_info”);
will not return ‘false’, it return cached value ( this cached value is never removed if ‘_transient_timeout_wc_psad_update_info’ is deleted )
and it never go to
if ( ! $respone_api ) {
//connect to a3api server to check new version
}
to get new version

Hence the plugin can never call for new version – user has no idea and just thinks there is no updates. We have a developers License for Gravity Forms and know it has the same issue as well as WooThemes WooCommerce plugins

As I wrote the fix is easy – what is not easy or clear is how let License holders know that there is an updated version with the patch.

I note the update was “get_transient() is now more strict in 4.3”

I am not aware of any issues with the old get_transient function? Was there security or other issues that required the change?

As I wrote we are not the only Premium plugin developers who have this issue and unless it is addressed there will be 100,000’s of wp site with plugins or themes that never show new version upgrades and hence over time will become a security issue.

The issue with the old get_transient was they weren’t deleting properly. They could “could delete transient timeout options in an unexpected way or cause two more unnecessary queries.” In the race for speed, the queries were killing some heavy sites.

Looking at your explanation:

This was failing due to a known and unresolved WP_CLI bug – wp doesn’t fully populate $_SERVER array

Without looking at the code that was failing I can only ask “Why did you chose to do this instead of not using $_SERVER?” Looking at that bug (https://github.com/wp-cli/wp-cli/issues/785 is the current one), using dirname(__FILE__) was a good fix, and FWIW, I’ve actually had $_SERVER in my wp-config and it does ‘break’ wp-cli but how does that break your code? My updates have trucked along just fine with wp-cli being weird. I don’t get how they’re related.

Also where was the SERVER array in your code, what was it being used for, and were there other alternatives? I’d love to see if we can fix this the ‘right’ way … Though IMO the ‘wrong’ is because wp-cli is borked because PHP (yeah, it’s PHP) is stupid. I’ll drop a note to wp-cli about it.

The answer for “How do I inform my users?” is one presumes you have their contact information? So … email. It sucks but a “Hey, sorry about this but we didn’t notice a change in WP conflicted with our update checker. You need to manually update. We’re REALLY sorry. Here have a free orange.” Or something like that.