better hdd cache invalidation

[Syberspace]

Assume _cachify_remove_post_type_cache_on_update is set to 1 (only clear page cache) for the current user.
This pull fixes the issue that _clear_dir deletes everything that's heirarchically below the post that is being saved.

This problem would also happen for any other hierarchical post type where any parent also invalidates all it's children's cache.
The tradeoff with my implementation is that one might find orphaned directories in their cache directory.
For example saving the page with permalink /test/ would leave an empty directory of cache/cachify/<hostname>/test/

The other caching methods might need a similar fix, I haven't checked those out.

[websupporter]

Hi @Syberspace,
thanks a lot for your input. I want to have a closer look into your commit and think about it. But give me a bit time (~ 1 week or so), because right now, I am a bit busy and I know most people of the team are (trying to release a new Antispam Bee version).

Thanks again, sorry if it takes some days until I have a closer look.

[websupporter]

Hi @Syberspace,
I played a bit with your PR. As you have mentioned, the tradeoff would be the possibility of orphaned directories, for example, in case I rename the post slug of the level 1 post. Lets say, you have
/level-1/level-2/ and you rename level-1 to parent, you basically create a second directory, where the cache searches for the "level-2"-page and creates a new cached page, if not found. In this case the benefit of your PR gets lost and we just get orphaned directories, until we clear the complete cache again. Since, we can still clear the whole cache, I think, your approach is interesting and renaming the slug an edge case.

But maybe, do you have an idea on how to detect orphaned directories while clearing a directory non-recursivly? This would be an awesome advancement, I think.

[Syberspace]

Maybe it would be possible to set up a wp cron for every directory that is to be deleted using url_to_postid. Anything that returns no postid could be safely deleted.

The reason for using wp cron is to keep the user's workflow uninterrupted if scanning a directory recursively has a negative impact on performance. If the $timestamp is set to time() the cron will run right away. It would also fail "gracefully" if by any chance the php max execution time is reached.

[bueltge]

The code is fine, but please note the codex, a blank after a ( , also before closing bracket ), also after the if, before the open bracket if (.

[websupporter]

The cron is a good idea. I think for now, it works fine and we can merge it, since it is a very nice enhancement. If we run into problems, we can consider a cron or another method to clean up. Thank you again for this thoughtful PR!

[Syberspace]

@bueltge thanks for the hint about formatting. should i update this pull to fix the formatting or are you gonna do that when you merge?

[bueltge]

@Syberspace yes, please a small update of this request, the fastest ways to solve this. Thanks a lot.

[websupporter]

@Syberspace
thanks for your contribution. Really appreciated 😃