I recently had a complaint from users of a site I support that the browser’s back button did not work when they visited the site. Further research showed that this is only happening on IE8 and IE9 (and possibly earlier versions that I’m too lazy test) and it is indeed a problem. It appears that the issue is an incompatibility between Internet Explorer and Google Adsense and is pretty much a problem across a significant portion of the web as Adsense is used on so many sites (like this one).

The issue isn’t that the back button doesn’t work…it actually is working. The real problem is that IE is adding every loaded advertisement as a new page loaded and updates the history accordingly. This means that every time you press the Back button, you are moving back through IE’s history of the ads loaded on the page. Once you’ve cycled back through every ad that has been served, pressing Back one more time will finally take you back to the previous page. On the site in question, it takes 11 clicks of the back button to go to the previous page. I’m planning on poking around a bit more but it really appears that there is not a known solution to this problem yet.

As serious as this is, I did find it amusing that the AdSense terms of service expressly forbid serving ads on a page where the navigation buttons are not provided, yet it is their code that is rendering these buttons inoperable on Internet Explorer:

Ads are not permitted in any window that is not initiated by a user’s click. Additionally, we do not permit ads to be placed in any window which lacks navigational controls, including back and forward browse buttons, and an editable URL field. AdSense ad code may also not be implemented on webpages where navigational elements have been removed.

In their defense, it does just state that the navigation buttons have to exist…and not that they have to work.

This is a pretty big deal since IE7 and IE8 have 3.2% and 10.7% of the browser marketshare (according to w3schools). Your site not rendering properly for 14% of your traffic is a significant problem.

However, this doesn’t mean that using HTML5 is not possible. Thanks to the HTML5 Shiv, very basic HTML5 now works in IE7 and IE8.

Now if only tables, transparent backgrounds and z-indexes worked on IE7 and IE8.

Deep in wilderness settings, detached from persistent electronic information input, I am a quieter, humbler, more alert, more appreciative, more empathetic, more reflective being.

Beautiful day today – time to step away from technology and take a walk.

Why on earth haven’t I thought of disabling or changing their function before today, I have no idea. But it is easy:

Disable Caps Lock in Windows
Disable Caps lock in Mac OS X

A complicated theme will use extra queries and this is acceptable if you need extra loops or recent comments or other special items. However, the key issue in this case is a theme framework with its significant overhead coupled with a sidebar employing 10 widget sections and over 30 different widgets.

I don’t want to sound like a broken record, but themes that allow the user to change settings within the WordPress interface generate overhead. Widgets generate additional overhead. For a high traffic site or even a significant burst of traffic, this can bring a site to its knees.

How can you fix this problem? Well, optimally, you recode the entire template so it doesn’t use any widgets or settings stored in the database. Is this painful, expensive and unreasonable? Yes, yes and no. What if you are not currently in a place where recoding the template is reasonable? Well, then you try to optimize what you can and get the query count as low as possible.

Most themes store settings in the WordPress options table and access them using the get_option() function. The theme set I’m trying to salvage uses get_option() 162 times. Finding a way to reduce the impact of these calls is probably a good place to start. Simply getting all the theme options in a single query and using cached values instead of reading them when needed should help reduce the number of total queries on each page.

To do this, first we need to figure out how to identify the theme specific options. Usually there will be a prefix on each option name, so I’ve created a new function in functions.php that reads all the options with that prefix and then I call it:

function theme_cache_options($prefix) {
  global $wpdb;
  global $theme_cached_options;

  $sql = "SELECT option_name, option_value FROM ".$wpdb->prefix."options ".
        "WHERE option_name LIKE '%s' AND blog_id = %d";
  $prepared_sql = $wpdb->prepare($sql, $prefix.'%', get_current_blog_id() );
  $theme_cached_options = $wpdb->get_results($prepared_sql, OBJECT_K);
}
theme_cache_options(‘cow_’);

Second, we need a function that lets us read the cached option value:

function get_cached_option($key) {
  global $theme_cached_options;
  $result = isset($theme_cached_options[$key]) ?
        $result = $theme_cached_options[$key]->option_value : '';
  return $result;
}

Finally, we need to go through the theme itself, and change every get_option() call that references a theme setting to get_cached_option(). Be sure not to change any option requests that do not start with the prefix specified in the theme_cache_option() call.

Does this help? Well, it helps a little. With the site I’m working on, I’m seeing roughly a 10% reduction in the number of queries. Worth it? I think so.

Final note for theme developers: If you are going to store theme options in the options table, there is a fourth parameter for the add_option() function that you should really be aware of. If you set $autoload to ‘yes’, then WordPress will automatically load and cache that option when it fires up. This means that get_option() calls for any option that was created with $autoload set to ‘yes’ will not generate any additional queries.

Intent intent = new Intent(Intent.ACTION_SEND);
intent.setType("text/plain");
intent.putExtra(Intent.EXTRA_TEXT, title + "\n" + content);
this.startActivity(Intent.createChooser(intent, "Share..."));

This brings up a selection dialogue which presents the users with every app they have installed on their device which handles a “text/plain” type request. For most scenarios, this is the best way to go, although sometimes the list of applications can be a bit overwhelming.

However, I needed a “Tweet This” button related to the content that was being displayed. Searching the net yielded a significant number of people asking exactly how to do this. Some responses just chided the question, and advised strongly that the standard intent and letting the user choose from what they have installed is the right way to do it. This isn’t bad advice, but I already have a social share button in this project that does exactly that. The project requirements also include a dedicated “Tweet” button and it makes no sense for a button labeled “Tweet” to pull up a list that buries my Twitter client (or clients!) among Gmail, Facebook, Google+, Dropbox, Evernote, LinkedIn, GoogleVoice, and others.

This post details how I managed to pull it off. I’m very aware that the solution is far from perfect and there is much room for improvement. It doesn’t support every known Twitter client out there but it can be extended as needed. The bottom line is it works, and the “Tweet” button actually tries to send a tweet. After spending the better part of a day putting this together, I thought I would share it here and hope it helps someone else out also.

Step 1 involves building a list of supported Twitter clients. This list can be easily expanded once you know the intent activity of any client. I did this by installing the 7 clients in the list, looking at the list of intents and then adding them to the list and testing each one. I hate hardcoding anything and I will probably move this list to arrays.xml down the line, but there really is not a better way to do this. All of these save one (UberSocial) support the generic “text/plain” intent type, which yields no way to identify a twitter client other than knowing the activity name in advance. (By the way, UberSocial supports the “application/twitter” intent type, which is a cool idea, however they are (as far as I know) the only client that supports this intent type which makes it pretty worthless at this point.)

Here is the code, which stores our supported Twitter Client list in a Map<String,String> named knownTwitterClients:

// Build list of Known Twitter Clients
private void buildKnownTwitterClientsList() {
	knownTwitterClients = new HashMap<String, String>();

	knownTwitterClients.put("Twitter", "com.twitter.android.PostActivity");
	knownTwitterClients.put("UberSocial", "com.twidroid.activity.SendTweet");
	knownTwitterClients.put("TweetDeck", "com.tweetdeck.compose.ComposeActivity");
	knownTwitterClients.put("Seesmic", "com.seesmic.ui.Composer");
	knownTwitterClients.put("TweetCaster", "com.handmark.tweetcaster.ShareSelectorActivity");
	knownTwitterClients.put("Plume", "com.levelup.touiteur.appwidgets.TouiteurWidgetNewTweet");
	knownTwitterClients.put("Twicca", "jp.r246.twicca.statuses.Send");
}

Step 2 is comparing our list of known clients with apps actually installed on the device. This is done by reading through the Intent Activities on the device and storing any that match our list of known Twitter Client. This list is stored in a Map<String, ActivityInfo> named foundTwitterClients.

// Detect Twitter Clients
public boolean detectTwitterClients() {
	buildKnownTwitterClientsList();
	foundTwitterClients = new HashMap<String, ActivityInfo>();

	Intent intent = new Intent(Intent.ACTION_SEND);
	intent.setType("text/plain");
	PackageManager pm = getPackageManager();
	List<ResolveInfo> activityList = pm.queryIntentActivities(intent, 0);
 	int len = activityList.size();
	for (int i = 0; i < len; i++) {
		ResolveInfo app = (ResolveInfo) activityList.get(i);
		ActivityInfo activity = app.activityInfo;
		if (knownTwitterClients.containsValue(activity.name)) {
			foundTwitterClients.put(activity.name, activity);
		}
	}
	return false;
}

Step 3 is a method that resolves the ComponentName object that will be used to launch a tweet request. Notice that I’ve added an extra string named preferredTwitterClient. This code grabs the first found Twitter client from our list and sets that as the client that will be used. Then it checks to see if a preferredTwitterClient is specified, and if that app is installed on the device, then that client is used instead. The thought behind this feature is to eventually have a settings option that lists the available Twitter Clients on the device and allow the users to pick the one they prefer.

// Resolve the twitter client component name
public ComponentName getTwitterClientComponentName() {
	ComponentName result = null;

	if (foundTwitterClients.size() > 0) {
		ActivityInfo tweetActivity = null;
		for(Map.Entry<String, ActivityInfo> entry : foundTwitterClients.entrySet()) {
			tweetActivity = entry.getValue();
			break;
		}

		if (preferredTwitterClient != null) {
			String activityName = knownTwitterClients.get(preferredTwitterClient);
			if(foundTwitterClients.containsKey(activityName)) {
				tweetActivity = foundTwitterClients.get(activityName);
			}
		}

		result = new ComponentName(tweetActivity.applicationInfo.packageName, tweetActivity.name);
	}

	return result;
}

Step 4 is simply coding the “Tweet” button handler method. Notice that if none of our known Twitter clients are found on the device, this method simply fires off the standard “text/plain” application chooser. The variables title and permalink are globals in the activity; you can set the Intent.EXTRA_TEXT to whatever suits your application.

// Tweet button handler
public void onTweetClick(View v) {
	ComponentName targetComponent = getTwitterClientComponentName();

	if(targetComponent != null) {
		Intent intent = new Intent(Intent.ACTION_SEND);
		intent.setComponent(targetComponent);
		String intentType = (targetComponent.getClassName().contains("com.twidroid")) ?
			"application/twitter" : "text/plain";
		intent.setType(intentType);
		intent.putExtra(Intent.EXTRA_TEXT, title + "\n" + permalink);
		this.startActivity(intent);
	} else {
		Intent intent = new Intent(Intent.ACTION_SEND);
		intent.setType("text/plain");
		intent.putExtra(Intent.EXTRA_TEXT, title + "\n" + permalink);
		this.startActivity(Intent.createChooser(intent, "Share..."));
	}
}

I hope that helps. The solution would be much cleaner if there was an intent type that identified Tweet actions. Ideally, every client should support both “text/plain” and “application/twitter” intent types – which would eliminate the need to manually build a list of known twitter clients – a significant improvement to what I’ve done here.

Future: I’m planning on adding a preference selector where the user could select the installed client they prefer, but another really nice idea would be to instead display a selector list just like the createChooser does but that only lists Twitter Clients.

If your favorite Twitter Client isn’t in the list and you want to do the research and find their intent activity, post it in the comments and I will add it to my knownTwitterClients map.

I’ve worked with WordPress since it first came out, and I’ve supported a number of very high traffic sites. The items below are what I’ve learned about making WordPress work better and faster:

Actions that are Free (or Mostly Free)

Actions that cost money

I hope at least some of that is new information and helps you make sure your site delivers your content as fast as possible. I know some people will disagree with some of this and I fully expect hate mail from some who either develop or employ Frameworks, which is fine. The point of this post was not to please everyone, but simply to take a critical look at anything that adds overhead to WordPress and ways to reduce it.

Hat-tip to Grek Mankiw

Can a Software Update Quench Kindle Firestorm?
The Kindle Fire is selling big, but some buyers are not satisfied. This update is supposed to help. #SlowBurn

Google’s Response to Siri is Codenamed Majel, Could be released by End of Year
I predict this will result in another lawsuit by Apple.
I also predict that the Washington Apple Commission will someday be the target of a lawsuit by Apple. #DontCopyUs!

Firefox is too big to link on 32-bit Windows
This is why I, a huge Firefox proponent from the beginning, abandoned Firefox entirely a little over two years ago. #Bloat

Similar to the Pharma-Hack, there is a new stealth hack which affects compromised WordPress sites and most people have no idea their site is infected. The reason for the ignorance is that the hack doesn’t affect any content on the infected site – except for pages delivered to googlebot. For those pages, it injects “Free live streaming porn – ” in front of page titles which gives nasty search results for innocuous content.

Take a look at these search results: google search for: “Free live streaming porn”. (Link is SFW).

About 11 million hits and if you read the summary content, most are blogs or pages from a WordPress installs that have search results that are injected with a bogus title and keywords. (Either the hack does not target Bing and Yahoo, or hacked pages end up futher down in the result set for those search engines, at least that is what I saw on those sites with the same search.)

So how do you know if your blog is one of these hacked sites? Do the same google search with the site tag:

“Free live streaming porn” site:blogrescue.com

Mine comes up clean, but it is probably a good idea to check yours. If you are infected, then you need to deal with the issue right away, and then comes the agonizing wait for googlebot to recrawl these pages and replace the damaged pages with the real version.