I wanted my blog to support the tracking provided by 10³bees, so that I could track how people got to my blog. According to their own site:

It’s an online service for webmasters, bloggers and internet marketers that is highly focused on natural search engine traffic analytics. It provides tons of detailed real-time statistics and in-depth information on the search terms that drive targeted traffic to your websites.

Anyway, I found no reference to an existing WordPress plugin, so I decided to roll my own. After all, it’s no complicated stuff: just allow the user to enter the 10³bees script and have it display in the page. Currently, 10³bees advices to put the code in the footer.php for your theme. While that works, you have to do the same every time you switch themes. Not handy.

And so, here’s the WordPress 103-bees plugin. It works really simple: download the file, extract it to your plugins folder, activate the plugin, go to options/103bees and paste the script that 10³bees provides. And you’re done.

Happy search analysis tracking.

Nice, I got Clean Urls working in Drupal running on IIS7.
I had to write a (partial) implementation of mod_rewrite to do it, but now it works.

I’m extremely pleased.

I’ll post more info on this later, after I can consolidate my libraries a bit.

I was writing my own ConfigurationSection class, and wanted to be able to both define settings inline (in web.config, in this case) or in a separate file. Also, I wanted to reference the external file without specifying a full path in the config file. Mainfully because full paths make transferring configs to production machines harder because the base path is (most likely) different on the development machine that on the production machine. And so I wanted to do:

But also:

(config params here)

Turns out there’s no easy way to get the path of the source file when in a ConfigurationSection class. The docs mention the ElementInformation property, which has a Source property. That property should be set to the source filename of the configuration section. Except: it doesn’t. Of course, I could resort to using HttpContext and Server.MapPath(“/web.config”) or something alike, but that adds a dependency to System.Web where it’s not really necessary (although the code will surely run in an ASP.Net environment, so I could use this approach). Also, I want to be able to use multiple web.config files in separate directories, and that would require me to build logic to search the directory hierarchy for the correct file. That only complicates matters, and it’s probably highly inefficient too. Through Reflector I found out that the XmlReader you get when overriding the DeserializeSection() method on your ConfigurationSection also implements the IConfigErrorInfo interface. That interface has 2 methods defined:

namespace System.Configuration.Internal {
public interface IConfigErrorInfo {
string Filename { get; }
int LineNumber { get; }
}
}

Hah, that interface has a Filename info. And it’s set too, when deserializing the section content. Nice.

And so you can just say:

IConfigErrorInfo info = reader as IConfigErrorInfo;
if (info != null && !string.IsNullOrEmpty(info.Filename)) {
realsrc = Path.Combine(Path.GetDirectoryName(info.Filename), src);
}

I guess that’s not the intented use for that class, but at least it works.