Issue
On a large, busy forum, wpForo’s file cache under {cache_dir}/item/post regularly exceeds 1000 files. Cache::check() then deletes every file in that directory on the same frontend request.
That runs from wp_footer → WPF()->cache->create() when the template is forum (forum index). After the wipe, traffic rebuilds the files, the folder hits 1000 again, and the wipe repeats (for us, every few minutes). PHP CPU spikes and the cache is not useful.
We have thousands of posts. Each cached post is its own file ({postid}_{locale}). A 1000-file cap is far below our working set. There is no setting or filter to change it.
This is still present in 3.1.5. classes/Cache.php check():
Page cache (WP Rocket etc.) is not in use on the forum; this is only wpForo’s on-disk cache.
Request
Please make the limit filterable, default 1000, pass $directory, and treat 0 as never wipe:
That stays backward compatible. Large forums can raise the cap or disable the wipe without forking the plugin.
Optional follow-up
Counting the directory with FilesystemIterator on every forum-index request is expensive once the folder is large, even if you never delete. A throttle (e.g. at most once per N minutes) would help. Full-directory unlink is also harsh vs deleting oldest files; the filter is the minimum we need please.
We have modified the check function to skip the file count function calls entirely when the max is set to 0 this avoids expensive CPU calls to count large directories which will not be cleared anyway.
public function check( $directory ) {
$directory = (string) $directory;
$directory = wpforo_fix_dir_sep( $directory );
$filecount = 0;
$max = (int) apply_filters( 'wpforo_cache_dir_max_files', 1000, $directory );
if($max === 0) {
return;
}
if( class_exists( 'FilesystemIterator' ) && is_dir( $directory ) ) {
$fi = new FilesystemIterator( $directory, FilesystemIterator::SKIP_DOTS );
$filecount = iterator_count( $fi );
}
if( ! $filecount ) {
$directory_ns = trim( $directory, DIRECTORY_SEPARATOR ) . DIRECTORY_SEPARATOR . '*';
$directory_ws = DIRECTORY_SEPARATOR . trim( $directory, DIRECTORY_SEPARATOR ) . DIRECTORY_SEPARATOR . '*';
$files = glob( $directory_ns );
if( empty( $files ) ) $files = glob( $directory_ws );
$filecount = count( $files );
}
if ( $filecount > $max ) {
$this->clean_files( $directory );
}
}
Filter Used:
add_filter( 'wpforo_cache_dir_max_files', fn() => 0 );
Hi @sc89me,
Thank you for sharing this issue. We'll fix this in the next version release. It'll change the max file number dynamically based on the forum activity and also we'll add filter hook to set a custom value.
Hi Robert,
Appreciate that thanks,
Will you please still include a skip (early return) of the function if set to infinite?
When we initially didn't return early and still allowed those file count calls to happen it was heavily loading the CPU because we hit periods of 50 - 100 views per second at peak times which caused those to happen per view.
@robert we made some further changes because of performance issues we found, is it possible to have these also added to the next version? I have included a list of these changes and the reasons why we made them, I have also attached the Cache.php should you wish to take a look directly at the file.
(can't upload .php files)
These are the 2 filters we have set for these changes:
add_filter( 'wpforo_cache_dir_max_files', fn() => 0 );
// Cache trash cleanup runs from the prod cron against EFS (~1,100 deletes per 20s), allow longer runs so a full clear doesn't take hours.
add_filter( 'wpforo_cache_trash_time_limit', fn() => 120 );
# wpForo 3.0.5: requested changes to `classes/Cache.php`
We run wpForo on three load-balanced PHP pods that share one cache folder on a network filesystem (AWS EFS/NFS). There are two problems with how `Cache` deletes files. We've patched both locally and would like the changes, or equivalent ones, added upstream so plugin updates don't overwrite them. The full diff against stock 3.0.5 is in `wpforo-cache.patch`.
---
## Change 1 (sent before): `wpforo_cache_dir_max_files` filter in `Cache::check()`
**Problem:** `check()` counts the files in a cache folder on every cache write and clears the folder once it holds more than a fixed 1000 files. On a network filesystem, counting and clearing are both slow, and a busy forum goes over 1000 files all the time.
**Change:** the limit can now be changed with a filter, and a value of `0` skips the count altogether:
$max = (int) apply_filters( 'wpforo_cache_dir_max_files', 1000, $directory ); if( $max === 0 ) return; // ...existing count... if( $filecount > $max ) $this->clean_files( $directory );
With the default of 1000, behaviour is the same as before.
---
## Change 2 (new): `Cache::clean_files()` renames the folder instead of deleting each file
**Problem:** A new topic, a post, or a moderator approving a topic calls `wpforo_clean_cache()`. That calls `Cache::clean()`, which calls `clean_files()` on `forum/`, `topic/` and `post/`. `clean_files()` globs the folder and then runs `is_dir()`, `file_exists()` and `unlink()` on every file. On NFS/EFS each of those calls is a network round trip. With about 1,200 files, the user's save request is blocked for 20–24 seconds. Our php-fpm slowlog showed those saves stuck in `Cache::clean_files() → unlink()`, which caused 502s at the load balancer. The `wpforo_cache_*` filters don't help here: they only control the item caches, and these folders are cleared by the global cache setting alone.
**Change:**
1. `clean_files()` first calls a new private method, `swap_dir()`. It renames the folder to `<folder>.old-<unix time>-<8 hex chars>`, for example `post.old-1790670666-3fa91c0e`. It then recreates the folder empty using the existing `mkdir()`, which also writes `index.html` and `.htaccess`. A rename is a single operation however many files the folder holds, so the request finishes in milliseconds.
2. `swap_dir()` schedules a one-off WP-Cron event, `wpforo_cache_trash_cleanup`, 60 seconds later, if one isn't already scheduled. The event's only argument is the cache root.
3. The cron callback `Cache::cleanup_trash()`:
- finds `*.old-*` folders in the cache root and in `item/`
- deletes each one recursively, within a time limit (20 seconds by default)
- skips folders renamed less than 60 seconds ago, so requests still writing into them can finish
- reschedules itself if anything is left
4. If the rename fails, or the new filter turns it off, `clean_files()` falls back to the original per-file delete, unchanged.
Nothing that reads the cache sees the renamed folders: every cache path is built from `$this->dir . '/<template>/'`. If a request writes a cache file between the rename and the re-create, `wpforo_write_file()` already recreates a missing folder, so the write doesn't fail.
**New hooks:**
| Hook | Type | Default | Purpose |
|------------|-----------|--------------|---------------|
| `wpforo_cache_clean_deferred` | filter `( bool $enabled, string $directory )` | `true` | Return `false` to keep the original per-file delete (for example on sites with no working WP-Cron). |
| `wpforo_cache_trash_time_limit` | filter `( int $seconds )` | `20` | How long one cron run spends deleting before it reschedules itself. |
| `wpforo_cache_trash_cleanup` | action (WP-Cron event) `( string $cache_root )` | — | The background deletion job. |
**Safety of the cleanup job:**
- It only deletes folders whose names match `/\.old-(\d+)(-[A-Za-z0-9]+)?$/`, directly inside the cache root or `item/`.
- It doesn't follow symlinks.
- It ignores errors from files that are still open (NFS "silly rename" `.nfsXXXX` files) and retries on its next run.
---
## Diff
- three new `use` statements
- the `wpforo_cache_trash_cleanup` hook registered in the constructor
- one line added at the top of `clean_files()`
- four new methods after `clean_files()`: `swap_dir()`, `schedule_trash_cleanup()`, `cleanup_trash()`, `delete_dir()`
- the `check()` change from Change 1