Skip to content

[5.x] Fix files not being removed after cache has been cleared #11873

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Conversation

indykoning
Copy link
Contributor

@indykoning indykoning commented Jun 16, 2025

This PR fixes the issue where url invalidation will no longer function after the cache has been cleared.
This is especially an issue when a cron is run that clears the application cache every so often.
When that happens the url cache keys will be removed, any kind of invalidation will no longer function.

This PR will use the recursiveDirectoryIterator functions to efficiently remove these files from disk if there are still some left over that were not in application cache.
Due to it being an iterator it's light on memory

Note: We could completely move to file based clearing instead of application cache. But for completeness, to keep other parts that might be watching the application cache in the loop i've decided to keep that as-is

@indykoning indykoning changed the title [5.x ] Fix files not being removed after cache has been cleared [5.x] Fix files not being removed after cache has been cleared Jun 16, 2025
@duncanmcclean
Copy link
Member

Are you able to add a test for this? It can be added to FileCacherTest.

@indykoning
Copy link
Contributor Author

I've added tests, only windows seems to fail.
I think it has to do with the different path separators on windows but i do not have access to a windows machine.
Could you assist in updating the test to work for windows as well?

@duncanmcclean
Copy link
Member

No problem - we can handle that, thanks!

@jasonvarga
Copy link
Member

What you had was working on Windows, but the assertions weren't.

There were inconsistencies with the directory separators.
e.g. getFilePath would return something like /path/to/foo.html but the writer used a path like /path/to\foo.html. The right file was actually deleted, but since mockery cared about the literal string passed to the method, it was failing.

@indykoning
Copy link
Contributor Author

Thank you! 🚀 I expected something like that considering it's the only part checking a full file path instead of checking a virtual one

@jasonvarga jasonvarga merged commit 98d90c4 into statamic:5.x Jun 19, 2025
24 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants