You can’t use Google Analytics on wordpress.com

I wish I knew this before I spent $12 on a custom domain for blog.zoopcast.com. You can’t use Google Analytics on a WordPress.com site.

I think the advantages of hosting the blog on their infrastructure outweigh the inconvenience of not having all metrics in one place (at least at this early stage), but it sure is an inconvenience.

Hopefully the WordPress.com Stats feature is good enough. From what I’ve read on TechCrunch though (and this is what sparked that whole “RSS is dead” fight last week), the stats that WordPress.com gathers don’t always match up with Google Analytics.

IE compatability issues with WordPress

There are a few problems with WordPress when working with IE. They’re kind of annoying, so I will look at fixing them when I can be bothered.

One I noticed today occurred when I wanted to create a link using the keyboard shortcut Ctrl+K after selecting text:

TinyMCE error IE7

It looks like it fails at this point (starting at line 28 of link.js):

// WordPress -- next 3 lines
document.forms[0].href.value = tinyMCE.getWindowArg('href') || 'http://';
document.forms[0].href.select();
document.forms[0].href.focus();

Let’s try this again. What is document.forms[0].href under IE7? It’s an <input /> tag. It’s the field that accepts the URL of the linked-to page. Let’s see whether it’s invisible or not enabled. <input /> tags definitely do accept the focus. The tag itself is visible and enabled, so it must be one of its parents. I guess the simple solution is to find the part in link.js that makes it visible, and put this .focus() call after it.

OK, it’s not as simple as that, because the code that makes the popup visible is called from an event handler. The onLoad() function in tiny_mce_popup.js, to be precise. It’s part of the TinyMCE_Popup class. I guess in IE7 the load event is called later than in Firefox? Right, well, it turns out it’s document.body that has display: none.

(I just checked in Firefox and there is no error at all. That’s good news.)

Ok, before the aforementioned line I added:

document.body.style.display = '';

Let’s see what happens. No error message! But the focus is not set. So it really has the effect of not setting the focus at all. But let’s think a minute. We want there to be focus whenever the insert link form is loaded. So why not put the set focus code in that load event? Actually, I think it is already being called from there, and it’s not working.

Never mind. I have fixed the problem I came to fix. I will fix the other problem another day.

One problem I have is that you can’t use the <code> tag without going into HTML mode. Must fix that.

Perhaps WordPress MU needs too much customisation

After a bit more experimentation, it looks like I might need to hack around with WordPress MU a bit more than I originally thought. Which suggests that perhaps it’s not the best thing to use for the travel blog site.

Stuff that’s very important is the ability for users to upload photos into their blogs inline easily (and not by uploading first and then adding the uploaded photo to the post) and a fixed list of categories, to be used to associate posts with places. Apparently WordPress has “global categories” but there is no common list of categories. Instead, if a user creates a new category with the same name as someone else’s category, they will become associated. This probably stems from the fact that WordPress MU is based on WordPress proper, which doesn’t have any support for multiple blogs and this was the easiest way to provide such a feature.

Also, a big problem with WordPress MU is that it doesn’t work very well with Internet Explorer. The WordPress crew also seem to have some sort of vendetta against IE, putting a link to a web site encouraging you to switch browsers at the bottom of the admin page. It’s kind of arrogant really. They’re probably saying “don’t use IE because it’s bad*” because they don’t want to say “we’ve only made this work with Firefox et al”. There’s also no use complaining that IE doesn’t implement standards properly, because IE is by far the most used browser. You have to e pragmatic. (* The linked-to site talks about security problems with IE.)

So, I shall now head back to my feature requirements list and evaluate some other platforms as well. Drupal and ELGG seem to be in the running as well as WordPress MU.

Customising WordPress MU

Last year, before my trip to France, I thought about starting a web site where anyone can set up a blog about their travels. Plenty of them exist already. None of them are any good!

WordPress, which my blog now runs on, is pretty good and mature. They have a multi-user version, called WordPress MU, which would suit me nicely. It’s very extensible through a plugin architecture, so it should be relatively easy for me to add some decent geotagging. I will chronicle my efforts here.

WordPress has two classification mechanisms: categories, which are a fixed (more or less – by default you can add categories at any time) list, and tags, where you just type whatever tags you want. I want to disable (sort of) categories, and let users only use tags. I say “sort of”, because the categories are going to be a site-wide hierarchical list of places. Users won’t choose the place through the category hierarchy. Instead, they will type the name of a place and the Google Maps geocoder will look it up for them. The coordinates of the article will be saved, and the post will be categorised automatically. That’s the idea, at least. I will reuse the geocoding interface used for Zemobo.

So my first task is to remove the ability to select a category when writing a post. This will also have to be removed from the RPC thing that applications like Windows Live Writer (which I am using now) use. No idea how to do that. I think it will actually involve hacking the existing code rather than using plugins.

You can follow my progress here: http://arunstephens.com/category/travel-blog/.