Joost Schuur

Thanks, Siobhan. Probably going to go with a dedicated theme for this one now (specifically, this one: https://demo.herothemes.com/knowhow/).

Looks like you were able to get it working on the link you provided. Can you confirm how you resolved it?

So in a nutshell, while Xcache can not only cache compiled script opcode, but also the output, thus bypassing even executing the opcode, there is a slight overhead in invoking PHP?

Sounds like I’ll give advanced disk based cache a try then for my site.

Just for fun, I could do the following to use the transient cache to save repeated hits to the file system for non static page access:

function get_latest_stylesheet() {

	if (false == ($stylesheet = get_transient("ttidg_latest_stylesheet"))) {
		$stylesheet = "style.css";

		foreach (glob(get_stylesheet_directory() . "/style_*.css") as $filename) {
			$filename = basename($filename);
			if ($filename > $stylesheet)
				$stylesheet = $filename;
		}

		$stylesheet = dirname(get_stylesheet_uri()) . "/" . $stylesheet;

		// Cache the value for an hour.
		set_transient("ttidg_latest_stylesheet", $stylesheet, 3600);
	}

	return $stylesheet;

}

But now I have to delete the cache when I upload a new style sheet. Not a huge problem, I can automate a delete_transient() call in my deployment process too (I use git to push/pull theme updates).

Just figured I’d share this if someone stumbles upon this thread.

Thanks for the tip. Here’s what I ended up doing, with a style sheet naming convention of style_YYYMMDD.V.css:

function get_latest_stylesheet() {
	$stylesheet = "style.css";

	foreach (glob(get_stylesheet_directory() . "/style_*.css") as $filename) {
		$filename = basename($filename);
		if ($filename > $stylesheet)
			$stylesheet = $filename;
	}

	return dirname(get_stylesheet_uri()) . "/" . $stylesheet;
}

It defaults to style.css and is overridden by the most recently named style sheet. My header then just uses

<link rel="stylesheet" type="text/css" media="all" href="<?php echo get_latest_stylesheet() ?>" />

Since the site uses caching for its content, and there’s usually only one style sheet anyway, I’m not worried about a performance impact.

I’m trying out AsideShop (1.2) under 3.0.1 and can’t get it to work. After I’ve defined my template, enabled a category for it, turned on AsideShop and made a new test post to the asides category, I still see nothing.

How does the plugin know where to display its posts? I expected to see a widget to include in the theme, but there wasn’t any. The installation instructions don’t really mention to do anything more specific, but there’s got to be a shortcode or set of template tags to include. I tried dumping the template code into a ‘text’ widget, but that didn’t work either.

I’m using a TwentyTen theme with no caching plugins enabled on the local instance that I’m testing this on.

Looking at the PHP code a little bit, it looks like it makes use of filters on the_content. I have a custom filter of my own set up, but for the purposes of this testing, I disable the filter in case that conflicted. My main loop is still active and calls the_content just fine.

Thanks for clarifying, Frederick. I’ve switched over to using different hostnames for each blog instance now, and that does the trick.

If I could bring the conversation back to the pros and cons of child themes for a second. While it looks like the concept of PHP pages in a child theme directory overriding the parent theme is useful for simpler changes, it becomes less and less so the more PHP pages I need to update over the course of upgrading the original theme, right? Once you start updating things like header/footer/loop etc, your theme isn’t going to survive a partial upgrade when the parent theme gets all the new files, but some aren’t called up any more because you have child theme files that have precedence.

To me it feels like I’m stating the obvious here, but I wanted to double check that there’s not some other piece of behind the scenes magic that I’m missing.

I ended up using a different approach, where I add another filter to my theme’s functions.php that simply replaces the last closing p tag with my additional HTML (just the permalink in a hash symbol in this example) plus the closing p tag again. If anyone is curious, here’s a few details.

First off, the filter function code:

function asides_inject_utility_links($content) {
		// If it's an aside, find the last closing p tag and add our entry utility links to it.
		if(in_category( _x('asides', 'asides category slug', 'twentyten') ) ) {
			$html= '<a href="' . get_permalink() . '">#</a>';
			$content = preg_replace("#^<p>(.*)</p>$#isU", "<p>$1 $html</p>", $content);
		}
		return trim($content);
	}
	add_filter('the_content', 'asides_inject_utility_links', 11);

Key here was bumping up the priority on add_filter to 11, otherwise, it didn’t fire late enough for the p tags to already be in the content. Luckily mine went up to 11, so I had no problems there.

I’m using a few preg_replace modifiers (based on some tips in this blog post) here anlong with # as the delimiter, so I don’t have to mess up the expression with quoted slashes. ‘i’ is a case insensitive match (just in case), ‘s’ tells ‘.’ to span newlines and ‘U’ dials down the ‘greediness’, to prevent ‘.*’ from also matching until the end of the string, including the closing tag.

Since I’m handling my links this inside the filter, I stripped out the entire entry-utility div that is dedicated to handling the asides style (look for comments along the lines of ‘How to display posts in the asides category’).

I’m also experimenting a little bit with changing the style of the asides further, so that it’s clear they’re not regular posts

.home #content .category-asides p {
		font-size: 14px;
		line-height: 20px;
		margin-bottom: 10px;
		margin-top: 0;
	}
	.home .hentry.category-asides {
		padding: 0;
		margin-bottom: 20px;
	}
	.home #content .category-asides .entry-content {
		padding-top: 0;
		padding-left: 10px;
		border-left: 1px solid #d0d0d0;
	}

If anyone sees any problems with the code or has other suggestions, I’d be happy to hear them.

Finally, I’m also using another addition to function.php to make the links in an RSS

function asides_external_rss_permalink($permalink) {
	if($asides_url = get_post_meta(get_the_ID(), 'ASIDES_URL', true))
		$permalink = $asides_url;
	return $permalink;
}
add_filter('the_permalink_rss', 'asides_external_rss_permalink');

One thing to keep in mind is that even though the default asides style on the blog doesn’t use the post title, most news aggregators like to dispay something. So if your aside is a just commentary without a link, your title should be something brief enough that doesn’t sound too repetitive, so that your aside works with or without it. When you are using this to briefly comment on a link (AKA ‘Daring Fireball style’), then you need to find a way to have the non-RSS, web based view repeat the link. That means either introducing a linked title header after all, by adding a hyperlinked short phrase like ‘link’ at the end of your content or by just preceeding your content with the title in the same first paragraph, similar to Waxy.org. Since the whole point of asides is to not use up as much screen real estate, so that you can do a few of them, I chose to do the latter.

Of course, the latter means another change to our filter, to update the entry content within the enclosing p tags with the title, but given the above groundwork, that’s not too difficult.

I’ve tested it out on a DreamHost PS using ngnix and Xcache, and it works just fine, at least based on speed improvements and the footer info on pages.

If you’re using disk based caching instead of an opcode solution like Xcache, it’s simply a matter or changing one line in the SuperCache nginx instructions (lines 23-49 in that post). Just change line 40, so it reads:

`set $supercache_file /wp-content/w3tc/pgcache/$1/_index.html;

Your rewrite rule now matches the directory structure under which the cached files are created with W3 Total Cache.

I didn’t see any explicit reference to SuperCache creating wp-cache-xxxxx files for admin users, but I’ll take your word for it that it’s intended behavior. There’s some comments in the FAQ section about ‘WP-Cache vs Supercache files’, but no specific comments about logged in users.

Are you saying that logged in users fall back to another caching mechanism that generates these files?

I assume you are using the WordPress.com Stats plugin.

On the dashboard, under the Plugins menu on the left, look for ‘WordPress.com Stats’, and there will be an option called ‘Count the page views of registered users who are logged in’, which you should deselect.

This discounts any user that has logged in. If you allow local accounts, and use them for users to leave comments, they’re gone from the stats too. Generally though, this is fine for most blogs, but if you want more control, you can Google Anayltics and if you use Joost de Valk’s Google Analytics for WordPress plugin to insert the tracking code on your site there’s an option under advanced settings where you can decide which type of user to ignore (Admin, editor, author, contributor or subscriber).

Looks like I cleared out my screengrabs the other day, so I broke that link.

Earlier, the form to add your code simply didn’t appear when you clicked on the configuration link. However, I just tried it again after I reinstalled the plugin and as able to load up the settings area fine. Problem solved.