M?ns Jonasson

I just committed version 2.4 which fixes this issue. Try it out!

Thanks, I will take a look at this in my next revision.

Thanks for the heads up. I will take another look at the locations in my next revision, and also look over the gettext functions.

I don’t think the locations of other files are stored in the database at all, but rather left orphaned in the uploads folder, unfortunately.

/M;

Your solution makes assumptions about the location of WordPress folders and is therefore not recommended.

What is the error you are getting with your include?

/M;

This is fixed in the latest release. Please update and try it out.

/M;

Thank you, I’ve had a look at it and I see the problem. Part of the problem is the (stupid) way in which WordPress handles thumbnail images. Since all the thumbnails are pre-rendered they are static in the uploads folder and this makes it somewhat difficult to accurately detect and delete them.

I’ll take this into consideration for the next version of the plugin.

This should be fixed in 2.0 released shortly. Please try it again.

Alright, I will stick with half on then, if there is no discernable punishment for not going “full-on” super cache.

Thanks a lot for all your answers!

Thank you,

my problem is that with Supercache “on” (instead of half on) the pages with queries are all served the same supercache file, regardless of the query.

With “half on” mode it works, but I would love to be able to enable full caching.

Are you saying that this SHOULD work in supercache mode? That pages with GET queries should be getting half-on cached files? Because they are not, in my case. It is like WP Super Cache is just ignoring the queries altogether, and serving the supercached copy of the page w/o query.

As for the queried versions of the pages, the debug tells me nothing, so I assume that the GET query is completely ignored by the mod_rewrite rules matching me against content in the /supercache/ directory?

No, I am not logged in, but the debug says the following:

11:38:08 / Cookie detected: wordpress_test_cookie
11:38:08 / Not caching for known user.

I guess this means that since I once WAS logged in, WP remembers me and WP Super Cache still ignores caching for me?

Not anymore. This was fixed in 2.4.

Thank you donncha,

but could you please elaborate? Do you mean that I could instead modify qTranslate to use the “supercache_dir” filter to set the exact uri to cache?

I’ve determined that qTranslate makes changes to $_SERVER[“REQUEST_URI”], stripping the language prefix from the URL so that WP Super Cache sess no difference between /en/content and /content, which leads to the problems described above.

A temporary fix I implemented was to make changes to wp-cache-phase2.php and more specifically the function get_current_url_supercache_dir() which determines the name of the current URL to be cached.

I’ve added a call to the qTranslate language function as such:

$uri = "/" . qtrans_getLanguage() . $uri;

This is an ugly way to fix this, since this will break if I upgrade WP Super Cache in the future, but I saw no other option for now.

I’m not sure about the qTranslate behaviour of “breaking” the $_SERVER[“REQUEST_URI”] data. I’d be able to solve the WP Super Cache much more elegantly if that variable (or another one!) was left intact.