Support » Plugin: Fast Velocity Minify » 3.0 Update

  • Resolved dimalifragis


    After using this excellent (before 3) plugin for some years, version 3 is the perfect example how to RUIN a plugin after a rewrite.

    Settings are lost and to understand what to do, you must guess. Or maybe now it is addressed to a very limited audience of very experienced people.

Viewing 3 replies - 1 through 3 (of 3 total)
  • Agreed. Love your plugin @alignak, but Whiskey Tango Foxtrot? Also, Stylesheets are no longer being server over SSL, and the switch to instruct FVM to use SSL is gone. I had to explicitly state the public URL in the cache field. Not a huge deal but it was not a seamless upgrade.

    • This reply was modified 5 months, 3 weeks ago by Andrew.
    Plugin Author Raul P.


    @omegaphase if the stylesheets are not served via ssl, likely your site is still accessible via http (when cache is being created), and most likely, your migration to https was not completed.

    You need to replace your database references, from http: to https: for it to be completed. Alternatively, you can also use the Really Simple SSL plugin to force it.

    The public url on FVM will match the one from your database.
    If you are allowing page cache on http: and if http: is accessible (not redirected to https:) then wordpress may be caching the HTML page when someone accessed it via http.

    Do a 301 redirect to https and replace the database references.

    Plugin Author Raul P.


    @dimalifragis the plugin has always, from the start, geared for developers and advanced users. However, settings remain mostly the same.

    Most of the settings have been either made default, or converted to the new plugin setting.

    The 2 main differences now, are

    a) some stuff is no longer needed because it has been replaced with more efficient code or method, and
    b) JS merging is no longer automatic, so if you wish to optimize it, you need to manually choose what to optimize.

    The decision of not merging JS automatically came, because not all scripts can be merged (they conflict with each other), and some scripts cannot be deferred (somethng breaks)…

    In other words, rather than to merge and then have users coming here and say that it doesn’t work (there is no way to solve scripts conflict automatically as it depends on each unique site), I have decided to make it more compatible by having JS optimization disabled by default (will allow nearly all sites to work by default).

    Of course, if you wish to optimize JS you can just fill the settings, however, because optimizing JS can break sites functionality, it’s now your responsibility to test and decide what can be deferred, what depends on it, or what needs to be render blocking.

    I understand the previous setting was automatic and then people just had to deal with the conflicts, but this has created issues from the start and thus, it lead me to make the option manual.

    If you refer to the help section on the plugin, it should be as straightforward as to copy paste some paths to the JS settings, but nevertheless, you still need to understand your site and what your scripts do and how they relate to each other.

Viewing 3 replies - 1 through 3 (of 3 total)
  • You must be logged in to reply to this topic.