Title: [2.8.9] wp cli command no more working?
Last modified: July 17, 2020

---

# [2.8.9] wp cli command no more working?

 *  Resolved [phloo](https://wordpress.org/support/users/phloo/)
 * (@phloo)
 * [5 years, 10 months ago](https://wordpress.org/support/topic/2-8-9-wp-cli-command-no-more-working/)
 * To update my site I use the wp cli command to flush the FVM cache
    In return 
   I get “Success: FVM and other caches were purged.” But nothing is really changed,
   instead I have to login to the site and manually flush the FVM cache via the 
   toolbar.

Viewing 15 replies - 1 through 15 (of 19 total)

1 [2](https://wordpress.org/support/topic/2-8-9-wp-cli-command-no-more-working/page/2/?output_format=md)
[→](https://wordpress.org/support/topic/2-8-9-wp-cli-command-no-more-working/page/2/?output_format=md)

 *  Plugin Author [Raul P.](https://wordpress.org/support/users/alignak/)
 * (@alignak)
 * [5 years, 10 months ago](https://wordpress.org/support/topic/2-8-9-wp-cli-command-no-more-working/#post-13136796)
 * 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.
 *  Thread Starter [phloo](https://wordpress.org/support/users/phloo/)
 * (@phloo)
 * [5 years, 10 months ago](https://wordpress.org/support/topic/2-8-9-wp-cli-command-no-more-working/#post-13136953)
 * 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.
 *  Plugin Author [Raul P.](https://wordpress.org/support/users/alignak/)
 * (@alignak)
 * [5 years, 10 months ago](https://wordpress.org/support/topic/2-8-9-wp-cli-command-no-more-working/#post-13137105)
 * 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.
 *  Thread Starter [phloo](https://wordpress.org/support/users/phloo/)
 * (@phloo)
 * [5 years, 10 months ago](https://wordpress.org/support/topic/2-8-9-wp-cli-command-no-more-working/#post-13138844)
 * 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.
 *  Thread Starter [phloo](https://wordpress.org/support/users/phloo/)
 * (@phloo)
 * [5 years, 10 months ago](https://wordpress.org/support/topic/2-8-9-wp-cli-command-no-more-working/#post-13144430)
 * 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](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](https://XXXX/wp-content/uploads/cache/fvm/1595238495/out/header-d2aa1bc8d7804d09d333f41979ea647cec4e1114.min.css)
 *  Plugin Author [Raul P.](https://wordpress.org/support/users/alignak/)
 * (@alignak)
 * [5 years, 10 months ago](https://wordpress.org/support/topic/2-8-9-wp-cli-command-no-more-working/#post-13144451)
 * 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.
 *  Thread Starter [phloo](https://wordpress.org/support/users/phloo/)
 * (@phloo)
 * [5 years, 10 months ago](https://wordpress.org/support/topic/2-8-9-wp-cli-command-no-more-working/#post-13144468)
 * 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.
 *  Plugin Author [Raul P.](https://wordpress.org/support/users/alignak/)
 * (@alignak)
 * [5 years, 10 months ago](https://wordpress.org/support/topic/2-8-9-wp-cli-command-no-more-working/#post-13144486)
 * 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.
 *  Thread Starter [phloo](https://wordpress.org/support/users/phloo/)
 * (@phloo)
 * [5 years, 10 months ago](https://wordpress.org/support/topic/2-8-9-wp-cli-command-no-more-working/#post-13144523)
 * 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?
 *  Plugin Author [Raul P.](https://wordpress.org/support/users/alignak/)
 * (@alignak)
 * [5 years, 10 months ago](https://wordpress.org/support/topic/2-8-9-wp-cli-command-no-more-working/#post-13144577)
 * 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.
    `http://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 5 years, 10 months ago by [Raul P.](https://wordpress.org/support/users/alignak/).
 *  Thread Starter [phloo](https://wordpress.org/support/users/phloo/)
 * (@phloo)
 * [5 years, 10 months ago](https://wordpress.org/support/topic/2-8-9-wp-cli-command-no-more-working/#post-13144631)
 * 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 5 years, 10 months ago by [phloo](https://wordpress.org/support/users/phloo/).
 *  Thread Starter [phloo](https://wordpress.org/support/users/phloo/)
 * (@phloo)
 * [5 years, 10 months ago](https://wordpress.org/support/topic/2-8-9-wp-cli-command-no-more-working/#post-13144738)
 * 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? :/
 *  Plugin Author [Raul P.](https://wordpress.org/support/users/alignak/)
 * (@alignak)
 * [5 years, 10 months ago](https://wordpress.org/support/topic/2-8-9-wp-cli-command-no-more-working/#post-13145430)
 * 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://wordpress.org/plugins/fast-velocity-minify/faq/](https://wordpress.org/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.
 *  Thread Starter [phloo](https://wordpress.org/support/users/phloo/)
 * (@phloo)
 * [5 years, 10 months ago](https://wordpress.org/support/topic/2-8-9-wp-cli-command-no-more-working/#post-13146212)
 * 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.
 *  Thread Starter [phloo](https://wordpress.org/support/users/phloo/)
 * (@phloo)
 * [5 years, 9 months ago](https://wordpress.org/support/topic/2-8-9-wp-cli-command-no-more-working/#post-13149959)
 * 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`

Viewing 15 replies - 1 through 15 (of 19 total)

1 [2](https://wordpress.org/support/topic/2-8-9-wp-cli-command-no-more-working/page/2/?output_format=md)
[→](https://wordpress.org/support/topic/2-8-9-wp-cli-command-no-more-working/page/2/?output_format=md)

The topic ‘[2.8.9] wp cli command no more working?’ is closed to new replies.

 * ![](https://ps.w.org/fast-velocity-minify/assets/icon-128x128.jpg?rev=1440946)
 * [Fast Velocity Minify](https://wordpress.org/plugins/fast-velocity-minify/)
 * [Support Threads](https://wordpress.org/support/plugin/fast-velocity-minify/)
 * [Active Topics](https://wordpress.org/support/plugin/fast-velocity-minify/active/)
 * [Unresolved Topics](https://wordpress.org/support/plugin/fast-velocity-minify/unresolved/)
 * [Reviews](https://wordpress.org/support/plugin/fast-velocity-minify/reviews/)

 * 19 replies
 * 2 participants
 * Last reply from: [phloo](https://wordpress.org/support/users/phloo/)
 * Last activity: [5 years, 9 months ago](https://wordpress.org/support/topic/2-8-9-wp-cli-command-no-more-working/page/2/#post-13151487)
 * Status: resolved