Murmatron 2

I think the first wpdb and cache shutdown is via the shutdown callback which fires in PHP4 and PHP5, and the second is the direct call to __destruct(). The second will only appear with PHP5.

I’m assuming that the references (e.g. global $wpdb) to them are invalid after the first event.

It’s pretty confusing though.

I don’t think this is a PHP issue.

/includes/cache.php (object-cache) registers a shutdown callback before supercache does. They get called in the order they are registered, so the object-cache dies before supercache.

It follows then that function calls from the supercache shutdown callback that access the object-cache (like current_time does via get_option) will fail.

Create a nocache-home.php in the wp-super-cache/plugins/ directory

Put this in it…

<?php
    if($_SERVER['REQUEST_URI'] == '/') $cache_enabled = false;
?>

Should work.

You have a conflict between WP-Cache and WP-SuperCache. You can’t use them both at the same time.

Remove the one that you aren’t using.

Personally, I prefer to give IE users an enhanced browsing experience by showcasing IE’s state of the art CSS extensions…

<!--[if IE]>
	<style type="text/css">
	body {
		filter:blur(add=false, direction=270 strength=10);
		-ms-filter:blur(add=false, direction=270 strength=10);
	}
	</style>
<h1 style="color:#99ff00; padding:0.5em; font-size:30pt !important;">Optimized for Internet Explorer</h1>
<![endif]-->

wp_cache_check_link() in wp-cache.php fails silently on Windows at line 960 due to
@readlink($wp_cache_link)

php readlink() doesn’t exist on Windows

It seems to me that since v0.8.3 the html comments have been causing a lot of confusion as to what is being served from where to the extent that a significant number of punters are doubting whether it’s working properly.

The problem that Donncha was trying to solve was not being able to tack different html comments onto wp-cache and supercache gzip files without gzipping each of them separately. It’s either gzip the content once, or gzip twice with different comments. Gzipping twice is a waste of cycles.

As you may or may not know/care; I have a [parallel|tangential] cache plugin based on WPSC under development and to solve the same gzip problem I pondered long and deep and finally elected to use a generic comment <!-- Served by WP-SuperCache-Plus - See X-WPSCP response header --> in every file and add a response header that specifies the extra info like Dynamic, SuperCache etc. on the basis that anyone who cares that much should be capable of using FireBug or Dragonfly to look at the response headers.

The variants that I use are:

X-WPSCP: Dynamic
X-WPSCP: Cache
X-WPSCP: Cache, mfunc/mclude
X-WPSCP: SuperCache (via “Header set” in cachedir .htaccess)

It takes a little extra effort to see the info, but there’s no ambiguity.

Just a suggestion.

Donncha,

I can replicate that easily logging in with multiple browsers, and to a lesser extent when not logged in. Neither scenario has anything to do with the browsers themselves.

The following are from Opera & Safari both logged in as admin on the same site:

Opera: WP Cookie check,admin|1225358221|aaa0fa7a513774eb2af8a6a09ebb7fb6,
Safari: admin|1224321519|1a689ac78c2fe15a07952c854d52ab23,WP Cookie check,

The hashes are different, but even if they were the same, the order of the cookies would cause separate cache files to be created, as would the different timestamps. The different cookie order comes (I believe) from the fact that Safari was logged in, whereas Opera was logged in, out and in again.

Fact: Multiple browsers logged in as the same user will almost certainly generate separate cache files.

I’ve also seen the following when logged in…

admin|1225358221|8228982bd4af22eb1476cb3f01dc1daa,WP Cookie check,admin|1225358221|aaa0fa7a513774eb2af8a6a09ebb7fb7,

i.e. Multiple user cookies with the same timestamp, but different hashes. This is usually short-lived; one of them will eventually disappear.

As for not logged in users; there is an issue with the default name of TEST_COOKIE in wp-settings.php which causes users who were logged in (or failed to log in) to be treated as though they are – i.e. no SuperCache…

if ( !defined('TEST_COOKIE') )
	define('TEST_COOKIE', 'wordpress_test_cookie');

Adding something like…

define('TEST_COOKIE', 'wp_test_cookie');

…to wp-config.php gets around that problem by removing that cookie from supercache’s regex radar and also removes it as a potential problem source with respect to cookie order for logged in users.

Fact: With the default TEST_COOKIE, a never-logged-in browser will generate a separate cache file from one which was logged in (or attempted, but failed).

If lots of browsers are logged in as the same user, as far as I can see; all bets are off, but I really think it’s a non-issue. How many end-users are going to be browsing the site logged-in with multiple browsers?

P.S. This is all on my dev site which is a WordPress trunk checkout with nearly everything using default values.

Your code is ignoring the existing query_string. Try:
query_posts($query_string . '&cat=13,14,15,16,17,18,22&showposts=5');

Looks the same in every browser I tried, including Firefox. The reason is this:

GET / HTTP/1.1
Host: www.prosebeforehos.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-gb,en;q=0.8,en-us;q=0.6,fr-fr;q=0.4
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive

HTTP/1.1 302 Found
Date: Sat, 04 Oct 2008 12:21:36 GMT
Server:
Location: https://www.prosebeforehos.com/wordpress/wp-content/cache/supercache/www.prosebeforehos.com/index.html
Content-Length: 354
Content-Type: text/html; charset=iso-8859-1

Your problem is likely the same as https://www.ads-software.com/support/topic/180699

Something in your server configuration is causing an external redirect.

In response to (1) and bearing in mind the fact that I’m not 100% clear on whether you’re using WP-Cache or WP-Super-Cache.

WP-Super-Cache will allow you to do (1) without messing with the source code of the plugin itself. WP-Cache2 does not (as far as I can see) allow for this.

Example of a WP-Super-Cache plugin to completely disable caching for logged-in users…

.../wp-content/plugins/wp-super-cache/plugins/nocache-logged-in.php
<?php
    while ($key = key($_COOKIE)) {
        if (strpos($key, 'wordpress_logged_in_') !== false) {
            $cache_enabled = false;
            break;
        }
        next($_COOKIE);
    }
    reset($_COOKIE);
?>

With WP-Cache2, you could hack the wp-cache-phase1 source code in a similar fashion since upgrades to the plugin aren’t much of an issue.

Insert into wp-cache-phase1.php @ Line 10 or thereabouts...

while ($key = key($_COOKIE)) {
    if (strpos($key, 'wordpress_logged_in_') !== false) {
        $cache_enabled = false;
        break;
    }
    next($_COOKIE);
    }
reset($_COOKIE);

With respect to (2), the short answer is ‘No’. When the cached content is pulled from the cache, it’s very early in the WordPress load sequence and there’s not much available to play with.

Maybe I’m missing something, but I don’t quite get the point of the semaphore at all.

The wp-cache filenames have an md5 with $_SERVER[‘HTTP_HOST’] and supercache files are saved in a structure based on HTTP_HOST so there is no inherent potential for different VHOSTS to be in contention. The scenario you describe arises purely from the use of the semaphore.

If the cache_writers_entry/exit were removed completely it seems to me that the worst that can happen is that the fopens fail because of blocking caused by simultaneous requests to the same HOST/URI, the cache file isn’t written for the second request but both clients get the content anyway.

Apache will not serve files from outside the document root (which the tmp directory certainly is) without additional conf or .htaccess directives which, unless they are certifiably insane, Dreamhost will not allow you to change.

Short version – It’ll never work unless Dreamhost’s server config is very wrong.

OK, I’ve been busy hammering a subset of my dev-site with multiple wget sessions at a rate of about 10 requests/sec (that’s much more than the PHP engine can serve, and much less than Apache can serve statically – it seemed a to be a fair balance) with very short cache expiry times whilst browsing and commenting and removing posts etc.etc. and didn’t get any junk or lag so I’ll post a link to a patch for anyone else brave enough to try it.

Using OS X, finding files with BOMs shouldn’t be a problem…

cd /the/path/to/your/wordpress/wp-content
grep -r --include=*.php -P "\xEF\xBB\xBF" *

That should scan all the PHP files in your plugins and themes and list any that require attention.

As for OSX text editors – I’m afraid I know nothing.