Commenting only because I had to update my email address to ensure I see the response 🙂
Okay, this morning I am seeing a different result.
First, my server has mod_rewrite, and it works fine for everyone application throughout my website.
My blog’s index page works as it is supposed to; when called, the mod_rewrite version is supplied– it displays as an HTML file — works like a champ.
Now, this morning, every other page regardless if an ad is on it or not now returns, “WP-Super-Cache:Served supercache file from PHP” I get pretty good traffic and the database calls can be expensive (from a visitor’s page loading perspective/not monetary).
I have checked and rechecked the htaccess files, and they have the code required by the plug-in.
I use HTTPS protocol, and my blog is just one part of my site and is in a directory, not the site’s homepage (domain.com/blog/).
Any suggestions to a resolution would be outstanding, thank you!
With the ad/FB code, are you using a particular plugin to insert them into your site or something direct in a template?
I’d like to duplicate this behavior on my end.
Cheers!
Brandon,
Thank you. As I wrote in my last comment, it is happening on every page now except the blog’s index page — when I first started the thread, I saw a difference in the two (index always worked, but ad and fb pages returned a different server header than ones without) — nut today, they are the same again, so my first conclusion must be wrong.
To answer your question though, I just add the Facebook code without a plugin — Adsense, I use AdSense Manager (old, unsupported plugin that still works great).
I also use Google Analytics (no plugin, just added code to my theme).
navycs.com/blogs/ is the url.
Again, thank you for checking — I can’t figure it out 🙂
Debug of a single visit to a post (I changed the actual document root to DOCUMENT_ROOT and also removed the cookie info — this page does NOT have ads or Facebook):
supercache dir: DOCUMENT_ROOT/blogs/wp-content/cache/supercache/www.navycs.com/blogs/2015/03/09/my-slap-tear/Fetched gzip static page data from supercache file using PHP. File: DOCUMENT_ROOT/blogs/wp-content/cache/supercache/www.navycs.com/blogs/2015/03/09/my-slap-tear/index-https.html.gzsupercache dir: DOCUMENT_ROOT/blogs/wp-content/cache/supercache/www.navycs.com/blogs/2015/03/09/my-slap-tear/Fetched gzip static page data from supercache file using PHP. File: DOCUMENT_ROOT/blogs/wp-content/cache/supercache/www.navycs.com/blogs/2015/03/09/my-slap-tear/index-https.html.gzwp_cache_get_cookies_values: /^wp-postpass|^comment_author_|^wordpress_logged_in_(numbers removed)/ Cookie detected: wordpress_logged_in_(numbers removed)In WP Cache Phase 2Setting up WordPress actionsNot caching wp-admin requests.
And I just noticed this error: “Problem with the SSL CA cert (path? access rights?)”
I have contacted my Webhost — I hope the resolution to this will fix the issue. I’ll keep you posted.
My web host, Hostgator, has told me, so far, that I do not have an SSL issue (TLS 1.2) and the “Problem with the SSL CA cert (path? access rights?)” error I am getting in WP Super Cache is a plug-in problem. I told them that I do not accept that answer and to boost the issue up to a higher level of support — they have done so and I am standing by.
That said, could there be an issue in the plugin when it deals with TLS 1.2?
I get the “Problem with the SSL CA cert (path? access rights?)” at the top of the page when I run the cache test as well as the following:
Cache Tester
Test your cached website by clicking the test button below.
Fetching https://www.navycs.com/blogs/ to prime cache: OK
Fetching first copy of https://www.navycs.com/blogs/: FAILED
Fetching second copy of https://www.navycs.com/blogs/: FAILED
One or more page requests failed:
The pages do not match! Timestamps differ or were not found!
Things you can do:
Load your homepage in a logged out browser, check the timestamp at the end of the html source. Load the page again and compare the timestamp. Caching is working if the timestamps match.
Enable logging on the Debug page here. That should help you track down the problem.
You should check Page 1 and Page 2 above for errors. Your local server configuration may not allow your website to access itself.
This was entirely my mistake. I had code in my WordPress htaccess out of order. Everything seems to work great now.
***slaps own forehead*** 🙂
