When exactly does doPlugins run?

In a meeting a couple of months ago, André Urban (a seasoned colleague of mine) and I got into a sudden and unexpected argument about when exactly s.doPlugins is called.

I was convinced it was called as a result of calling either s.t() or s.tl(), while he says it was also called everytime a visitor clicks anything on the page.

Funny enough, he was able to show me on a simple page.

Since this was completely against what I thought I knew about how the darn thing works, I decided to dive into this a bit deeper. Let’s see who was right!

doPlugins

As a refresher, the doPlugins method is defined inside the s_code.js or AppMeasurement.js file. It is a callback method that allows for a considerable amount of automation in your tracking setup.

Traditionally (as in: pre-DTM), we used it to put Javascript that would grab campaign tracking codes from URLs, call plugins, or do other useful things. Anything that would potentially apply to all pages on your site, we used to handle in the doPlugins method.

While most of this can be done directly in DTM (or whatever Tag Management System you use), there are still cases where you’d use doPlugins, the biggest one of those being a migration. It is so much easier to keep your doPlugins method when you move everything into DTM, than it would be to avenge it in DTM.

So, where do we start our investigation?

Use the Source

Step 1: let’s look into the code!

The good old H.27.5 code contains exactly one call to s.doPlugins. Given how the H-code is built, I am inclined to first look at the new 1.5.3 code, which is much more easily readable. The three occurrences I find in there contain a comment, a clause in an if-statement, and a single call.

Cleaning up the Javascript a little bit shows that the call sits within the t() method, and that tl() ultimately calls t(), too. Sounds like I was right!

Then again… I am assuming that t() & tl() only ever called explicitly, either on the page itself, or by some code injected into it. What if I’m wrong?

A short burst of hectic CTRL-F’ing shows me that there are indeed calls to track() inside the AppMeasurement.js file itself! What on earth?

But it makes sense.

Remember that you can configure whether you want automatically track exit links, downloads, and normal links for clickmap? Well, somehow, the code needs to be able to do that. And so it installs event handlers, and inside those, it calls track() (which is an alias of t()). Makes perfect sense, in fact.

I’m still thinking I’m right at this point. And I’m not going to go into all the methods that I find. Some of them are beyond my grasp. I’m not a programmer, after all.

Debugger

So, let’s look at a page through the debugger or the Console.

We’ll make this easier by making a doPlugins method which outputs something into the Console:

s.usePlugins=true
function s_doPlugins(s) {
	// purely for testing purposes
	console.log("doPlugins has been called!");
}
s.doPlugins=s_doPlugins

Then we’ll load the page, maybe click on it a couple of times, and check the Console.

Oops… doPlugins does indeed get called when I click on the text!

So there are clearly circumstances under which doPlugins is called even though no actual tracking call is being made. Sounds like André was right, then.

Although I could still claim that because t() is called, I was “sort of right”, right? Right?

Also, setting

s.trackDownloadLinks=false
s.trackExternalLinks=false
s.trackInlineStats=false

makes no difference!

Legacy

I don’t like finding out that something I took for granted for years was utterly wrong. So maybe this is an AppMeasurement.js thing? Maybe the old H-code did/does it differently? Let’s test…

Ha! It does not call doPlugins on clicks!

This is a very good illustration of why it is dangerous to trust an expert, isn’t it? Some experts (like my colleague André) keep up with the changes and adjust their internal model, while others (like me in this case) don’t.

Actually, I suggest that experts shouldn’t trust themselves, ever. Always go back on your assumptions and your experience when you work with technology!

Update: André can easily reproduce the “doPlugins called everytime” behaviour with H.27.5 code, so this is even more a reason to double-check on your deployment! Seems like we haven’t found out exactly what is going on, yet.

Update 2017-08-14: The behaviour is normal and “works as designed”. Just want to document that here (because it came up on a project recently 😉 )