bob_wp

Hi

Super Cache looks for the tags:

# BEGIN SuperCache
# END SuperCache

(that may not be the right capitalization and it does matter)
if it finds them it decides to use mod_rewrite. If it does not find them it decides the rules aren’t loaded acts accordingly.

If you simply comment out the rules (and don’t delete the tags) super cache gets *very* confused.

If you are going to use mod_rewrite, the super cache rules need to be pretty much exactly as shown in the plugin. If they are not, Super Cache will likely mess up in one way or the other.

The rest of the rules in the /.htaccess file also need to be right. That’s not just for Super Cache, that’s true for WordPress in general. If the rules are not right, odd things will break here and there.

Bob

Hi

If Super Cache finds the rewrite rules in your /.htaccess file, it will use mod_rewrite caching. The “php caching” setting will be overridden.

Don’t ask how I know this … it’s in the same file as, “gee if wp-cron stops working right all sorts of things break in odd ways (including Super Cache) …”.

Bob

Hi

If you are set to the default settings under 3.0, there are no rules installed in .htaccess. If the switch is re-writing rules, I suspect it’s only going to work if you switch between the “right” two things.

Crazy stuff …

Bob

Hi

How are your DNS entries set up?

Bob

Hi

You do *not* want to post what comes after

#BEGIN WordPress

and before

#BEGIN WordPress

The only reason to paste any of the “WordPress” tags is to enable the automatic stuff to work.

The stuff you *do* want to paste is between the Super Cache begin and end tags.

Again, if there’s something else already in the /.htaccess file, be carefull you don’t mess it up. (as in don’t erase it).

If you have the WordPress tags in your /.htaccess then put the Super Cache stuff *before* the WordPress stuff. The same would be true if your /.htaccess had WordPress generated lines that did not have the tags on them. The SuperCache stuff would go before that as well.

Bob

Hi

You are going to run into a very basic problem pretty fast. Because of the way SSL works, you can have only one SSL cert per IP. Unless you have more than one IP to use for SSL, you are still stuck. They will get one and only one SSL ….

Bob

Hi

This stuff could be a lot easier than it is. Of course you are doing some *very* complex things with these plugins. Not simple at all…

Bob

Hi

Mod_rewite is a fine thing. It’s recomended mainly because it adds a slight bit more performance. The setup is much more involved. I suspect it’s more likely to have strange interactions with other stuff. I have benchmarked both mod_rewrite and php on my site and found little differance in static tests. Static testing is *never* perfect, so in the real world there may be a greater differance.

Bob

Hi

One other point, you do not want the goop between the tags in the /.htaccess file. What you add looks like this:

# BEGIN WordPress
# END WordPress

and not like this:

# BEGIN WordPress
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# END WordPress

That all *assumes* you have a blank /.htaccess file with nothing in it. If there’s stuff in there already you would do this:

# BEGIN WordPress
everything that's in there now goes here
# END WordPress

That assumes that WordPress put the stuff in the /.htaccess file. If not you will have to figure out where the file came from.

Bob

Hi

No, the “BEGIN WordPress” stuff does not go in /wp-content/cache/.htaccess.

The stuff you have shown between # BEGIN supercache and # END supercache is correct for /wp-content/cache/.htaccess.

Completely different rules go into /.htaccess once it is set up with the # BEGIN WordPress and # END WordPress tags. The only thing you need to do manualy is add those tags to /.htaccess if they are not there already. Everything else you need is done for you by the magic of the Super Cache admin page.

If you are having all this trouble why are you using rewrite caching? Just click the box for php caching and all these issues will go away.

Bob

Hi

There are two .htaccess files involved here. One is in “/” and the other one is in “/wp-content/cache”. The one that needs the # Begin stuff is the one in “/” . The “Rules cannot be updated” is complaining about the “/.htaccess” file and not about the “/wp-content/cache/.htaccess” file.

Bob

Hi

Ok, I didn’t want to blindly add rules without checking. The good old “it’s working now and I don’t want to break it”. I have since added Varnish into the mix, so there’s a whole other layer of “stuff” going on.

Bob

Hi

I found that I had to copy the “example” .htaccess stuff directly from the Super Cache admin page into the .htaccess in the wordpress root directory to get it to recognize that it was there. Maybe I had a typo, who knows.

Once the correct stuff was in .htaccess It then brought up more stuff on the Super Cache page to allow it to try the .htaccess rule add. The file needed to be writable by the server in order for that to work.

Again, I only saw this stuff after I checked “use mod_rewrite” instead of “use PHP”. Getting the “use PHP” up and running was very simple.

Bob

Hi

The only time I see the stuff about rewrite rules is when I check the top box on the advanced setup menu. That’s the one that enables rewrite caching instead of php caching.

The cache can either work by feeding back information at the php level (the code) or by re-writing the request (the server level). Doing it at the server level is slightly faster according to the docs. rewrites are also a bit more complex to set up.

Did you have another cache set up before you installed Super Cache?

Bob

Hi

If you are using “rewrite caching” then indeed you need to update the rules.

Are you running rewrite caching?

Bob