WikiBugs/HtmlCache

The page cacheing code was obviously written under the plausible assumption that $UseCache would be constant for the life of a given wiki.

There are two cases where this causes a bug

1. When $UseCache is set to 1, then to 0, then pages that were changed during the uncached era revert to an obsolete form

1. When doing timing tests with two separate sets of wiki code on the one set of files you get odd results (which was how this was spotted)

Work-Around

Create a brand new page immediately after setting $UseCache back to 1. This has the side effect of completely flushing the cache (at least with the current code).

Poor Bug Fix

Remove the $UseCache tests from appropriate code so that the cache is always flushed after an edit, even with $UseCache=0. This is a poor fix as it will try to delete a cached page for every page in the system every time an edit occurs, with a probable performance hit.

Enhancing Bug Fix

As for the poor bug fix, but rewrite code to flush cache so that it only tries to delete files that actually exist. This will not take much time where no files exist, and will also enhance the performance in the cached case as a welcome side-effect.

If I have time I will post a fix as a Patch, but if it is not here by the end of Jan 2002 assume I didn't have time!

--RiVer

Actually, my assumption was that people would completely remove the cache and all of its files whenever they changed the $UseCache setting. (If they are enabling the cache, they should get rid of old files. If they are disabling the cache, they can get rid of the unused cache files.) The cache setting is not really meant for ordinary use as it has some known problems. The cache option remains in the code because it may be useful as a temporary measure under sudden high-load conditions (like a MeatBall:SlashDotting). If one expects continuous high loads, one should use a PersistentCGI solution like the Apache mod_perl module. --CliffordAdams