cloudshift

You are right. We were able to fix it. Now everything seems to work like expected again. Thank yo very much for your help!

Thanks for the answer. The cache works but still the “x-cache-handler: cache-enabler-engine” is visible which was completely gone before. So still at least some PHP is processed, and we were not able to solve this so far.

I send you temp access to our websites. If it is too complicates we will stay on the old version 2. It used to worked perfectly an we had great scores and speed. There were never problems with php files too and it never touched the position of the jquery file. To be honest we still don’t get the intention of the update because the majority of our own and our clients websites now have massive problems and the scoring is way worse than it used to be.

Have a look at our main website. You can see the error on the console:

https://www.cloudshift.de

The latest version is installed right now and all caches have been cleared. I will recover the backup in about an hour to recover the website.

Second problem is that even if we add jquery to the ignore list it is now loaded in the header instead of the footer. The PSI score goes down in a very bad way. Why?

Unfortunately still no change on version 3.0.7. Still getting these “Uncaught SyntaxError: Unexpected token ‘<‘” in the console on nearly every website.

Yes, it happens on the latest versions too. Some files I’m we’re using for example are:

https://www.cloudshift.de/wp-content/themes/Atomic/js/app-atomic/app-atomic.js.php
or
https://www.cloudshift.de/wp-content/themes/Atomic/js/app-gsap/app-gsap.js.php

I think it’s within these resources the problems happens on aggregation or minifying.

Thanks again!!

After the latest update I get new Errors (see screenshot).

https://www.dropbox.com/s/svf08jbtlazgnsf/screenshot_17.png?dl=0

We’re testing on an internal server. The URL with the wrong JS file is: https://www.myserver.de/wp-content/cache/fvm/min/myserver.de/1609418930-85e1d64ff2813503ae6042205fbfdad20f976cd6.footer.min.js

If you need live access I have to set up a new test environment and make it accessible from the web.

Thanks for your help again and happy new year!

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

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.

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!!!

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!

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.

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!

Wow, great!!

I corrected it manually within the plugin and will contact the plugin owner for getting it corrected in further versions. Thanks so much!

Happy holidays to you!