Inposure

On the wish list:

1. Add an option to sleep n seconds between each page cache when preloading. I believe there was a mandatory 5 sec sleep in a previous version, which for my taste is too long. But a user defined sleep should accomodate for different setups and reduce load when supercache starts preloading.

2. Add a fixed clock time when to begin preloading. As it stands, you can only define intervals, like every 1400 minutes, which will inevitably lead to the preloading schedule being displaced forward or backward in time, because this time counts from the time preloading is finished. For obvious reasons, I would like to preload the site when it is the least busy, and also make it fit neatly into other tasks like optimizing mysql via cron.

A solution that I have control over, like customizing the message (if any), including translating it to a proper language and providing an e-mail message of my choice (if any).

And it is not harmless. An e-mail address out in the void WILL be picked up by harvesters and WILL result in phishing attempts, viagra spam and a lot of noise.

This will cost me an awful lot of pain changing e-mail at various places and informing others. I never opted to get spam, I wanted a solution to get rid of it.

From bad-behavior-wordpress.php:

// Return emergency contact email address.
function bb2_email() {
	return get_bloginfo('admin_email');
}

Then in core.php, we get the call:

<p>Your technical support key is: <strong><?php echo $support_key; ?></strong></p>
<p>You can use this key to <a href="https://www.ioerror.us/bb2-support-key?key=<?php echo $support_key; ?>">fix this problem yourself</a>.</p>
<p>If you are unable to fix the problem yourself, please contact <a href="mailto:<?php echo htmlspecialchars(str_replace("@", "+nospam@nospam.", bb2_email())); ?>"><?php echo htmlspecialchars(str_replace("@", " at ", bb2_email())); ?></a> and be sure to provide the technical support key shown above.</p>

So, yes, it does that. It came to my attention when someone actually used that e-mail address to inform me of a failed attempt at posting a comment.

And now this e-mail address, which was previously hidden to the world, is in the open, and I am receiving spam messages to it.

Yeah, happens to me too.

Really?

For me stats is working, sort of, but top posts are missing since yesterday. And now posts are all reported as “deleted” in the stats dasboard:

#2304 (deleted)
…

I think a word on this from the WP crew would be in order, apparently there is a great snafu with the stats causing trouble for a lot of people.

curl -I "https://luxford-pt-1.s3-website-eu-west-1.amazonaws.com/wp-content/themes/arras/js/superfish/superfish.js"
HTTP/1.1 404 Not Found
x-amz-error-code: NoSuchWebsiteConfiguration
x-amz-error-message: The specified bucket does not have a website configuration
x-amz-error-detail-BucketName: luxford-pt-1
x-amz-request-id: 76D0504B142C188E
x-amz-id-2: yL9TVWmtk6PncutS/Jb9bh0tDoqWBTLBesSze4JHKiJNy7XvXy73RpZtT4QXnbVM
Transfer-Encoding: chunked
Date: Fri, 04 Mar 2011 23:20:30 GMT
Server: AmazonS3

This means that your CDN configuration is wrong. There is no such website configuration, and therefore no files to get.

I guess your PC browsers used cached versions.

Works fine on my Mac (Safari, Chrome, Firefox). Clear your cache and see if that helps.

These might also work:

WPCACHEHOME . ‘wp-cache-phase1.php’

WP_CONTENT_DIR . ‘/plugins/wp-super-cache/’ . ‘wp-cache-phase1.php’

It must be the full absolute file path:

/path/to/your/web/directory/wp-content/plugins/wp-super-cache/wp-cache-phase1.php’

where /path/to/your/web/directory is unique to your system.

It is a DNS spoof and has nothing to do with Super Cache.

Add the following to your .htaccess file to get rid of it:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_HOST} !^domain.com$
RewriteRule .* – [F]
</IfModule>

Now Super Cache (Widget Cache and so on) will not be bothered, all that fake visitors will see is a 403 Forbidden page.

If you use multisite, make sure you have NOBLOGREDIRECT set (google it).

If you use www, make the following modification:

RewriteCond %{HTTP_HOST} !^(www\.)?domain.com$

Yes, it seems that Quick Cache puts it like this:

<?php define(‘WP_CACHE’, true);

Whereas otherwise it usually is far below.

Anyhow, fact remains that it is Super Cache that removes the entire line, even if it is Quick Cache that puts it where it shouldn’t be.

Speaking of Capital letters, it seems that super cache doesn’t care about capital letters in escape sequences. I have the following URI on my site:

/om-%25e4%25b9%258b%25e4%25b9%258e%25e8%2580%2585%25e4%25b9%259f

But sometimes, through stupid “normalization” by bots and clients, this becomes:

/om-%25E4%25B9%258B%25E4%25B9%258E%25E8%2580%2585%25E4%25B9%259F

This is cached as a separate instance by super cache.

Not a big deal, but something that can’t easily be changed on the htaccess level.

1.4.2 seems to work just fine.

I second that. Installing this version reverted the options I had previous chosen, for example “open in a new window” (which is really really an abomination from the past).

The plugin also automatically defaults to show “awards” for all commentators with 0 or more posts, but the supplied award icon is not registered until you actually go into the widget and save new values; merely updating it and thinking it would work out of the box makes it load “”, which defaults to the blog home page… x15.

I downgraded as a result.

There must be an option to reject awards entirely, and it should be on by default. Just setting number of comments to 2000000 is not good enough.

All bells and whistles should be off by default, don’t just take for granted people want to use it.

In wp-cache.php, on line 2390, you select all ID from the table posts where post_status is “publish” when caching in preload mode:

$posts = $wpdb->get_col( "SELECT ID FROM {$wpdb->posts} WHERE post_status = 'publish' ORDER BY post_date DESC LIMIT $c, 100" );

Thing is, not all items where post_status is “published” are of post_type = “post”, but also of post_type = “nav_menu_item”.

Caching nav_menu_item will generate a 404 error and slow things down. post_name for nav_menu_item is always the same as ID, that is a number.

To solve this, WP Super Cache must also check that post_type = “post” in its SQL statement:

$posts = $wpdb->get_col( "SELECT ID FROM {$wpdb->posts} WHERE post_status = 'publish' AND post_type='post' ORDER BY post_date DESC LIMIT $c, 100" );