Hello,
I have been unable to reproduce the issue you describe in my testing environment.
It sounds like this might be a theme issue or a conflict with another plugin that you’re running. One simple test, if possible, would be to set up a second WordPress install on your server and test Quick Cache using the default WordPress theme and with no other plugins active. An alternative test would be to deactivate plugins one-by-one to see if the problem goes away and/or switch your site to one of the default WordPress themes.
I’m also getting this on every page except the home page, and I think the reason is the Nginx Confiiguration I’m using, which includes:
# Catchall: Catch permalinks and special slugs
location ~ ^/.+$ {
try_files $uri $uri/ /index.php?q=$uri&$args;
}
That’s a security measure, a fallback which converts the url to the form which WordPress expects if no file or directory exists as specified in the URL. I seem to recall that WordPress can also manage without, I’ll check it and get back.
Tim,
Thanks so much for jumping in here. If you can indeed confirm that it’s the Nginx configuration, I will open a Quick Cache bug report for this on GitHub and figure out how we can work around this.
Hi Raam,
always glad to help if I can! I spent an hour yesterday surfing for details on how WordPress handles Permalinks and $_SERVER variables, since I remembered once reading a lucid article somewhere, but could not find it again (baah). You may want to check the WordPress Codex or even the current sources – source never lies…
What I did piece together from vague hints and then by testing is this:
# Catchall: Catch permalinks and special slugs
# ?q=$uri&$args after /index.php is common but counterproductive: Cache-Plugins see
# GET parameters and may therefore not cache the page, fearing dynamic content.
# But WordPress is clever, it can infer Permalinks from the SERVER-Environment
# (QUERY_STRING, REQUEST_URI), so omit the GET parameters.
location ~ ^/.+$ {
try_files $uri $uri/ /index.php;
}
So basically, using Nginx and PHP-FPM, you just need to be sure that your Nginx-Config is setting the fastcgi_param’s QUERY_STRING and REQUEST_URI correctly – typically done in an extra include file, on Ubuntu / Plesk in /etc/nginx/fastcgi.conf. Then index.php handles permalinks correctly without any GET parameters and the caching problem is solved.
But I think that this problem also probably exists with Apache too – WordPress deposits a .htaccess file with roughly equivalent effect:
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
which in fact says that if no file or directory exists at that url then rewrite (as last action) to “/index.php” – BUT note “By default, the query string is passed through unchanged.” See Apache Docu.
So the .htaccess method would seem to “pass the query string through” – but what do they mean by that – as $_SERVER variable values only, or also appended as GET-Parameters? I really don’t know and wish they could document that better!
Anyone else able to chip in the 5 cents?
Cheers, Tim
What I meant to imply…
is that a Caching Plugin, finding GET parameters, could duplicate the algorithm behind WordPress’s index.php to check if the original URL was in fact simply a permalink (by checking the relevant $_SERVER variables) – and if it matches, i.e. it was in fact just a permalink, then NOT suppress the caching.
Tim,
Thanks again for your investigative work into this!
So the .htaccess method would seem to “pass the query string through” -but what do they mean by that – as $_SERVER variable values only, or also appended as GET-Parameters?
I believe they are passed as $_SERVER variables only. I just tested this on my site, where I have the default WordPress .htaccess rules and Quick Cache set to disable caching for GET Requests. When I visit a URL that doesn’t exist, the request is passed to index.php and WordPress then tries its best to guess what the real URL actually is. When it finds the real URL, it redirects me to that.
For example, if your permalink is /2014/07/example-post/ and you visit /example-post/, WordPress will figure out the correct URL and redirect you to it. When that happens, Apache doesn’t send the request to index.php using a query string. Instead it redirects to index.php and WordPress probably uses the $_SERVER['REQUEST_URI'] to get the URL that was originally requested (in this example, /example-post/) and then figure out if there’s a post that likely matches that permalink.
So, it would seem that the issue you’re experiencing with Nginx is related to how Nginx sends those requests differently than Apache. I haven’t personally heard of or seen this issue in my testing with Nginx, so it no doubt has something to do with the configuration you mentioned earlier.
is that a Caching Plugin, finding GET parameters, could duplicate the algorithm behind WordPress’s index.php to check if the original URL was in fact simply a permalink (by checking the relevant $_SERVER variables) – and if it matches, i.e. it was in fact just a permalink, then NOT suppress the caching.
That’s certainly a possibility. As I said, I haven’t heard this issue reported prior to this and I know that many people use Quick Cache with Nginx. If you’d like to open a feature request for adding an additional routine that runs when Nginx is detected, which checks the query string to see if it matches a permalink pattern, I will gladly add it to the roadmap.
