• The changes made to add ‘http’ vs. ‘https’ support appear to have resulted in breaking this plugin pretty badly. Files aren’t being deleted any more when comments are posted so most users are getting stale content.

    IMO, this is indicative of a more serious problem that is only going to propagate itself and you need to nip it in the bud right now before it gets a lot worse and this plugin becomes severely unwieldy to manage. Creating lots of directory entries based on metadata of the request is the wrong approach. When someone goes to post a comment, how are you going to know which files to remove from the cache? You can’t if you are using metadata in the paths. Adding ‘http’ and ‘https’ to the paths was a bad move. Put ALL files for the same cache entry in the same directory so you can simply do an opendir()/readdir()/unlink()/closedir() on all files in the current cache directory and know that you successfully wiped all relevant files. A better approach would be to do:

    http.index.html
    http.index.html.gz
    https.index.html
    https.index.html.gz

    Or something similar if you really need to differentiate the protocol used. It will simplify your rewrite rules too. And it also starts you down the right path of better supporting mobile themes.

Viewing 4 replies - 1 through 4 (of 4 total)
  • Good idea. The current code is supposed to cycle through the directories but this does make it easier. Thanks. Now, got a code patch? ??

    I converted almost all the bits of code that I needed so that the filenames would have the identifying string instead of a directory when I realised that when checking the supercache/hostname/ directory the plugin will have to use a known list of files. It’s not good enough opening that directory with opendir() because a blog may have a flat permalink structure with thousands of directories when they’re all cached.

    I had to go back and create a function similar to the one that returns an array of directories. This one returns an array of index.html variants to check or delete.

    Pity, because I had a nice opendir() loop that would delete/check index*.html.gz etc…

    Thread Starter bigsite

    (@bigsite)

    Let me know when your code is in the latest devel download and we’ll give it a go in our production environment. We’re using a hack (cron job) at the moment, that I’d love to get rid of, that completely wipes all files in the cache every fifteen minutes.

    I checked the code in but I’m not sure if you should be running it on a mission critical site. It works on my personal site but try it on a dev site first!

Viewing 4 replies - 1 through 4 (of 4 total)
  • The topic ‘[Plugin: WP Super Cache] Latest devel version not working’ is closed to new replies.