I have a scenario where I need to flag a user on an external API when order status changes. This currently works but we also need to flag them with the same flag if users are granted a complimentary membership/subscription inside WooCommerce Subscriptions. Investigating how to ensure we don’t hit that external API twice, once for the Membership becoming active and once for Order completing. Under normal operation that is what would happen.
It’s been a while since I looked at the docs on transients and current best practices so we’ll start there since transients can be stored for a limited time.
Transients can work for this, but maybe I don’t need to worry about it since it’s not a long query or a lot of data. We’re literaly sending an array of 3 keys with two letters in each. The only issue really is with our endpoint that may reject a few quick calls in a short time.
#### Transient Resources
**[The Deal with WordPress Transients](https://css-tricks.com/the-deal-with-wordpress-transients/)**
> Transients are for any chunk of information that takes a long time to generate. They will improve server latency for any routine more complex than retrieving a single database cell. That said, they are more code, and more code means more bugs. Therefore, I tend to reserve them for either remote calls or really large queries.
– so I’m not making large queries that need to be stored and I could make my transients stick around for maybe a minute or two
– the penalty for making a 2nd query occasionally if the transient isn’t there will not be high, we still do want to prevent it though
> It’s helpful to be able to identify all of the transients that pertain to your plugin. The way to do this is to prefix them with your plugin namespace. This is also crucial for preventing collisions with other transients. That’s why you see me doing `css_t_subscribers` instead of just `subscribers` in most of my examples here, where `css_t` is my imaginary prefix for css-tricks.com.
– need to prefix my transients with my “short” client name to avoid any conflicts
– for plugins maybe include the version number of your plugin in your constant name so that as you update any cache is invalidated by the update. Though that would mean that your old transients won’t be called again and thus won’t be invalidated.
– there is a 172 character limit on transient names. They may not get stored if you’re over that number because of old developer stuff that doesn’t matter. The old limit was 40 characters pre WP 4.4
– author suggests hashing transient names, but not the prefix, with `md5()` to compress the names down. That would give you 32 characters of the name and then you add your prefix.
– remember md5 hash is [not safe for anything](https://www.zdnet.com/article/md5-password-scrambler-no-longer-safe/) you want to keep out of people’s hands though this use doesn’t seem to be an issue to me
Additionally, although they can improve your project’s performance, transients are best reserved for large queries and remote calls. If it will require more code to create a transient than it will to simply make a fresh request for the resource each time it’s needed, you’re better off going without.
– again with the big request thing, so maybe I’m over thinking this
– check and manage your transients with [the transients manager plugin](https://wordpress.org/plugins/transients-manager/)
– totally, this is way easier than trying to dig through the DB for them especially because if cached they may not even be there
– if you set the transient time value to `0` or leave it blank the transient won’t expire
– could be good if you only want to get new information **after** you delete stuff
– large load sites effectively don’t have Memcache because they fill it so fast that by the time a user is requesting a cached value it’s already purged
– specifically if you’re store session data, which would rarely be called again because the keys won’t be called again unless the same session is there
**[10up Engineering Best Practices](https://10up.github.io/Engineering-Best-Practices/php/)**
– creating non-expiring transients is not advised because they’re all loaded on every page load so you could be dealing with a bunch of data
– also talks about cache priming so users never hit a blank cache via the transients API
**[Locking Mechanisms in WooCommerce](https://github.com/woocommerce/woocommerce/issues/15780)**
– the end result of the discussion is that they built a [queue system](https://github.com/woocommerce/woocommerce/issues/16971) instead. That seems way too heavy for my needs though
If you’re looking to [build a Membership Site on WordPress](https://sfndesign.ca), I’ve been doing that since 2009. [Shoot me an email](mailto:firstname.lastname@example.org) to talk.