• Resolved dimal

    (@dimalifragis)


    Trying to debug the preload issues, i see the log full of those:

    gc: could not delete ABSPATH/wp-content/cache/supercache/index.html as it’s protected.

    prune_super_cache: did not delete file as it wasn’t a directory or file and not forced to delete new file: ABSPATH/wp-content/cache/supercache/index.html

    prune_super_cache: did not delete file as it wasn’t a directory or file and not forced to delete new file: ABSPATH/wp-content/cache/supercache/www.web site.com/index-https.html

    What all those mean? Is that “ABSPATH” an issue?

Viewing 4 replies - 1 through 4 (of 4 total)
  • Plugin Contributor Mark (a11n)

    (@thingalon)

    Hi @dimalifragis,

    gc: could not delete ABSPATH/wp-content/cache/supercache/index.html as it’s protected.

    There are paths which Super Cache will never delete; these include the index.html files inside the cache/ and cache/supercache/ directory. I believe this message is safe to ignore.

    prune_super_cache: did not delete file as it wasn’t a directory or file and not forced to delete new file: ABSPATH/wp-content/cache/supercache/index.html

    Super Cache has an internal function called prune_super_cache, which is called after preloading is complete. (It’s called in other circumstances too – but I’ll focus on the one most relevant to the system you are debugging).

    prune_super_cache deletes cached files which are too old, based on your cache settings.

    We recently found an issue where prune_super_cache was deleting recently preloaded content if “Cache Timeout” was set to 0. We’ve got a patch coming soon to a Super Cache near you.

    Anyway, this particular message will appear when Super Cache decides that a specific file is not to be deleted because it’s too new (or it looks like it’s a directory). The wording “as it wasn’t a directory or file and not forced to” could be improved upon, but this one is safe to ignore.

    What all those mean? Is that “ABSPATH” an issue?

    Yes, seeing ABSPATH in your file path is a little strange, and could cause issues. ABSPATH is the name of a PHP constant which (usually) contains the path of your WordPress site’s files on the server they are running on.

    It looks like "ABSPATH" has been used as a string value somewhere in your system, instead of being used as the name of a PHP / WordPress constant.

    The above log messages (about prune_super_cache, etc) all come from parts of Super Cache which use its internal idea of where to cache your files. It bases those on WP_CONTENT_DIR — an internal WordPress constant describing where wp-content lives. I suspect that your WP_CONTENT_DIR constant contains the string "ABSPATH". This could potentially happen if your wp-config.php file contains overrides for your wp-content directory which are mis-applied.

    Do you have any custom code in your wp-config.php or anywhere else in your site which may be setting the value of either ABSPATH or WP_CONTENT_DIR?

    Thread Starter dimal

    (@dimalifragis)

    Thanks @thingalon for the help.

    I worry about the last part, the ABSPATH issue. No i don’t have anything strange or modified in my config of WP. Now if it is used anywhere else, i have no idea.

    I will have some to check for all that.

    Plugin Support Alin (a11n)

    (@alinclamba)

    Hi @dimalifragis,

    I will have some to check for all that.

    Thanks for letting us know. When you have any updates, please let us know.

    It’s ABSPATH to protect the security of your site as this is output from the plugin debug log.

    Long ago, the logs reported the actual path and people would paste them into the forum here, exposing the path to their webserver for all the world to see. This way is much safer and as @thingalon said, it’s the path to your WP install. Not something we really need to know.

Viewing 4 replies - 1 through 4 (of 4 total)
  • The topic ‘Some issues from WPSC debug’ is closed to new replies.