S2member - excessive writing of transients into wp_options

s2member writes loads of transients into the wp_options table. I doubt if it cleans up properly or if all are needed.

While they are not autoloaded - a huge wp_options table is not good for performance reasons. Within 5 days (low activity period right now for my website approaching winter in Europe) - I have over 1200 lines of transients in my wp_options table (the full wp_options without s2member transients is only 500 lines).

I think it would be great if there could be a review if they are really needed. If yes then it would be much nicer if s2member could just write them into another table - and not wp_options for performance reasons. I cleaned up the transients recently - but I had over 50MB of those s2member transients leftover before. Much easier to clean if they are in another table and better performance.

Since wordpress 4.9 - wordpress should clean up transients itself - maybe there is some problem with s2member transients and wordpress cannot drop them?


I’ve been tracking this a bit longer. Now I’m already at over 2500 lines of s2member transients. There is clearly something wrong here and s2member is leaking transients (not cleaning them up correctly - or specifying them wrongly so wordpress cannot clean them up).

Here a screenshot of how my wp_options table looks like cluttered by lefover s2m transients. Pattern is the same.

Thanks for bringing this to my attention. I have added it to my list.

This is still quite excessive. Why does s2member set 10 year expiry for transients? In any case 366 days should be enough (if not 1 day) - right? What is the reason for 10 years?

I found out about the 10 year expiry after installing Transient Manager plugin. I think it is better now - but do we really need the 10 year expiry on so many transients.

If I clean them all - there is no problems! Nothing broke…