- Early access to new free plugin which speeds up imports even more! - October 14, 2024
- ChatGPT really sucks at SQL - August 9, 2024
- We’ve launched our newsletter again - July 24, 2024
I actually discovered this performance issue right here on our own website. Normally I discover performance issues on client or customer websites. From now on, as I discover badly behaving plugins, either on my site, or through optimisation work I do for clients and customers I will be taking the time to write about them and expose this bad behaviour.
My first hope is that these plugin authors will be shamed into acting – if you own this plugin, you could contact the plugin authors through their support channels and link them to this article. My second hope is that WordPress developers learn and improve over time. It’s a sad truth that many plugins are written with truly awful code where the developers spend more time on marketing than they do on quality of code.
In this case, I had Query Monitor active and was looking for something else – something related to MailPoet which I really dislike as a plugin but that’s a story for another article. While I was looking at what MailPoet was doing wrong, I discovered the following terrible behaviour on pages totally unrelated to products – i.e. the Product Customer List code should not be running:
You can see in the screenshot that this plugin is updating a few options, notably which plugins you have installed and then also many details about your installed plugins including license keys. That’s not cool.
If you look at the call stack, it looks like it gets initiated by the Surbma GDPR plugin and then by Freemius which is located inside this Product Customer List plugin.
Freemius, in case you don’t know, is a rather large company who provide a licensing system for small plugin developers to help them manage licensing and sales. In return they take 7% of your revenue. They seem decent, but I’m going to investigate further to figure out what is happening here with the storage of license keys in this option.
Upon further investigation, on my own website I have 3 plugins which use Freemius – Surbma GDPR which I’m going to replace, EU VAT assistant which I no longer use and this Product Customer List for Woo plugin which I’m going to remove.
The sensitive info (which plugins you have installed) is stored against fs_accounts, but in the code this is enumerated as: WP_FS__ACCOUNTS_OPTION_NAME
According to Freemius and @Vova, they gather all of this data in order to help their plugin authors improve the usage of their plugins.
I myself am planning to add something like this in a future version of Scalability Pro, but you can be 100% sure that I will ask users – they will have to opt-in – and it will be 100% clear what they are opting into and what type of information will be sent to us.
Probably better than that, I probably won’t make the data submission automatic – I’ll probably raise it at a relevant point in time and ask the admins if they would like to send this data to us rather than doing it hidden underneath.
Here’s what Freemius had to say:
There is quite a bit more back and forth with other customers getting involved, but the upshot is it looks like Freemius do not care and are going to remain non-compliant with GDPR.
https://wordpress.org/support/topic/freemius-and-privacy-concerns/
As for me, I care about performance and that’s how I got here in the first place – what is this plugin updating massive options on every page load?
The answer is that it’s any plugin that has Freemius embedded that is saving massive amounts of info to your wp_options table and then at some later point uploading this info to the Freemius servers so the plugin authors can review their analytics and so Freemius can improve and track sales.
For me, I’ve now removed all 3 of these Freemius embedded plugins and Freemius is now on my blacklist. If any plugin comes embedded with Freemius, it is not recommended for both performance and GDPR-compliance reasons – controversial given that one of the Freemius plugins is focused on helping you stay compliant with GDPR!
Really interesting.
What bothers me, too, is the wp_options = autoload yes for frermius options. Do you think these could just be set to autoload = off?
How big are they and how many of them are there? Then the other question, are they actually used and looked up on every page? If they are not used on every page then turning autoload to off will help.
You can test turning off items to check before & after performance by setting autoload to anything other than ‘on’ – the PHP code does not check for alternative values, it only grabs items that have ‘on’. When get_option is called and the option requested is not an autoload item, in that case a SQL query is created to grab that item and they ignore the autoload option in that case.
i.e. you could set autoload to ‘test_freemius’ and this would switch autoload for those options off, and then if you need to switch them back on then you can target all the options with autoload=’test_freemius’ in order to reset autoload to ‘yes’