Murmatron 2

why is an extra file extension necessary?

Because rename() in PHP fails on Windows servers if the destination file exists. To my mind that would have left a (very small) window of time where no file existed to serve since to be cross-platform compatible we would have to delete the .html before renaming the .tmp -> .html

Working properly on Windows is important to me.

That’s the only reason.

tigertech, I was thinking along similar lines but decided against it because of this:
<!--nextpage-->
Comments usually appear at the bottom of every page of a paged post. Taking the human trigger out of that process means that you may actually increase the server load by having to automatically regenerate all the pages of a paged post when everyone is busy posting comments on just the first or the last.

I’ve got a working version already that pretty much guarantees only one load of the php engine for each supercache page by doing this:

1. Don’t delete expired pages; rename them to .expired
2. Page generation renames .expired to .wip (short for ‘write in progress’) which is served by rewrite rules to parallel requests during page generation.
3. Write .tmp rather than .html so that partial .html isn’t served (the rewrite rules prefer .html to .wip)
4. Rename .tmp -> .html
5. Delete .wip

Unfortunately, I’m having problems making a patch against supercache since the version I’m running is more ‘different’ than TortoiseMerge can cope with now. :\

No, that line tells browsers that what they are getting is encoded as UTF-8

See. https://en.wikipedia.org/wiki/Character_encodings#Popular_character_encodings

Unfortunately there’s two ways to encode a file as UTF-8.
One has what’s called a Byte Order Mark at the start while the other does not.

If your text editor supports UTF-8 BOM encoding, you’ll never see the BOM. The problem is that if one or more of your PHP files has a BOM there’s actually the 3 characters ??? before the opening php tag and it makes supercache go crazy.

I guess how you find and fix it depends on what OS you have and what text editor you normally use.

Of course, the problem could be something else, but I shot myself in the foot with a UTF-8 BOM a few weeks ago – It looks very familiar.

The screen-shot looks like one of your theme files (or plugin files) is saved as UTF-8 with BOM

I’m 75% there, but I can’t settle on a form of rewrite rules that minimize the performance hit

Here’s the sequence.
phase2 wp_cache_ob_callback
1. rename .obsolete to .wip (.wip is served by rewrite) so no
other anon clients will load php
2. create .tmp
3. write file
4. rename .tmp -> .html
5. delete .wip

If a file has been expired, there’s will always be a file for rewrite to serve and I think the .tmp -> .html sequence also addresses the possibility of partially written files in this thread.

.obsolete files are generated in prune_super_cache and wp_cache_post_change by renaming instead of unlinking and aren’t served by rewrite rules

The sequence and logic seems sound. I’ve got this working on my mutant version of supercache just fine, but the most important and trickiest bit is to get Step 1. moved out of ob_callback to before ob_start so that only the first anon client (unless we’re very unlucky) will load php

Stay tuned – It might take a couple of days

I was about to hit ‘Post’, but I got thinking… It may not be that bad. I can probably rename the .obsolete files on fairly cheap pre-conditions in phase1 and then undo it in ob_callback if it turns out to have been inappropriate to do it.

<?php if($paged && ($paged != 1) && ($paged != $wp_query->max_num_pages)) echo " | "; ?>

If the Content-Encoding header is in fact missing, mod_deflate would zip the already zipped data. Some browsers don’t like that very much.

mod_deflate definitely won’t encode (I checked the 2.2.9 source to verify) if a Content-Encoding header is already present in its input (it doesn’t care what the encoding is claimed to be).

However; I can’t replicate the missing header in the meta.

Here’s a gzip meta from my server:

Vary: Accept-Encoding
Last-Modified: Tue, 29 Jul 2008 20:37:36 GMT
Expires: Wed, 11 Jan 1984 05:00:00 GMT
Content-Type: text/html; charset=UTF-8
X-Pingback: https://murmatrons.armadillo.homeip.net/xmlrpc.php
Cache-Control: no-cache, must-revalidate, max-age=0
Pragma: no-cache
Content-Encoding: x-gzip
Vary: Accept-Encoding
Content-Length: 8383

The only strangeness there is 2 stored instances of Vary – not sure where that comes from.

A strange problem indeed.