Raul P.

Hi there,

There are no known vulnerabilities on FVM and the plugin is regularly audited by me and third party services, like WordFence. Furthermore, if you download the plugin again, you can see that the offending code is not part of the source code.

JS files, from any plugin are prime targets for malware, as well as the theme header and footer php files, so the affected file is not relevant when auditing. WordPress core files are often also injected with similar malware, and it is not usually because of a core related vulnerability. The target of most malware that affects WP sites is random, to try to prevent detection. As long as it runs somewhere, is all that it’s needed.

A vulnerability has to occur in some PHP file, usually file upload related, or in some system that accepts api calls or importing of data, or sometimes simply something that accepts any user input, like a form.
Often the culprit is unsanitized user input, so a hacker can inject php code that will run as part of the execution.

Another possibility is a vulnerability at the server level.
If you use shared hosting, that can happen relatively easy if any site on the server get’s infected, even if they don’t belong to you. Malware can spread inside the server, regardless of user isolation (unless they use containers, which would make things more complex for malware, but not impossible).
If there is privilege escalation anywhere on the server, malware can spread to other clients.

FVM doesn’t allow file uploads, and it doesn’t accept POST requests except for admin users, so it is unlikely that it’s the culprit. It does however, merge and minify JS and CSS files, so if those have malware, they will be minified as it is and put in the cache directory.

If /plugins/wp-lozad/js/lozad.js?ver=5.8 is modified, first download a fresh copy and see if the error persists. It would not be the first time that hackers inject malware on repositories, but it’s rare. If the source is clean, then somewhere else allowed the vulnerability to go in.

I would suggest switching hosting and audit all themes and plugins, especially if any code has been custom made, or original plugins or the theme have been customized (meaning, they lack updates).

You can try to use WPScan to find versions of common plugins with known vulnerabilities.


And you can use something like WordFence to scan the whole site for other issues, though be advised, even with WordFence, your site can still have new malware, if it’s not yet part of their signatures.

There are high sensitivity modes to scan the site, but that will require a bit more knowledge to distinguish what is normal and not normal.

Hi, sorry, you meant the opposite of what I said.
Scripts in this plugin are added manually, because if you add everything they can break (not all scripts support deferring depending on how they are coded).

In this case, instead of using a more generic path, you need to spend some time adding all plugin directories you specifically want to defer, and do not add the ones you want to exclude.

That filter was made that way, to force developers to specify which ones to optimize.
It was though for third party scripts, even if it also works for local scripts.
The logic might be outdated a bit, sorry about that.

In the near future, I plan to review some of the logic and push another update with a few more options.

Hi, you can exclude anything by a matching path, so adding /plugins/someplugin/ will exclude all, but /plugins/someplugin/somefile.js will only exclude that specific file.

Hi, it’s not too weird at all, (if you understand what it’s doing) but it’s undesirable, of course.
Please check if you have some dynamic css or js file that is being minified (like the name or query string changing on every uncached pageview). That should be the only time where that kind of thing can happen.

If you minify a dynamic file with a unique name or query string (some developers add a query string that is time based to avoid caching), whenever the page is requested, the name will change, leading to a new file being found and thus minified again.

If you cleared the cache and then google comes and craws your site anew, it’s going to find as many different dynamic file names as the amount of pages it crawled. So if google spidered your site and fetched like 10k pages, it will see 10k alternative names for the same dynamic file, which FVM also sees… so it minifies it again and again (because the name is different every time).

To avoid that, you need to exclude the file, either by some partial path or some unique part of it’s name, and it will leave it alone. Else, if it’s common code, change your code so that it enqueues with a fixed query string value, so it’s always the same url across all requests.

That is not a bug, what is the problem?

Hi, all plugins are the same, just uninstall from wp admin and delete, that’s it.

A “broken” frontend, where you lost the CSS styling (visually) is page cache related, not this plugin related.

What happens in that case, is that your server has some sort of persistent caching, so when the plugin minifies the CSS files and duplicates them with a different name, the server caches the page pointing to those files. So then you clear the FVM cache or it auto clears as needed, but your page still points to the other files, now deleted.

In other words, your server cache configuration, does not clear automatically when WordPress clears itself its own cache. Normally, the hosting provides a way to clear page caching… so please check with the hosting.

The actual disk space used by the ibdata file in MySQL is going to depend on how you set the server, however, I can tell you that FVM shouldn’t be adding and then deleting data under normal circunstances.

It periodically deletes some data, but it’s to prevent growing the table beyond a reasonable limit.

For wp_fvm_cache the limit is 20k rows, and for the wp_fvm_logs the limit is 500 rows. The plugin will delete rows above this count.

The wp_fvm_logs are only created when you do a manual cache purge, mostly, so they increase but not so frequently.
The wp_fvm_cache increases whenever it sees a different css or js file, so as I said earlier, if there is a dynamic css or js url (the query string changes on each pageview for example)… it’s going to keep increasing.

If the wp_fvm_cache table is increasing the row count for every pageview, then you need to exclude that file, else it’s not efficient.

You can convert wp_fvm_logs and wp_fvm_cache to MySAM too, though it will affect performance when inserting data, because it will block the table instead of the row.

Removing FVM might mitigate the database storage issue, but check if indeed the two tables are increasing rapidly to those limits. If they are not, then data would not be deleted.

It would be more likely some transients used somewhere else (theme, plugins, code…) since those are meant to be created and deleted frequently.

If the issue is with regular wordpress transients, then adding a Redis Object Cache plugin will help you move them out of MySQL (transients will not write to wp_options anymore).

—

For MariaDB, you could try to switch to Percona DB and see if it makes a difference. It’s not the first time I’ve seen performance issues on MariaDB that don’t happen with Percona… but it’s still going to depend on the settings.

Take a look at these settings and see what you can do:

innodb_file_per_table:

• When set to 1, this option stores each InnoDB table’s data and indexes in its own file (.ibd file) instead of the shared ibdata1 file. This makes it easier to reclaim space at the table level. It’s typically recommended for most use cases.

innodb_page_size:

• This setting determines the page size for InnoDB tablespaces. The default is 16KB, but it can be set to 4KB, 8KB, or 64KB depending on your workload and hardware. Smaller page sizes can reduce waste when dealing with lots of small rows but can increase overhead.

innodb_buffer_pool_size:

• This setting controls the size of the buffer pool, where InnoDB caches data and indexes. A larger buffer pool can reduce I/O by keeping more data in memory, but it won’t directly affect disk space usage.

innodb_autoextend_increment:

• This variable sets the increment size (in MB) for extending the size of an InnoDB data file when it’s full. A larger increment can reduce the frequency of file extensions but might lead to more unused space.

innodb_optimize_fulltext_only:

• When set to 1, OPTIMIZE TABLE statements only optimize InnoDB full-text search indexes. This is relevant if you’re using full-text search and want to optimize those indexes without fully rebuilding the table.

innodb_file_format:

• This setting determines the file format for InnoDB tables. In MariaDB 10.3 and later, the default and recommended value is Barracuda, which supports features like table compression.

innodb_flush_method:

• This setting affects how InnoDB flushes data to disk. While it doesn’t directly impact space reclaiming, it can influence I/O performance and efficiency.

innodb_log_file_size and innodb_log_files_in_group:

• These settings control the size and number of log files in the InnoDB redo log. Proper sizing is important for performance but doesn’t directly impact space usage.

These are generic recommendations though, so good luck investigating that.

I would export the wp_options table (or take a look via phpmyyadmin), then look for the last rows added and see if they are related and what’s inside.

Cron jobs are stored?in the wp_options table of the WordPress database where the option_name is cron. Check it’s size.

You need to see if it’s increasing because of the cron field, or because more rows are added to wp_options.

Hi, it would require inspection on what is being stored there, but no, normally that shouldn’t happen.

The plugin settings itself is stored on wp_options, but that is similar to other plugins and takes a few Kb at most.
The wp_options is also used to store transient admin notices after manually purging the cache. It would not cause that to happen, as it only happens on manual interaction.

To store the minified css and js files, it uses it’s own table, wp_fvm_cache so those should not be on wp_options.

Please ensure you are running the latest version, and not some old or edited version.

A few years ago, there was a version that had a bug and was creating too many cronjobs. You can install a plugin like wp cron control and take a look at the cronjobs. It’s safe to delete anything fvm related.

If after installing the plugin, you see the database increasing in size, check if it’s really the wp_options or the cache table.

If it’s the wp_options you need to inspect and see what kind of data is being stored there, by looking at the name and content.

If the cache table increases too much, you likely are minifying a dynamic css or js file. If the name of the file changes on every pageview (check without fvm) then every pageview would trigger a minification for that file.
In that case, exclude it, as there is no point minifying a dynamic file.

Sorry for the late reply.
If the client has wp rocket, then probably they already have options to minify the files and also to delay js exclusions.
I would recommend using only wp rocket, as FVM would be redundant in this case.

Hi,

A few things cause that.

With FVM disabled, https://slimbyapriori.global/?nocache
your security policy (CSP) is not allowing some of the necessary scripts to run: https://i.imgur.com/G8WXepG.png
You should fix that first.

Second, you added sha384 integrity checks to some of your css (fontawesome) so what that does, is to check if the file had no changes. If there are changes, the integrity will fail and the file will not load.

Minification is a change to the file, so either you must remove the integrity check (check your fontawesome settings), or you must exclude the files with integrity checks from being minified, so that it doesn’t touch them.

I can add a check to remove the integrity check from minified files in the next version, but until then that is the solution.

Thanks

Hi, there shouldn’t be any mistake, but right now I cannot check if it’s a bug or something else. Does it work for other user levels?

There are a lot of enforced exclusions, regardless of the setting.

Auto-saving (DOING_AUTOSAVE)
Installing WordPress (WP_INSTALLING)
Repairing WordPress (WP_REPAIRING)
Importing data (WP_IMPORTING)
Ajax requests (DOING_AJAX)
Command-line requests (WP_CLI)
XML-RPC requests (XMLRPC_REQUEST)
WordPress admin tasks (WP_ADMIN)
Short initialization (SHORTINIT)
IFrame requests (IFRAME_REQUEST)
REST API requests (REST_REQUEST)

404 Error pages (is_404)
Feeds (is_feed, is_comment_feed)
Attachment pages (is_attachment)
Trackbacks (is_trackback)
Robot.txt (is_robots)
Preview pages (is_preview, is_customize_preview)
Embeds (is_embed)
Admin pages (is_admin, is_blog_admin, is_network_admin)

Checkout pages (is_checkout)
Account pages (is_account_page)
WooCommerce Ajax (is_ajax)
WooCommerce endpoints (is_wc_endpoint_url)

certain static files, such as .txt, .xml, .xsl, .map, .css, .js, .png, .jpeg, .jpg, .gif, .webp, .ico, .php, .htaccess, .json, .pdf, .mp4, .webm.

Request must be a GET request and the requested domain must match the one on the wp_options.

Request cannot be an AMP page.
Request cannot have query strings, unless you specify them.

A possible case is the existence of some cookie that forces you to bypass cache, or in some cases caching (like OPCaching). If not, it might be a bug on the plugin. I will check in the near future if it’s the case.

Thanks

You will need to purge it via API call, programmatically.
However, for APO specifically, you need to purge everything.

If you purge a specific URL, it doesn’t clear the same url with query strings.
If you have separate cache for mobile active, it only purges the desktop version.

If you are enterprise though, you can do wildcard queries to purge the url, but still no luck with mobile/desktop clearing by purging only the url.

Hi,

The last version to support 4.9 was FVM 3.2.9, after that it was bumped to 5.0… however, theoretically, the last FVM version should run on 4.9 if you simply edit the readme.txt from Requires at least: 5.6 to Requires at least: 4.9

To be honest, I don’t remember if I am using some function only available on v5+ so you would need to try and check.

unfortunately, it’s a very old version so to ensure that everything is completely removed, that is the only way, especially with multisite.