Raul P.

Should be fine, but its a matter of testing. Thanks

Hi,

If you are doing development, involving editing css or js files, you should never use any plugin that minifies files, and you should never be behind a cdn like cloudflare for example, without having some rule to bypass cache.

Furthermore, all your css and js files need a query param, that changes after each change.
I like to use filemtime on php to match the version to last modified date of the file itself for example.
You should not just use time() or similar, because later your url will keep changing and not be cached.

None of these things are related to any plugin, so for development, just go ahead and disable all cache and minification for all layers (plugins, server side, cdn, etc) and only enable those things on production.

Hi there,

Sorry to hear about that, you can try the 3.5.3 release now, which has better support for fonts.
What happened, is that some of the security fixes implemented were too tight, so it could block relative path fonts that shouldn’t be blocked.

Thanks

Hi, thanks for reporting. This should be fixed on 3.5.0 now.

Hi, it’s not an error, it’s an HTML comment for informational purposes.
Using AMP is already the optimization, so there is nothing to do with the scripts on AMP.

Hi, it’s been a while because I only work on this on my free time, and I haven’t had time for the project in a long time.

Normally, PHP Deprecated errors, only show up if you specifically enable error logging at that level, and it doesn’t affect the normal usage of sites in production (live sites). You should probably not have that level of error enabled on production sites, but it’s up to you.

That error also appears to mean, that you don’t have the correct wp_footer hook on your theme, or at least on some page templates, else it shouldn’t show up (it’s supposed to be there).

That being said, it doesn’t change the fact that the error should be accounted for and fixed, so I have pushed a quick release to sort it out.

I don’t have much time for this plugin at the moment, but it is maintained.

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, 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.