.wp-cli/cache files

[Franco]

Hello,
under each of my subscriptions I can find plenty of .zip files (older WP versions and plugins) under /.wp-cli/cache/. What are they and can they be removed safely? And if so, how to avoid those adding up over time?

I could not find any information online, thus I am asking here if somebody has any idea, please.

Running Plesk Onyx 17.5.3 on CentOs 7.

Regards
Franco

 

[virtubox]

Hello,
under each of my subscriptions I can find plenty of .zip files (older WP versions and plugins) under /.wp-cli/cache/. What are they and can they be removed safely? And if so, how to avoid those adding up over time?

I could not find any information online, thus I am asking here if somebody has any idea, please.

Running Plesk Onyx 17.5.3 on CentOs 7.

Regards
Franco

Hello,

WP-Tookit keep them in cache with an expiration date. It will remove them automatically.

You can disable cache by adding the following directives in your panel.ini file (with the panel.ini editor extension or directly in /usr/local/psa/admin/conf/panel.ini) :

[wpToolkit]
features.cacheDataByVersion = false

 

[Franco]

Hi, Thanks. Not sure whats thé expiration time as those files look quite old indeed (the value is 2592000). Anyway, I disabled it as per your indication.

Regards

 

[Franco]

Uhm, it does not seem to work, though. This morning another set of zip files were added
Here's what I have in the panel.ini:

Section Setting Value
[wpToolkit] features.cacheDataByVersion false ( default value: true )
[wpToolkit] features.cacheDataByVersionExpireTime 2592000
[wpToolkit] enabled true
[wpToolkit] features.checkUpdatesWhileInstall false
[wpToolkit] features.autoCheckSecurityApsInstances true
[wpToolkit] features.autoAttachApsInstances true
[whm] balancer dummy
[whm] enabled false
......

What could be wrong? Some sort of restart needed, perhaps?
Regards
Franco

 

[Aleksey Filatev]

Hello,

I regret that I miss your question and did not answer it in operative manner. The directory /var/www/vhosts/<domain_name>/.wp-cli/cache which you can see in your subscription's home is the part of WP-CLI caching mechnism. As you can see, WordPress Toolkit uses WP-CLI for managing themes and plugins. This themes and plugins downloaded from the public catalog at wordpress.org and cached in your subscription. It is just an performance improvemnt in case, for example, if you want to install the same plugin on several instances simultaneosly. It will be downloaded just once in that case. You can safely remove .wp-cli directory, nothing bad happens. It will be created automatically if needed.

What's about option "cacheDataByVersion" (for Plesk 17.0 and above it should be specified without prefix "features." in section "[ext-wp-toolkit]"), it is a legacy option, quite useless for the moment. If this option is "true", data of WordPress instances, installed via applications catalog, will be cached and used from cache while next installation from the same package. It could slightly increase the speed of WordPress installation via application catalog. Modern WordPress Toolkit not use applications catalog while installing WordPress.

 

[gbotica]

Hi all,

I also have lots of files building up in subscription's .../.wp-cli/cache/. I have checked my panel.ini and I have:

[ext-wp-toolkit]
cacheDataByVersion = true
cacheDataByVersionExpireTime = ‪604800‬

However, I have many files in .wp-cli/cache that are older than 7 days, so it appears that this is not working?

As a test, I have deleted all files and reduced the cache time to 2 days:

rm -frv /var/www/vhosts/*/.wp-cli/cache/*
cacheDataByVersionExpireTime = ‪172800‬

So, I'll see if it starts working correctly. I also note that:

plesk ext wp-toolkit --clear-cache -instance-id 1

Does not seem to work either, I assume this is supposed to clear the instances .wp-cli/cache?

 

[Aleksey Filatev]

Chache files stored at /var/www/vhosts/*/.wp-cli/cache/* are artifacts of WP-CLI utility which used by WordPress Toolkit to interact with WordPress instances. You can find more details at Question - .wp-cli/cache files.

Regarding an option cacheDataByVersion, it's legacy and useless for now (see details at the link above).

CLI command plesk ext wp-toolkit --clear-cache -instance-id 1 do the same (almost) as Refresh button on the instance details page: refresh inctance properties (settings, list of installed themes and plugins, etc.), cached at the toolkit side.

 

[gbotica]

@Aleksey Filatev Thank you for your input.

I didn't quite understand your earlier message, I thought you were saying that the 'features' setting prefix and the ini header [wpToolkit] was legacy.

So, if 'cacheDataByVersionExpireTime' and 'cacheDataByVersion' have no effect, then these .wp-cli cache directories will grow in size until manually removed? That's not very good.

I guess I'll have to use a cron job to empty out the /.wp-cli directories then

 

[Aleksey Filatev]

Thank you for feedback! I just created an issue EXTWPTOOLK-2163. I belive we can automate clean up of the WP-CLI cached data in future releases of WordPress Toolkit.

 

[Bobbbb]

Is this issue (EXTWPTOOLK-2163) still open? I also have large .wp-cli/cache directories that put customers over their allowed disk quota. What is the solution? I'm using Plesk Onyx Version 17.8.11 Update #83 on CentOS Linux 7.7.

 

[gbotica]

I thought I saw a changelog from WP Toolkit saying this was fixed, but I haven't tested. I've been using a cron job to empty the customer's directories as a workaround:

0 45 1 * * root rm -frv /var/www/vhosts/*/.wp-cli/cache/*

 

[custer]

@Bobbbb, @gbotica

Well, this is going to be awkward...

The issue was technically fixed in the WPT 4.2.0 release. Here's the corresponding line from the release notes:

[*] WordPress Toolkit was finally shamed into regularly cleaning up wp-cli utility cache on a per-site basis.

Problem is, we've shipped the code that fixes the issue, but we forgot to enable it (yes, you've read that right). I know what you're thinking (I can hear you facepalming from here), but let's focus on what can be done with this conundrum right now.

Due to technical limitations of spacetime continuum I cannot travel back in time and enable this feature at the point of WPT 4.2.0 release. However, I can do things right now -- and to be more specific, I've started the feature rollout process 30 minutes ago. In five days, all WPT installations will have this feature up and running. If you don't want to wait for the rollout to reach you (the server selection lottery is random), let me know and I'll tell you how to enable this change immediately.

Sorry for the embarassing hold up, guys. Better late than never, right?