-
# wp plugin list –status=active | grep fv
fv-wordpress-flowplayer active none 6.6.6
fv-player-pro active none 7.1.5.726.betaThis seems to be a regression from https://foliovision.com/support/fv-wordpress-flowplayer/requests-and-feedback/vimeo-issue-2 or a new component failed to recognize the dangers of
wp_options autoload.Our app profiling tool noticed a massive abnormal memory use (400MB memory usage just by loading
wp_options autoloadvalues), but it took me a while to understand how to pinpoint it.fv-player-pro/fv-player-pro.class.phpL730 is the guilty party, where it usesupdate_option()to store vimeo transcript cache WITHOUT explicitly settingautoload = 'no'parameter. WP API defaults toyes, and this causes potentially hundreds of MBs of irrelevant transcript data loaded on every request everywhere (incl wp-admin!).BAD:
update_option($option_name, $option);
MAYBE SAFER:
update_option($option_name, $option, false ); // @leho 2018.07.18
RETROACTIVE FIX
$ wp db cli
mysql> UPDATE wp_options SET autoload = 'no' WHERE option_name LIKE 'fv_player_pro_transcript_%' AND autoload = 'yes';
Immediately after the query, request memory usage dropped 10x and is back to normal.
This is a super bad situation, I recommend fixing immediately.
-
-
Would really be nice if your comment formatter would manager to understand standard
</code> and <code>something` markup better.
Hello Leho,
thank you for the bug report!
I’m sorry about the issue you have been facing here, specially as we faced similar issues before with some other plugins. At certain scale issues like this can appear, specially when using wp_options.
We will adjust the update_option() call to not use autoload as you suggested. While it’s not a perfect solution (the wp_options table remains big) it will work for now, as we are moving to a new database model.
Thanks,
Martin
Thanks. “wp_options” can handle a ton of data (I’m not worried about the table size at all), but yeah must avoid autoloading the rows. You should really find a way to retroactively run the SQL query for other customers, who may not be savvy enough to do it on their own, or even know to search for it as a bug.
Looking forward to the data model migration, but this change alone should certainly work well enough for a while.
Hello Leho,
I forgot to post an update here – FV Player Pro uses autoload properly since version 6.6.7 (or 7.1.10.726.beta).
The next version will also include code to fix this retroactively. Every time FV Player Pro is updated it clears the data cached for Vimeo, so I set that to remove these fv_player_pro_transcript_* options too. That way the old table rows with autoload will get deleted.
Thanks,
Martin
