[2.8.9] wp cli command no more working?

If you are getting “Success: FVM and other caches were purged.” then the plugin is working fine. That message only shows up via wp cli, after it executes the cache purge.

What may be failing is the cache purge itself, for some reason.
However, the function to purge the cache is exactly the same as the one used on wp-admin.

When you say nothing is changing, do you mean your html is still cached and the cache file names have not been incremented?

If that is the case, then for some reason, the page cache purging is failing.
Do note, FVM doesn’t do page caching. It only supports a few hosting and cache plugins.

You may need to purge your page cache on your hosting or some other plugin you use, after you purge FVM, in order to see the differences.

Also please check your server php error logs for any errors.
And check if your php-cli is running the same version as the fpm or web version.

Thanks for the response and ideas.

More info about the situation to clear things up.

The HTML is correct, no caching issues here. I load two different versions of CSS for the same url, depending on a setting in the WP backend. Not sure if the cli command doesn‘t update the files or load the css for the older version of the page. After I flush it when logged into the WP site, the correct css is loading.

Is there a hook to update FVM files when a page is saved? I guess it has to do a hard reset to show the correct version of the styles.

Does the different version version of the css file for the same url, change name?
If not, it has to… else, if you are showing different css code with the same file url, things will get cached bot on the plugin or whathever cdn you may use.

FVM will detect all file names and make a hash out of it.
If a file name changes, if the order changes, if some file is new or some file is missing, it will create a different file cache.

But if a css file is different without changing the url, that won’t work.
It will just cache the first one and that first cache is reused for any subsequent requests of merging that file (by name, not content).

Is that what’s going on?

—

FVM file names change whenever you purge caches.
This is to bypass caches on cdn’s and user browsers.
Are your generated FVM file names changing after purging caches via wp-cli?
You need to check that, not logged in. That’s the point as logged in users don’t see fvm cached files.

Yes, the css files have different names. I add a custom field to the post and if this is activated, I load the other css styles.

So, the HTML is fine, shows the correct css classes but the other css styles are loaded. After I log in and click the FVM Purge link manually, everything is correct.

“Are your generated FVM file names changing after purging caches via wp-cli?
You need to check that, not logged in. That’s the point as logged in users don’t see fvm cached files.”

I need to debug this. Will monitor when its happening again and check the generated css file names.

There must be a problem with the generation of the CSS files.
The minified filenames are exactly the same but the CSS is different (after purging FVM cache)

old (wrong) css
https://XXXX/wp-content/uploads/cache/fvm/1595232293/out/header-d2aa1bc8d7804d09d333f41979ea647cec4e1114.min.css

new (correct) css after purging
https://XXXX/wp-content/uploads/cache/fvm/1595238495/out/header-d2aa1bc8d7804d09d333f41979ea647cec4e1114.min.css

Purging cache, is changing the directory, so it’s working.
It changed from 1595232293 to 1595238495 so it’s changing and it’s incremented.

The filename itself, will only change if the requirements change.
So if you have 10 css files with the same name in the same order, the name won’t change.
But if you go to a different page with 11 css files, or 9 css files, or with 10 but one of them has a different name, then the generated name will change.

I still don’t understand exactly what problem you are having.

Ah, I checked the filenames only. My bad!

The problem is: we are doing a re-design and upgrade single pages (there are hundreds to update manually because of new modules, etc.)

So we added a custom field (e.g. “redesign2020”) and activate it to load the new css files (different names). When we edit it (no fvm cache activated) everything works as expected. But as soon as the page is cached. It shows the old css instead of the new files. Only after purging again the correct css shows up. And after a couple of hours (or whatever changes the behaviour) the old CSS styles are shown and we have to manually flush again.

How are you enqueing the redesign2020 code and on which hook?

If you are purging the cache and it merges correctly, it should not go back to the previous.

I can understand if you are reusing file names, since that would be cached once and reused for other requests.

Did you check FVM status page for the generated files and to check which files are actually being merged? And are the files being merged correct?
The log file shows you both the path and file names it’s using.

I change the path on the wp_enqueue_style routine.

Thanks for the hint with the log.
I can see it uses the “old” css files to generate the merged css files.
As far as I can tell it’s when the page is saved and has no custom field activated (still old layout), the global css files will be with those styles.

Is this the desired behaviour by FVM?
Any way to get the correct styles for each page?

I think you are likely dequeueing the original and enqueueing the new file too late.
That’s why I asked which hook are you using.
Post the code you use to check if the a custom css file exists and how it’s being enqueued, and where.

Using wp_enqueue_style has to be done before the $wp_styles object is created.
We hook into it on wp_print_styles and also sometimes on style_loader_tag so if you are doing it later, then it won’t be there. That explains why it’s using the original, default file instead.

You need to check the order of hooks you are using.
https://rachievee.com/the-wordpress-hooks-firing-sequence/

Then check if the page has a css file earlier (the template redirect, or the loop is too late) and do the logic before the wp_enqueue_scripts hook.

The earliest hook for conditional tags is the wp hook.
I suggest, creating a function and hooking into it.
Then inside that function, you can check if it’s a page or post, fetch the meta info and dequeue/enqueue your css files.

• This reply was modified 4 years, 4 months ago by Raul P..

The hook is the following:
add_action('wp_enqueue_scripts', 'theme_basics_setup');

Inside the function I check for the custom field and change the path of the css file. Example:

$new_css = (get_field('redesign2020')) ? "2020" : "";

/* base styles */
wp_register_style('wp-fonts', $assets_path.'/css'.$new_css.'/fonts.css','','', 'screen' );
wp_enqueue_style('wp-fonts');

I can change the hook to “wp” or something different.

• This reply was modified 4 years, 4 months ago by phloo.

Okay, I think I found the cause for the CSS mixup.

When I purge the FVM Cache and visit a page without the new redesign files, the cache will be generated with those files and used globally. Without checking if a single page is loading another style set.

If I purge the FVM Cache and the first visit is a redesigned page, the files are generated as desired.

Looks like the plugin is not able to check for single pages, right? :/

The plugin checks every single page or url for different requirements.
You can have different cache files in every single page if it’s needed.

It’s explained in the faqs:
https://www.ads-software.com/plugins/fast-velocity-minify/faq/

As long as there is a different file, FVM will generate the new cache.

When I purge the FVM Cache and visit a page without the new redesign files, the cache will be generated with those files and used globally. Without checking if a single page is loading another style set.

The plugin is checking, always.
The issue is that, you are likely not enqueueing the overwriting files early enough, or
the filenames of your custom css files and the original css files are exactly the same, or
you use some sort of object cache that is caching the $wp_styles object.

If you use object cache, try to disable it and test.

If I purge the FVM Cache and the first visit is a redesigned page, the files are generated as desired.

I all comes down to what files are showing up in the logs.
FVM merges what it sees and saves it on the log.
If it doesn’t see anything different, it serves the same file that matches an equivalent same set of files.

If you have file a,b,c,d,e it will generate a cache file.
If you have file a,b,c,d,e,f,g it will be another
If you have a,b,g,k,x it will yet be another.

The key, is the combination of file names.
If any file name changes, or if it order changes, it has a unique hash key.
If it’s a new hash, it triggers a new cache file.
You will have as many as needed, per page.

You just need to figure out why is your new script, not on the $wp_styles object.

—

You need to post the whole theme_basics_setup function, else I cannot see what’s wrong.
And where are you putting the add_action('wp_enqueue_scripts', 'theme_basics_setup'); code? That should likely to go into the functions.php outside of any other hook.

First up, thanks for the explanation and help, really appreciated.

basic setup function
The add_action is in the theme’s default function.php and contains only enqueuing of scripts and styles, depending on pages, custom post types and plugin usage (forms).

names of css files
example old: fonts.css
example new: fonts2020.css
So they are different (also can be seen in the fvm logs)

object cache
The site is hosted at WPengine, so yes, there is an active caching system behind it. But flushing the cache via FVM/wp cli should also trigger the flushing of the object cache at WPE. It’s weird that the correctly written css files are overwritten after some time, hence some trigger is pushing the old css file paths instead of the new ones.

enqueing
In the theme functions.php I call the hook action:
add_action('wp', 'theme_basics_setup');

This function is loading another php file with only enqueue entries:

$assets_path = get_template_directory_uri()."/".basename(dirname(__FILE__));
$newcss = (get_field('redesign2020')) ? "2020" : "";

/* base styles */
wp_register_style('wp-fonts', $assets_path.'/css/fonts.css','','', 'screen' );
wp_register_style('wp-styles', $assets_path.'/css/app.css','','', 'screen' );
wp_register_style('responsive-styles', $assets_path.'/css/responsive'.$newcss.'.css','','', 'screen' );
/* layout */
wp_register_style('wp-layout-hero', $assets_path.'/css/layout/hero'.$newcss.'.css', '', '', 'screen');
wp_register_style('wp-layout-header', $assets_path.'/css/layout/header'.$newcss.'.css', '', '', 'screen');
wp_register_style('wp-layout-content', $assets_path.'/css/layout/content'.$newcss.'.css', '', '', 'screen');
wp_register_style('wp-layout-footer', $assets_path.'/css/layout/footer'.$newcss.'.css', '', '', 'screen');

wp_enqueue_style('wp-fonts');
wp_enqueue_style('wp-styles');
wp_enqueue_style('wp-layout-hero');
wp_enqueue_style('wp-layout-header');
wp_enqueue_style('wp-layout-content');
wp_enqueue_style('wp-layout-footer');

The get_field function is from the “Advanced Custom Fields” plugin. I would have guessed it may not be available when FVM checks what to merge but then again it merges the files correctly when I flush the cache manually.

I will try to figure out why it’s still not working.

Definately some problem with cli & wpengine
Here is the current test.

First: it reverted back to the old code again. Still no idea why this happens. The HTML code shows its a redesigned page, only the generated css files are wrong

Before purging:
https://www.xxxxxxxxxxxxx.com/wp-content/uploads/cache/fvm/1595313857/out/header-498bb607109d20c2a937936f4be405b507657e2a.min.css

After wp cli command (still old and wrong css)
Success: FVM and other caches were purged
https://www.xxxxxxxxxxxxx.com/wp-content/uploads/cache/fvm/1595330316/out/header-498bb607109d20c2a937936f4be405b507657e2a.min.css

After FVM purge from WordPress toolbar (new styles, correct view)
https://www.xxxxxxxxxxxxx.com/wp-content/uploads/cache/fvm/1595330456/out/header-498bb607109d20c2a937936f4be405b507657e2a.min.css