Raul P.

Can you post your code, how you are enqueueing the css and js files?
Are you doing this on your theme, or custom plugin?
If custom plugin, are you using ob_start or similar functions?
What is the source code on the html after enqueuing?
Thanks

Are the files generated matching the domain?
CSS or JS files?

Can you post the exact url with query strings, where FVM is not working?

Note that FVM will still ignore the page, if there are any other query strings, so you would need to add any other query strings shown up there.

Additionally, if the content is being returned via AJAX it will also ignore that, but let me know the url so I can take a quick look.

Those fields appear to be from version 2, so pretty old.
On v3 simply deactivate and delete via wp-admin.

If there are v2 leftovers, run via phpmyadmin or your database tool.
Please backup first, of course.

DELETE FROM wp_options WHERE option_name = 'fvm_settings';
DELETE FROM wp_options WHERE option_name = 'fvm_last_cache_update';
DELETE FROM wp_options WHERE option_name LIKE 'fastvelocity%' OR option_name LIKE 'fvm-%'
DROP TABLE IF EXISTS wp_fvm_cache;
DROP TABLE IF EXISTS wp_fvm_logs;

Replace wp_ with your tables prefix.

Thanks for the info. I believe the new update should be working for you. Thanks

Hi,

When you clear everything, even if the files were not purged physically, the new cache file names should still change (view html source) so cache should be busted and redone from scratch again.

Can you please confirm that the file names are changing after purging, and that the problem is that the old ones are just not being deleted?

Or are you for example, editing a css or js file and FVM is not updating the code when you purge, but is it still regenerating the new named cache files?

Deactivating and Activating deletes the database table, and recreates it. It also calls the cache purge to clear the cache files, but it’s the same exact function.

Maybe the purge everything option is no longer purging the database table… I need to look into it and get back to you later.

The function is there and every time a cache purge runs, it’s supposed to delete anything older than a certain date.

For 2020 files, I can only speculate if the file ownership is incorrect, or something else so it didn’t have permission to delete them.

But if you are still seeing months old cache files in the future, please let me know again. Thanks

@davidfonsbo not sure if the latest 3.2.5 version works for you (I made new changes), but I did not find any critical error on any dev site. If you have access to logs on the server, there should be a more detailed reason. Thanks

@freeduke sorry about that, but please always test (any) plugin before updating.
@saddeveloper the information you have provided was very helpful, thanks a lot. I believe v3.2.5 should work now for your environment type.

Yes, as I said I will rename that on the next release, but ideally others should rename it too, that is what I said. My next release is a few hours away. Thanks

@insomnia88 @davidfonsbo @adamjonfuller

For cache related issues with the update, please refer to the instructions I provider below, to debug the issues.

https://www.ads-software.com/support/topic/v-3-2-4-combined-url-not-found/

The error says, /wp-content/plugins/responsive-lightbox/ so please contact that plugin author.

I will rename the “simple_html_dom” class on my end too for the next release, to prevent same name conflicts, but they should do it too, or check if it already exists before adding it again.

In this case, I am using that on my plugin so it get’s defined.
Later, their plugin is trying to repeat that and it fails, because it already exists.
They should check if it already exists, before adding it again.

If you are seeing <link rel="stylesheet" href="combined" media="all" /> I just tested and I can confirm, this happens when there are no write permissions on the cache directory. Please ensure the /wp-content/cache/ directory exists and it’s writeable by the PHP user.

If it’s not this, then it seems to me, that your server has some cache that needs to be purged, or maybe some file disk permissions, but can you please check the following.

a) Purge Minified CSS/JS files instantly – is disabled

b) the directory under /wp-content/cache/ exists, and it’s writeable.

c) you have purged the cache on FVM, followed by any other cache plugin or your hosting cache (you may need to log in to their control panel, depending on your provider)

d) open chrome in incognito mode, then “view source” and check what is the name of the combined css file name, and it’s location. Note the first digits on the file name. It should look like this: https://yoursite.com/wp-content/cache/fvm/min/1643713442-css415aa84a8178f2faa1874f311cf5818bebda56ed4448886c2af4fbba57038.css

e) visit the url and see if it opens or returns a 404 error. if it shows 404, check on the /wp-content/cache/fvm/min/ directory (some file manager, sftp, hosting, etc) if the file actually exists and it just doesn’t open, or if it doesn’t exist.

—

Now, if the file exists but it returns a 404, something is wrong because the server is blocking the file from showing. If it does not physically exist, keep reading.

—

f) Purge everything on FVM, via wp-admin top admin bar, FVM > Purge All

g) refresh the incognito chrome window and view source again. Then compare the css file name, specifically, the first digits to see if it’s the same, or if it has changed.
Note that the filename digits, are supposed to change whenever you purge FVM cache.

—

If you are here, then there are two possibilities.

1) If the number on the css file name did not change after purging FVM, that means you are seeing a cached version of your html page, so naturally, it’s still pointing to an older file that may or may not be deleted.

This means, FVM is not capable of clearing the page cache either for some other cache plugin that is in use, or for your hosting caching, or perhaps some other third party cache like cloudflare APO for example.

This would also cause your “css files to disappear”, though what happened there, is the fvm cache was purged after the upgrade but the page cache is still pointing to the old files, now deleted.

Purge Minified CSS/JS files instantly, option can be disabled and cache files will be preserved for 7 days. This allows for any third party caches to expire, provided their expire date is not longer than 7 days. Most hosts have this set to 15 minutes or so, so this is enough.

2) If the digits on the file name changed after purging FVM, check if the file opens on the browser. If it returns 404, and if the file still doesn’t exist physically, then it means the plugin is not able to save the file on the cache directory.

In that case, I need to know.

Does your wp-config.php configuration require you to use ftp credentials to be able to write files, or are you perhaps using something like the s3 offload plugin, which uploads files to amazon s3 instead of allowing files to be written to the server?

—

The PHP Fatal error is caused by a core file, that is included on the plugin to allow writing of the cache files. This file however, no longer exists on the latest version update, so it shouldn’t be showing.

Please take note of your settings, try to delete the plugin and reinstall again.

Sometimes servers and certain hosting providers have object cache enabled, or file storage cache… and what this does is to cache code execution in memory to speed things up, so there is a possibility sometimes right after the update, the server is still processing code from the previous version even if the files are already different.

Object cache, as well as any other file cache system should be purged, anytime you do an update, being that a wordpress core update, theme or any other plugin.

Most hosting providers that have page caching, have a place where you can go and purge everything, but in doubt, please ask your hosting about cache purging.

—

I just retested yet again, reinstalling a fresh WP 5.9 with PHP 8 on 2 different providers, installed FVM, enabled css merging, and it’s working properly.

My wordpress files have the same permissions and ownership as the php user (the most common setup), so wordpress can write files directly. It does not require ftp credentials or anything else.

If you run PHP as a different user than the files owership, perhaps that could be the reason… but untested on my end, so please let me know.

Hope this helps.

And what was the error log or message exactly? I am not seeing any error on the update routines here. Maybe you needed to purge the object caching or something, or maybe the update failed for some other reason, or maybe some other plugin.

No error: https://youtu.be/07EAN6EQg1g

This was added. Thanks