Not usable anymore

Hi,

As explained on the release notes, you are advised to backup before upgrading.
FVM 3 converted some settings to become default, hence they are now gone, but they are actually already there behind the scenes.

FVM 3 no longer optimizes scripts by default (for compatibility reasons), so please refer to the HELP tab on the plugin for suggested defaults, which will be equivalent to what it was doing on FVM 2.

It’s not enough to enable it, as that won’t do anything else by default.
You need to enable AND manually insert the scripts, or paths you want to optimize.
If there are no scripts on the list, enabling it will have nothing to process.

There are instructions for each field and how to reconfigure it again.
I understand it’s 50 sites, but I hope you are not just upgrading everything in one go without testing plugin updates… this is a major upgrade, and things usually change in major upgrades.

—

Especially gsap.js related animations are not working at all. There are no JS errors in the console, and we can’t figure out what happened.

Because scripts are no longer optimized by default, and if you haven’t add any scripts, this is likely some CSS issue when merging.

Debugging CSS is exactly the same as before.
First you disable CSS processing and see if that is it.
If it is, you can try and disable the “Merge Fonts and Icons Separately” option and see if it works.

If a specific CSS file is overwriting some rules, you will either have to write more specific rules so that they don’t get overwritten https://www.smashingmagazine.com/2007/07/css-specificity-things-you-should-know/
or you just need to add the offending css filename to the css ignore list.

To decide what to put on the ignore list, look at the status page for a list of CSS files being merged. You can then try one my one to exclude it, until you find the culprit.

Javascript works the opposite way.
It will not touch any scripts, unless you manually choose to optimize it, either by merging in the header as render blocking, or to defer it.

The majority of the plugin works exactly as before, except for the javascript part that is now manual, as it’s been an issue from the beguinning.

Optimizing js files, is always a manual process even if it was working for a lot of sites. However, on FVM 3 instead of finding which script is breaking what and ignoring it, now they are all ignored by default and you just need to add all the scripts you wish to optimize and evaluate if there are errors.

I understand it gives a bit more trouble to configure, especially for 50 sites, but it’s safe and more compatible for the future and it forces users to know their site better, than to just click a button and expect it to work perfectly for every site.

Unfortunately, it just doesn’t work like that.
Optimization is still a thing people need to look into it manually, especially for large sites.

Hope you understand.

Thanks

To be honest your answer kind of shocked us. After doing testing JS optimization doesn’t work at all! It doesn’t matter what control fields are selected in the backend. It just has no effect anymore. CSS seems to work. The JS log is empty.
We were maybe one of the biggest promoters of your plugin in Europe and even paid you in the past for custom development for including the processing of js.php files if you remember. We’re devs ourselves and know exactly how optimization works. The thing is you had by far the best optimization plugin on the whole WP marked and now making a non-backward compatibility upgrade destroying dozens of hours op optimization work we and our clients already have done in the past within the old configuration. We don’t get why!!! We now have to think about hiring a new dev for a future fork of your plugin. Why make it super complicated when something already worked? We’re really sad because we loved your work so far!

After doing testing JS optimization doesn’t work at all!

Are you sure you have both enable js processing, and filled the textareas with the appropriate default, recommended settings?

Can you post a screenshot of your settings?

We’re still experimenting on our dev server about that specific error that JS minification doesn’t work at all. Nevertheless, for us with over 50 own websites and several hundreds of WP installations with custom settings within the old plugIn it’s no option to ever upgrade. Nobody will pay us for that work so that means we now have to inform hundreds of our clients that we no longer can support that plugin on our hosting platform. We are getting massive support tickets even today and had to do dozens of backups even today. We promoted your plugin when these clients came to our platform, so it’s a bit difficult for us to now communicate to not use it anymore. Why in the world there were no upgrade script/path/option. The amount of work for a manual upgrade for hundreds of websites is impossible to do for anybody. Your plugin was usable for end users and exerts at the same time and now has become an exclusive tool for just the experts. In my understanding this will make it unusable for 90 % of all users.

It’s not as simple as converting js settings between version 2 and 3.

The decision to disable JS Optimization by default is for compatibility reasons and also to bring it to more modern standards.

Previously JS optimization worked by merging everything that was enqueued properly (only), while scripts that were not enqueued were not detected. On FVM 3, all scripts can be detected and optimized.

Previously, with the automatic JS optimization, it often resulted in JavaScript errors, broken functionality, etc. You could then exclude files that caused errors via the ignore list. The problem is, any non technical user will have no idea how to fix those, what the ignore list does or why it’s needed, let alone, what to put there. On FVM 3, instead of risking breaking sites after a new install, it only does safe optimizations by default, such as HTML and CSS.

On FVM 3 you have full control over what scripts to merge, how and where. You can also choose to mark inline js code dependencies, so that those inline scripts wait until the deferred scripts finish before running.

This dependency option, allows for a lot more files to be merged, when previously they had to be excluded.
In other words, this means less requests and better performance.

The option to exclude some files from PSI was removed, because it used JavaScript document.write which is now deprecated.
It’s also considered cloaking to do this, so I have removed it. However, you now have a similar option to optimize third party scripts.

Scripts like facebook, google tag manager, hotjar, etc, can be delayed until user interaction or up to 5 seconds.
This means, less data on the initial request, which will improve your web vitals scores in the long run.
Previously, all those tracking scripts would affect your CRuX reports and web vitals…

Several minor settings from FVM 2 were automatically converted or included by default on FVM 3.
Some methods have changed, but in essence, they were all well tested and they will improve your scores.

FVM 3 requires a re-audit of it’s JavaScript settings, but this is simply necessary maintenance that will achieve the same or likely better results as before.

Defaults that work with most sites are also provided in the HELP section, and they roughly mirror the FVM 2 settings if you copy paste them to the settings.

—

The sites should be visually the same as before the update, and having temporarily lower scores on the tests because scripts are no longer automatically merged by default, will not break your sites and it’s neither critical priority to solve.

New sites that install the plugin will benefit from it, as well as older sites that review and update the settings properly.

I completely understand that with dozens of sites, you do not wish to do that… but please understand, that doing it is also part of the maintenance process and part of the cost of managing and owning a website.

I seriously doubt you will use more than 5 minutes per site to copy paste and save a few settings.
If nobody is paying you for that time, then perhaps you need to consider maintenance fees and plan for this.

As you know, once you upgrade WordPress to WP 5.6 and later to WP 5.7, it’s bound to break a lot of sites due to the significant jQuery changes occurring now. Same as FVM 3, you will eventually have to deal with maintenance.

Changes are needed and they happen all the time, not only with plugins, but also themes and WordPress itself.
Going back to 2.8.9 because you don’t want to deal with it, it’s not a solution… is just delaying the inevitable.

If you now remove the plugin, the site will just work as it was made to work.
If you want to optimize the sites, then you need to understand that speed optimization, requires periodic maintenance.
Obviously, updating the plugin and reviewing it’s settings, is part of it.

If you don’t want to spend time reviewing the settings, point your clients to this forum or to the help section in the plugin.

If they are not willing to pay for your time re-optimizing the speed, then that simply means they do not value their site being optimized.

I appreciate you recommending the plugin, but as you know it’s completely free and I do not get anything out of it other than experience.

Trust me that I completely understand how frustrating it must be to go and update dozens of sites because of a significant change, but keep in mind, this is something extra you do to speed up sites for your clients, and should be charged separately.

If you recommended the plugin and charged them money to configure it, then you cannot complaint.

If you simply recommended it and don’t want to deal with it, then clarify you do not own the plugin and point them over to the HELP section, or this forum and let them deal with it.

Other than that, nothing else I can do.

—

In regard of minification not working, minification and merging are two different things.

I suggest following these steps to ensure everything is done correctly.

a) Disable and enable the plugin, just in case the update routine failed for some reason.

b) Enable JS processing and then look at the HELP tab, for the recommended defaults and copy paste them back.

c) Make sure the wp-content/cache directory is writeable.

d) Purge all caches available, both on FVM, server, page cache, cdn, cloduflare, etc.

e) Optimize any third party js code, by looking at the scripts on the page and manually auditing them. Again, there are examples on the HELP tab.

f) Ensure you have a sufficiently high memory limit defined on wp-config.php (I usually recommend 128 or 256 MB).

—

And if this doesn’t work, let me know.

Sorry you have to do it for so many sites.

I think you don’t understand our point. We don’t do WP maintenance. We’re one of the biggest WP hosting companies in Germany and Europe. It’s impossible to handle or communicate such an upgrade without automatic migration path. We promoted your plugin heavily as other providers did too. We will send out a newsletter tomorrow and also press releases to inform our clients to deinstall this plugin immediately. With all respect, I think you have absolutely no a glimpse of an idea what happened in the support departments of many hosting companies today! This is a mess!!! This was a major plugin which everybody recommended. This will be over now if there will be no proper migration path.

Just one example: Nearly every newer theme shifts jquery to the footer, which also works. With your plugin even with the new configuration jquery has to be shifted back to the header, which alone leads to significant higher loading times.

We find it unprofessional to do a major upgrade overwriting custom settings and not being backwards compatible from one day to another. A lot of onlineshops on our plattform had massive issues today after the upgrade too.

If you are not willing to find a solution for an automatic upgrade path my forecast is, that this will be a VERY BIG ISSUE in the WP community in the next few days in general!

We know the plugin is free, and we appreciate the work you have done, but destroying a loyal base of users by overwriting custom settings which are not easy to bring back is a very bad idea we think.

Also by default there are now massive problems with nearly ll major WP themes like Avada, Divi oder Enfold which are widely used.

I think you only see this case from a developers’ standpoint which is very bad!

ust one example: Nearly every newer theme shifts jquery to the footer, which also works. With your plugin even with the new configuration jquery has to be shifted back to the header, which alone leads to significant higher loading times.

I’m sorry but you are mistaken on this.
With JS optimization by default (disabled), it will not touch it regardless of where it is.

Obviously, now if you want to optimize it, you can choose to add jQuery (either) render blocking, OR to defer it, as well as any other script on the page.
Deferring is the equivalent of putting them on the footer… it’s actually better, because a script that is deferred in completely non render blocking, while a script in the footer is still render blocking (it just happens, there is nothing to render after it).

—

A lot of onlineshops on our plattform had massive issues today after the upgrade too.

I don’t think those store could possibly had “massive issues” due to this… it doesn’t make sense. By simply stopping js optimization, it goes back to be exactly as it was meant to be by the site owner, unless there was some other css issue.

At most, they would complain their score went down.

—

Also by default there are now massive problems with nearly ll major WP themes like Avada, Divi oder Enfold which are widely used.

I happened to test this on multiple Divi and Avada sites before the upgrade and there were no issues with the default settings. Obviously, JS wasn’t optimized, but that was it.

—

I think you only see this case from a developers’ standpoint which is very bad!

No I am not, and there are many other users that were very happy with the new update and better performance, provided they take a few minutes to re-adjust those settings.

The benefit of using the new version after re-optimizing it is much better than using the old version method, but it does require re-optimizing some settings.

—

Having said that, I agree that preserving the old FVM 2 settings are important in case people want to downgrade, and I’ll have an update for that shortly.

The option to “Remove Google Fonts completely”, “force https”, “Inline CSS” and “Preserve Settings on plugin deletion” will be brought back, those these are minimal.

In regard of JS optimization itself, which seem to be a big issue for you, there is no way to convert those settings to the new FVM 3 method.

However, in consideration to your request and situation, I will see if I can quickly create a legacy switch, that will allow you to update while preserving the old FVM 2 behavior from FVM 2.

The next update will be out shortly, to allow the old settings to be preserved after upgrading to version 3. That way, to rollback it’s a simple as downloading and replacing the plugin.

The other update will likely take a day or so, because I have to see how to implement the legacy mode.

First, thanks for the quick reply!

The jQuery example is a very important one because it is still used in WP. From my understanding when a theme shifts it to the footer your old plugin had the ability to leave jQuery alone and NOT defer it. This is not possible anymore. Shifting it back to the header for the PSI point of view IS a BIG ISSUE! There is no possibility to blacklist scrips. If you want that now, you have to enter script by script, which is just impossible. Why no global blacklist anymore? This was a top feature, because we all know which scripts better leave alone! Please bring it back!!

The problems with many sites today were a front end performance issue which caused many online shops to perform worse. You could directly see it by the live sales numbers.

I think a legacy mode (maybe for a limited time) would be a very good idea. Along with a blacklist option. Script Blacklist was the major key to the compatibility of the script.

Last point: please handle jQuery and jQuery migrate as separate files when it comes to the load from CDN function because many themes handle the jQuery migrate file in their own scripts (for what ever reasons). If you combine or load it from a CDN together it causes many problems.

Thanks for your help!!!

From my understanding when a theme shifts it to the footer your old plugin had the ability to leave jQuery alone and NOT defer it. This is not possible anymore.

Now you have full control… you only need to be more specific with the paths.
The new version doesn’t move jquery back to the header, and neither you are forced to defer it (though you should, if you were putting it on the footer).

If jquery.js is on /wp-includes/js/jquery.js and you wish for the plugin to leave it alone, then simply use longer paths to match the other files you wish to merge.

If you put /wp-includes/ on any of the other sections, it will process any script with that common path. If you do not wish to do it, then simple use longer paths or exact file names.

The blacklist was just a way to exclude one or several files from the pond.
Now, you choose who goes into the pond and everyone else stays outside.
You just have to specify them either by name, or more complete path.

—

The problems with many sites today were a front end performance issue which caused many online shops to perform worse. You could directly see it by the live sales numbers.

This is most likely something related to the Google December 2020 Core Update.
https://searchengineland.com/google-december-2020-core-update-rolling-out-344333
https://www.seroundtable.com/christmas-weekend-google-algorithm-update-30665.html

Many stores have drastically drop on their rankings on the past few days.

It’s nothing to do with disabling JS processing.
It just happened that this change came around at the same time.

—

Last point: please handle jQuery and jQuery migrate as separate files when it comes to the load from CDN function because many themes handle the jQuery migrate file in their own scripts (for what ever reasons). If you combine or load it from a CDN together it causes many problems.

It will only load from the CDN if you specifically choose that option, else it will use whatever you have. Likewise, as I said earlier, it will only merge what you name and i the location you need.

If you have a specific site that is causing issues and want me to look into the settings, contact me via fastvelocity.com with access to a staging version, if available. I can reconfigure it for you as an example.

Exactly this is a major problem. When handling hundreds or thousands of sites it is NOT possible to handle script by script. If there is a global blacklist with scripts we know they will fail on merge you can copy at least that blacklist. Nobody can handle that site by site and script by script. Blacklist field is key!!!

Our support desk had dozens of tickets today right after the update was deployed. It was performance is directly liked to that update.

When handling hundreds or thousands of sites it is NOT possible to handle script by script.

I guess that I didn’t consider a situation like yours (sorry about that), and I have added the ignore list back to the settings, however… site owners are supposed to have it empty and test the new settings after the update.

The new version allows for many of the scripts in the previous ignore lists, to be merged and deferred now, especially if using the dependencies field in case of deferred scripts causing undefined errors with inline code.

The new ignore list will import the previous FVM 2 lists back to the settings after the update, provided you are upgrading from FVM 2.

A few more settings have also been re-added, though merging scripts and CSS is still not going to be exactly the same as before.

If upgrading from FVM 2, it will now add the default recommended settings to the defer section as well, which is similar to what it was doing before:

/ajax.aspnetcdn.com/ajax/
/ajax.googleapis.com/ajax/libs/
/cdnjs.cloudflare.com/ajax/libs/
/stackpath.bootstrapcdn.com/bootstrap/
/wp-admin/
/wp-content/
/wp-includes/

It will ignore whatever you had on the ignore list.
And if you had the Skip deferring the jQuery library option enabled, it will add it to the files to be merged render blocking in the header.
Sites that had enabled the inline css option, will also work as before.

If you already upgraded to FVM 3.0.0 or FVM 3.0.1 the old settings have been deleted.
The upgrade routine only works for FVM 2 to FVM 3 upgrade, else for new installs, it will default to manually adding the scripts.

If needed, the default ignore list for javascript on FVM 2:

/IE9.js
/a.optnmstr.com/app/js/api.min.js
/assets/js/plugins/wp-enqueue/min/webfontloader.js
/assets/js/wcdrip-drip.js
/avada-ie9.js
/excanvas.js
/fusion-ie9.js
/html5.js
/html5shiv-printshiv.min.js
/html5shiv.js
/js/TweenMax.min.js
/js/mediaelement/
/mailchimp-for-wp/assets/js/third-party/placeholders.min.js
/pixelyoursite/js/public.js
/plugins/LayerSlider/static/layerslider/js/greensock.js
/plugins/elementor-pro/assets/js/frontend.min.js
/plugins/elementor/assets/js/common.min.js
/plugins/elementor/assets/js/frontend.min.js
/plugins/revslider/public/assets/js/jquery.themepunch.tools.min.js
/plugins/woocommerce-product-search/js/product-search.js
/respond.js
/respond.min.js
/selectivizr.js
/themes/Avada/assets/js/main.min.js
/themes/jupiter/assets/js/min/full-scripts
/themes/kalium/assets/js/main.min.js
/wp-includes/js/mediaelement/wp-mediaelement.min.js

—

I expect that you will still need to look into a few settings, but hopefully this will make it easier. Try it out first on a test site.

Thanks for the fast reaction.

The latest plugin has the problem, that it can’t process .js.php files (with correct http header!!!). PHP is not processed again. As many themes and plugins make use of that for their configurations in JS it’s still not really usable AND breaks hundreds of websites with standard WP themes and plugins installed.

This hasn’t anything to do with the header.

FVM tries to read the file from the disk first, and if the file doesn’t exist, it will fallback to an http request (wp_remote_get with a 7 second timeout).

If the HTTP request fails, that may be another issue… but give me an example, because I just tested it with a php file printing css code and it worked as usual.

What is the exact url for the asset?
What happens exactly?
It’s ignoring it, or it’s merging it wrongly, or what?

You can see that PHP code is included inside the generated minified JS files so about 60 -70 % off all WP websites we tried the upgrade on fail (see screenshot).

https://www.dropbox.com/s/wwdh50uxvlfsaw6/screenshot_95.png?dl=0

Thanks, was this true on the latest version as well?

What was the uri path of the php file you used?
I need to know to try and reproduce it.

I had code to fetch the files via http when it detects <?php but I have made some tweaks to it on the latest version.

However, The plugin also removes query strings from static assets, so I need to know the uri path and query strings used, so I can retest it.

Thanks and sorry about that.