• Resolved kieronboz

    (@kieronboz)


    Whenever I browse to a page, view its source, and look for the super cache output at the bottom and the timestamp, that time is always just whenever I load the page.

    I have adjusted garbage collection to be high, I dont have the setting to update on post/publish checked.

    I can see a few instances of this on google + this forum, but never a concrete solution.

    Thanks!

    The page I need help with: [log in to see the link]

Viewing 12 replies - 1 through 12 (of 12 total)
  • Thread Starter kieronboz

    (@kieronboz)

    To clarify, I just visited the homepage now, and the page source has this time (which is now, as of typing):

    <!– Dynamic page generated in 0.407 seconds. –><!– Cached page generated by WP-Super-Cache on 2024-07-08 10:04:27 –>
    <!– super cache –>

    Plugin Author Donncha O Caoimh (a11n)

    (@donncha)

    It looks like caching isn’t working correctly, but there’s a way you can investigate.

    Go to the Debug settings page and enable the logging there. You may see errors there related to writing the cache files, but normally you’ll see something like the following for anonymous visits to the front page of your site:

    / Output buffer callback
    / Anonymous user detected. Only creating Supercache file.
    / Writing non-gzipped buffer to supercache file.
    / Renamed temp supercache file to ABSPATH/wp-content/cache/supercache/example.com/index-https.html
    / Sending buffer to browser
    / wp_cache_shutdown_callback: collecting meta data.
    / Did not write meta file: meta-wp-cache-123456.php

    When a page is cached you should see a couple of lines, and then this line means the page was served, at least to an anonymous user, not a logged in user:

    / Fetched static page data from supercache file using PHP. File: ABSPATH/wp-content/cache/supercache/example.com/index-https.html

    I’m not sure what errors you’ll find, but hopefully, they help you figure out what is stopping the cache from working.

    Thread Starter kieronboz

    (@kieronboz)

    Thanks, I am looking for the link to view the logs, https://jetpack.com/support/wp-super-cache/enabling-the-debug-mode/ this says find the link that says “Login to the debugger, by clicking this link” – but where should this be?

    If I click the line that says “Currently logging to: blah5235235blah.php” it simply downloads a PHP file?

    Thanks!

    Plugin Author Donncha O Caoimh (a11n)

    (@donncha)

    The blah5235235blah.php text is a link, open that in a new tab after copying the “Username/Password” below it. It shouldn’t download. It’s just another php script that should be executed by your server.

    What operating systems are you using? What webserver? Do you have extra security modules installed to limit how PHP writes or runs scripts on your site?

    Are you using “expert mode”? If you are, try simple mode. If you continue to have problems, it might be worth completely uninstalling the plugin and installing it again (or delete wp-content/wp-cache-config.php if you have permission to do so) to reset the configuration. Then, enable caching from the Easy settings page and see if that works.

    Plugin Author Donncha O Caoimh (a11n)

    (@donncha)

    You could also look in wp-content/cache/ and you’ll see the debug log .php file there. One is a viewer script, and the logs are in a bigger file. You could download them to your computer if you have problems looking at the logs.

    You should take a look in wp-content/cache/supercache/ for the actual cache files. See if the pages are being cached in sub directories there. If they are, then there’s something up with the code that serves them to visitors, as that code should normally find those files. I don’t think it’s a bug, it’s something different about your server that the code isn’t expecting.

    Thread Starter kieronboz

    (@kieronboz)

    Thanks, I just opened that php file to reveal everything, I can see a lot of this and the problem becomes obvious!

    13:21:21 1474019 /?lottery-cron=check wp_cache_post_change: checking /var/www/html/wp-content/cache/meta/
    13:21:21 1474019 /?lottery-cron=check wpsc_delete_files: deleting /var/www/html/wp-content/cache/supercache/blazecompetitions.co.uk//competition-category/uncategorized/
    13:21:21 1474019 /?lottery-cron=check wpsc_get_realpath: directory does not exist - /var/www/html/wp-content/cache/supercache/blazecompetitions.co.uk//competition-category/uncategorized/
    13:21:21 1474019 /?lottery-cron=check wpsc_delete_files: directory does not exist: /var/www/html/wp-content/cache/supercache/blazecompetitions.co.uk//competition-category/uncategorized/
    13:21:21 1474019 /?lottery-cron=check wpsc_get_realpath: directory does not exist - /var/www/html/wp-content/cache/supercache/blazecompetitions.co.uk//competition-category/uncategorized//page
    13:21:21 1474019 /?lottery-cron=check prune_super_cache: exiting as file/directory does not exist : /var/www/html/wp-content/cache/supercache/blazecompetitions.co.uk//competition-category/uncategorized//page
    13:21:21 1474019 /?lottery-cron=check wpsc_delete_post_archives: deleting cache of taxonomies: https://blazecompetitions.co.uk/competition-category/uncategorized/
    13:21:21 1474019 /?lottery-cron=check wpsc_delete_files: deleting /var/www/html/wp-content/cache/supercache/blazecompetitions.co.uk//shop/
    13:21:21 1474019 /?lottery-cron=check wpsc_get_realpath: directory does not exist - /var/www/html/wp-content/cache/supercache/blazecompetitions.co.uk//shop/
    13:21:21 1474019 /?lottery-cron=check wpsc_delete_files: directory does not exist: /var/www/html/wp-content/cache/supercache/blazecompetitions.co.uk//shop/
    13:21:21 1474019 /?lottery-cron=check wpsc_get_realpath: directory does not exist - /var/www/html/wp-content/cache/supercache/blazecompetitions.co.uk//shop//page
    13:21:21 1474019 /?lottery-cron=check prune_super_cache: exiting as file/directory does not exist : /var/www/html/wp-content/cache/supercache/blazecompetitions.co.uk//shop//page
    13:21:21 1474019 /?lottery-cron=check wpsc_delete_post_archives: deleting cache of post type archive: https://blazecompetitions.co.uk/shop/
    13:21:21 1474019 /?lottery-cron=check wpsc_delete_files: deleting /var/www/html/wp-content/cache/supercache/blazecompetitions.co.uk//author/blaze/
    13:21:21 1474019 /?lottery-cron=check wpsc_get_realpath: directory does not exist - /var/www/html/wp-content/cache/supercache/blazecompetitions.co.uk//author/blaze/
    13:21:21 1474019 /?lottery-cron=check wpsc_delete_files: directory does not exist: /var/www/html/wp-content/cache/supercache/blazecompetitions.co.uk//author/blaze/
    13:21:21 1474019 /?lottery-cron=check wpsc_get_realpath: directory does not exist - /var/www/html/wp-content/cache/supercache/blazecompetitions.co.uk//author/blaze//page
    13:21:21 1474019 /?lottery-cron=check prune_super_cache: exiting as file/directory does not exist : /var/www/html/wp-content/cache/supercache/blazecompetitions.co.uk//author/blaze//page
    13:21:21 1474019 /?lottery-cron=check wpsc_delete_post_archives: deleting cache of author archive: https://blazecompetitions.co.uk/author/blaze/

    But, the question is, can I stop WP Super Cache from purging, based on those CURL query string CRON events I have? Also, I can see some double // blazecompetitions.co.uk//shop//page every so often, is that indicative of an issue or expected?

    Thanks so far!

    Plugin Author Donncha O Caoimh (a11n)

    (@donncha)

    I presume you’ve disabled WP Cron and are calling “/?lottery-cron=check” continuously to run cron jobs?

    That shouldn’t cause pages to be deleted unless you’re modifying a page every time, which I guess you might be, judging by the first line saying, “wp_cache_post_change”.

    If you are doing that, you might try enabling lockdown mode before doing the edit. Define the constant “WPLOCKDOWN” and it hopefully won’t purge the cache when an edit is done.

    What I’d do, is create a shortcode that reads the updated data from a file or database record and displays it on the page, and tell WP Super Cache not to cache that page. Look at “Rejected URL Strings” on the advanced settings page. If you do allow the page to be cached, then clear it when it gets updated with the prune_super_cache() command. See how it’s used in the developer docs here.

    Thread Starter kieronboz

    (@kieronboz)

    Hm okay, I have disabled WP-CRON yes – but admittedly the /?lottery-cron=check part I have, is for a plugin – I don’t love the implementation but I am at their whim, they advised me to use ‘WP Fastest Cache’ – and just testing it, it doesn’t seem to wipe the cache with the cron jobs on, so I suspect that they have some edge case in their plugin which is making it behave differently, and in turn WPSC is wiping.

    Their words:

    Hi

    install wp fastest cache or clearfy and set cache, it seems wp super cache does not remove some comments which are then changed on every request and causing cache regeneration on every request.

    regards

    I will keep investigating as I much prefer Super cache so far.

    I dont think the lockdown mode would be useful, as the site is generally quite dynamic and time dependant, especially for logged in users (which I dont cache for) – but admittedly i dont know _what_ the query crons are activating, for this plugin.

    Plugin Author Donncha O Caoimh (a11n)

    (@donncha)

    It’s strange the other cache plugins don’t clear the cache when edits are done. I’m glad they work at least.

    With lockdown mode, I meant that you could modify the code that runs in the lottery cron request so it sets lockdown mode *only* for that request. So then the plugin won’t delete any cache files, for that request. If it’s any other request, lockdown mode won’t be set.

    Adding this code in that lottery function would do it:


    if ( ! defined( 'WPLOCKDOWN` ) ) {
    defined( 'WPLOCKDOWN', 1 );
    }

    The only drawback is, if the cache is supposed to be cleared by some other action in that request, it won’t be as you can’t undefine a constant.

    Plugin Support Stef (a11n)

    (@erania-pinnera)

    Hey @kieronboz,

    Do you still need help? We usually close inactive threads after one week of no movement, but we want to make sure we’re all set before marking it as solved. Thanks!

    Thread Starter kieronboz

    (@kieronboz)

    Hey, no thats ok for now, I havent got too much availability to keep debugging so will just leave it for now, thank you.

    Plugin Support Animesh Gaurav (a11n)

    (@bizanimesh)

    Hello there — no problem! When you get the availability, you can continue troubleshooting. Feel free to reply to this thread anytime if you need help.

Viewing 12 replies - 1 through 12 (of 12 total)
  • You must be logged in to reply to this topic.