• synaemnid

    (@synaemnid)


    I have WordPress installed in a subdirectory with upper and lower case letters in the name.

    After installing and configuring WPSC, the mod_rewrite rules look like:
    RewriteRule ^(.*) “/MyDirectory/wp-content/cache/supercache/%{HTTP_HOST}/http/MyDirectory/$1/index.html” [L]

    But the actual cache directory is:
    wp-content/cache/supercache/www.example.com/http/mydirectory/

    So it is converting the directory name to lower-case when creating the directories for the cache files, but it doesn’t do it when generating the mod_rewrite rules. Once I realized this, it was easy enough to fix it manually…but will there be any other problems?

    The code that generates the mod_rewrite rules (in wpsc_get_htacess_info) is easy enough to follow:
    $home_root = parse_url(get_bloginfo(‘url’));
    $home_root is then used for both RewriteBase (which needs the case preserved) and for the sub-directory name after http/https (which should be lower-case).

    I saw this in get_current_url_supercache_dir:
    $uri = strtolower( $wp_cache_request_uri );
    $uri later gets used to create the path)…but it looks like the conversion to lower case is only done when $post_id==0. Also, get_current_url_supercache_dirs doesn’t do it:
    $uri = $wp_cache_request_uri;

    Maybe I just need to spend some more time understanding the code, but right now I’m not confident that, even after fixing .htaccess, it’s going to work in all cases.

Viewing 8 replies - 1 through 8 (of 8 total)
  • Plugin Author Donncha O Caoimh (a11n)

    (@donncha)

    Damn, unfortunately your site triggered a fix I had to include to make sure international sites were cached correctly. I’ll have to come up with a different way to fix it.

    Thanks for reporting the bug. I’ll reply here again when I’ve fixed it in the development version so you can test it.

    Hi,

    We’ve encountered a similar problem, that could have some security impact.

    We have had an SEO problem where some of our pages where accessible independantly from using lower/uppercase character. This could lead to duplicate content, and thus we fixed our code so that the only valid URI would be lower-case.

    Unfortunately, this seems to have triggered a bug in wp-supercache :

    – User access http://www.exemple.com/My-Url
    -> Server return a 404
    -> wp-supercache store the 404 content into the supercache my-url directory (lowercase).

    – User then access http://www.exemple.com/my-url :
    -> Server return the cached 404 page in place of the real page content…

    Any advise on how to fixes this problem ?
    Regards,

    amael.doe – Supercache shouldn’t cache a 404 error so it shouldn’t be caching that My-Url page. Can you debug it with the plugin debug log?

    synaemnid – should be fixed in trunk now if you want to give the development version a go (will update in the next 20 minutes).

    Thans Donncha for the feedback,

    Not sure whether that would be related, but the 404 is triggered from a WordPress plugin, using the following code:

    status_header(‘404’);
    $wp_query->set_404();
    echo(“Page not found.
    “);
    return;

    You are correct in that the 404 isn’t detected:

    10:32:17 /calendrier/boutique/testnotexist/ supercache dir: /var/www/www.exemple.com/htdocs/wp-content/cache/supercache/www.exemple.com/http/calendrier/boutique/testnotexist/
    10:32:17 /calendrier/boutique/testnotexist/ No wp-cache file exists. Must generate a new one.
    10:32:17 /calendrier/boutique/testnotexist/ In WP Cache Phase 2
    10:32:17 /calendrier/boutique/testnotexist/ Setting up WordPress actions
    10:32:17 /calendrier/boutique/testnotexist/ Created output buffer
    10:32:17 /calendrier/boutique/testnotexist/ Output buffer callback
    10:32:17 /calendrier/boutique/testnotexist/ Anonymous user detected. Only creating Supercache file.
    10:32:17 /calendrier/boutique/testnotexist/ Gzipping buffer.
    10:32:17 /calendrier/boutique/testnotexist/ Writing non-gzipped buffer to supercache file.
    10:32:17 /calendrier/boutique/testnotexist/ Writing gzipped buffer to supercache file.
    10:32:17 /calendrier/boutique/testnotexist/ Renamed temp supercache file to /var/www/www.exemple.com/htdocs/wp-content/cache/supercache/www.exemple.com/http/calendrier/boutique/testnotexist/index.html
    10:32:17 /calendrier/boutique/testnotexist/ Renamed temp supercache gz file to /var/www/www.exemple.com/htdocs/wp-content/cache/supercache/www.exemple.com/http/calendrier/boutique/testnotexist/index.html.gz
    10:32:17 /calendrier/boutique/testnotexist/ Writing gzip content headers. Sending buffer to browser
    10:32:17 /calendrier/boutique/testnotexist/ wp_cache_shutdown_callback: collecting meta data.

    Ah. Try setting the global variable $wp_cache_404 as true as well. The plugin caches the 404 status on startup because some themes mess with it when they use the query object.

    Setting that variable to true should fix your problems.

    Hi!

    I can modify the global variable, however, it seems the plugin will reset it in wp_cache_catch_404() function anyway.

    Is there a specific place where I should perform this modification ? Would it be possible to add a configuration entry so that wp-supercache doesn’t cache the 404 status on startup ?

    Thanks!

Viewing 8 replies - 1 through 8 (of 8 total)
  • The topic ‘[Plugin: WP Super Cache] mod_rewrite caching fails if WP is in sub-directory with upper-case letters’ is closed to new replies.