Doesn't seem to be working

[EricGibson]

I am using the latest stable version of WP 2.9.2 and have firefox and Headway WP theme. I install Quick Cache, turn it on, click "Save Changes" at the bottom, log out.... click a few pages... and go to View Page Source and scroll to bottom... nothing about Quick Cache shows up... Any suggestions?

[Carlos]

Same here. Is there another way to see if it is working properly?

[Elizabeth]

**Quick Cache is very easy to install ( follow these instructions ):**

1. Upload the `/quick-cache` folder to your `/wp-content/plugins/` directory.
2. Activate the plugin through the `Plugins` menu in WordPress®.
3. Navigate to the `Quick Cache` panel & enable it.

**How do I know that Quick Cache is working?**

First of all, make sure that you've enabled Quick Cache. After you activate the plugin, go to the Quick Cache Options panel and enable it, then scroll to the bottom and click Save. All of the other options on that page are already pre-configured for typical usage. Skip them all for now. You can go back through all of them later and fine-tune things the way you like them. Once Quick Cache has been enabled, **you'll need to log out**. Cache files are NOT served to visitors who are logged in, and that includes YOU! In order to verify that Quick Cache is working, navigate your site like a normal visitor would. Right-click on any page ( choose View Source ), then scroll to the very bottom of the document. At the bottom, you'll find comments that show Quick Cache stats and information. You should also notice that page-to-page navigation is lightning fast compared to what you experienced prior to installing Quick Cache.


If after you log out it's still not working.
Go to your WordPress Dashboard -> Quick Cache -> Config Options.
If you have a red bar, then it's not enabled. Use the drop down menu and enable it.

[EricGibson]

Thanks... I've tried all that, installed, made sure it was "enabled," logged out, browsed around as a regular visitor would... go to "View Page Source," scroll down to bottom and nothing about "Quick Cache" shows up. After the first few clicks, however, it does seem fast. But I'd still like a more "firm" visual way of making sure it's working. When I tried W3 Total Cache, (altho it didn't seem any faster than Quick Cache), the stuff about "W3 Total Cache" DID show up at the bottom of the "View Page Source" results. I'd prefer to use Quick Cache, as I've heard good reviews, but would like to have a more solid way to know it's installed and working properly. As Carlos says above, is there an alternative way?

[Jason Caldwell]

Hey guys. Please read over this. It might help you out with this problem.

By default, Quick Cache does NOT cache _GET requests.
However, you can change if you need to.

In other words, if you're using unfriendly Permalinks ( with ?pageID=123 )

Please log into your WP Dashboard, and go to:
Quick Cache -> Don't Cache Query String GET Requests

Don't Cache Query String GET Requests?

This should almost always be set to True, unless you're using unfriendly Permalinks on your site. In other words, if all of your URLs contain a query string ( /?something=something ), you ARE using unfriendly Permalinks, and you should update your Permalink options in WordPress® immediately, because that also optimizes your site for search engines.

That being said, if you really want to use unfriendly Permalinks, and only if you're using unfriendly Permalinks, you should set this to False; and don't worry too much, the sky won't fall on your head

It should also be noted that POST requests ( forms with method="POST" ) are always excluded from the cache, which is the way it should be. POST requests should never be cached. CLI requests are also excluded from the cache. A CLI request is one that comes from the command line; commonly used by cron jobs and other automated routines.

* Advanced Tip: If you are NOT caching GET requests ( recommended ), but you do want to allow some special URLs that include query string parameters to be cached; you can add this special parameter to your URL &qcAC=1 to tell Quick Cache that it is OK to cache that particular URL, even though it contains query string arguments.

[Lynda]

Well, I'm experiencing the same problem. I have everything configured correctly and I do not use unfriendly permalinks. Nothing about quick cache is showing up in my View Source while not logged in. Is this not compatible with 3.0?

[Lynda]

I do see files being created in the cache directory, but nothing at the bottom of View Source and my site doesn't seem one iota faster.

So how exactly can I tell if this is working?

[Jason Caldwell]

Thanks for reporting back Lynda.

Yes, Quick Cache is compatible with WordPress® 3.0.

Here are some other things that I would check on:

• Are you logged in whenever you're testing? Make sure you're logged out.
• Is Quick Cache enabled? After you activate the plugin, "enable" it through the Quick Cache panel.
• Run a quick scan through your plugins to make sure none of them are selectively disabling the cache. For instance, you can run a search for QUICK_CACHE_ALLOWED, and also for DONOTCACHEPAGE. If you find those words inside one of the files in your /plugins/ directory, it could be preventing the cache system from working.
• Have you configured any No-Cache URIs in the Quick Cache panel?
  If so, empty those out before testing, just to make sure there was no mistake.
• Also check your No-Cache Referrers & No-Cache User-Agents.
• Does `/wp-content/advanced-cache.php` exist?
• Does your /wp-config.php file contain this line?
  

  Code: Select all

  define("WP_CACHE", true);

If nothing works, and you're still not seeing the Quick Cache comment lines at the very bottom of your source code, there is a high probability that you have a plugin conflict somewhere. Try disabling other plugins until Quick Cache works as expected.

If you were testing other cache plugins before you installed Quick Cache, it might do some good to manually delete the /wp-content/advanced-cache.php file, and then re-install Quick Cache.

Please report back if you can. ~Thanks.

[RVoodoo]

Well, instead of starting a new thread, I'll jump into this one since I have the same issue, I hope that's cool.

I do have the same issue, nothing outputting on my source. I believe I've followed everything here....but I also think it was initiated by something I did.

Originally when installed, the plugin worked and I had output from it in my source. I tried to enable gzip through htaccess per the info included in the plugin. That didn't work. I scrapped that and went with the php.ini, that didn't work. I did a little research (I'm on godaddy shared) They say to include this line at the top of my header to enable gzip

Code: Select all

<?php if (substr_count($_SERVER['HTTP_ACCEPT_ENCODING'], 'gzip')) ob_start("ob_gzhandler"); else ob_start(); ?>

so I did. That broke the plugin. (related note, I did the same thing with w3 cache installed, and permanently broke the plugin..it worked before I did that, after I did that, I could never get it working)

So after the plugin broke, I checked my wp-config for the appropriate line. Made sure that line was out of my header, along with the htaccess and php.ini stuff. Deleted the plugin and all files, including cache folder. Reset plugin folder. Reinstalled the plugin and ran only that. Ensured the plugin was activated and enabled. Logged out and tested. Still no go. All the appropriate files and folders were put in place by the plugin. I have some action in the cache folder, just nothing in my source. Any ideas? Did I break it forever?

Thanks in advance!

[Jason Caldwell]

so I did. That broke the plugin. (related note, I did the same thing with w3 cache installed, and permanently broke the plugin..it worked before I did that, after I did that, I could never get it working)

I've heard other reports similar to this. Often times, the appearance of something being "broken forever" on GoDaddy, is attributed to server replication within their network. After you make a server configuration change, it can sometimes take up to 24 hours for that change to be reflected, and the same is true when a setting is reverted back.

This creates a confusing situation whenever you're adjusting your configuration. I'm not sure it's the case here, but I just thought I would mention it. It's usually not a full 24 hours, but more like 30 minutes; which can still be quite confusing. You expect something to be one way, and it IS, but not until 30 minutes later.

This normally will NOT have an impact on settings within WordPress, but it WILL have an impact on changes within your php.ini file, and/or inside an .htaccess file.

All the appropriate files and folders were put in place by the plugin. I have some action in the cache folder, just nothing in my source. Any ideas? Did I break it forever?

Code: Select all

<?php if (substr_count($_SERVER['HTTP_ACCEPT_ENCODING'], 'gzip')) ob_start("ob_gzhandler"); else ob_start(); ?>

Interesting. If either of you can provide a demonstration of this happening, I'd love to see it. It sounds like it might be an issue related specifically to GoDaddy shared hosting. If I can gain access to a test installation on one of your domains, it would help tremendously. I can probably resolve the issue; once I'm able to reproduce it.

[RVoodoo]

Well, it's been well over 24 hours now, still no caching from what I can tell. Nothing in the source code, and still have long load times. The website in question is http://www.rvoodoo.com

I could set up a test installation, but the thing is, I would think it would work if I did. I think that because when I originally installed Quick Cache, it worked perfectly. It wasn't until I tried to get gzip working that Super Cache died. No amount of uninstalling and reinstalling has done any good unfortunately. I'm gonna try it again since it's no big hassle.

Not sure if you'd like access to the production site/ftp to poke around?

Thanks for the reply, much appreciated!

[Jason Caldwell]

Gotchya. Yes, FTP/Dashboard access would be great.
memberlist.php?mode=email&u=2

[RVoodoo]

Thanks, I went ahead and sent you a PM. I'll just repeat here what I sent you, for those following along at home!

Friday, quick cache still wasn't working on my index page. I went to a single post and it worked. So I cruised around my site checking the source code on each page/post. It only worked on that one post. No other page or single post had the info in the source. The next day I checked it out again, and the post that quick cache had been working on the day prior no longer was working. So I'm back to having no cache functioning.

Thanks again!

[Jason Caldwell]

Hi there. Sorry for my delayed response.

My PM's were disabled a few days ago, because I was being flooded with them; which is non-productive for everyone else on the board. ( so I missed yours, very sorry )

Instead, please send me that information through the Email link under my name. Either that, or you can submit the details through our contact form if you prefer:
http://www.primothemes.com/contact/

[RevVoodoo]

I sent a message through the contact form. The link under your username has the exact same url as the link in one of your previous posts, which is where the last message was sent. SO hopefully it gets through this way.

No problem on the delayed response, I have been trying various cache plugins for months now and have never succeeded, so a few more days doesn't bug me at all.

One thing I forgot to mention on my contact form email, should you feel like poking around in the ftp. the wp is running from root, but installed in a subdirectory (you can get the subdirectory name by peeping the url of the admin screen when logged into the site, as I'm sure you know)

Thanks again!

[Jason Caldwell]

Hi there. My investigation on this has completed.

Quick Cache is running on your installation now; with GZIP enabled as well.

GoDaddy recommend this to you, but they are WRONG.
1. I removed the ob_start("ob_gzhandler") from your header.php file.
( This is NO-NO ) I don't recommend the ob_gzhandler method, because it causes output nesting issues. Particularly when it is placed inside a theme file. For the benefit of other readers, if you really NEED to use this method, always place this line inside your wp-config.php file instead; this will ensure the proper nesting order, so that gzipped data is not stored inside the cache.

2. I added this line to your /php5.ini file:

Code: Select all

zlib.output_compression = on

3. I cleared the entire cache, and reset your Quick Cache installation.

4. I logged out, and ran tests in Firefox with Firebug HTTP monitoring on.
Quick Cache is fully operational now, and GZIP is working correctly.

[RVoodoo]

Well would ya look at that? Very cool! I have no idea how you found that line in my header file? I had deleted it previously when we talked up above. Maybe I added it in? Or had it in there twice. No idea, but regardless, I checked around the site....ran it through some tests, and everything works, I'm getting better times, and the gzip is working...saving me 82% on bandwidth. That's straight up awesome! I'm off to donate!

[Jason Caldwell]

Very welcome. Glad to hear that everything worked out.
~ Donation received. Thank you!