When I write HTML, running code through the W3C Validator is part of my process. If the code doesn’t pass the validator, there’s a slim chance I’ll consider that code ready for anything.
So after I upgraded this blog to WordPress 3.01’s Twenty Ten theme, I was mildly irritated to find that I had a few validation errors. I viewed the source code to investigate the offending lines of code, and noted that the code the validator cited was not in the source.
This phantom code led me to suspect that DOM scripting from a plugin caused the errors by inserting more code into the markup. That was it, and this evening I finally took the time to track it down. Here’s the scoop.
First, the phantom code that broke validation
Where was this code? Well, all 9 errors were in the same area of code: links to other websites (blogroll) in the sidebar. I wanted to see it for myself, so I opened the page and viewed the source code. I used the Find command and pasted in some of the code from the validator error message, but the Find came up empty-handed.
While the offending code was not in the served markup, the validator was certainly picking it up, so I went back to the validator to examine that code in more detail.
The value of the onclick attribute was the immediate tell for where this code came from. It was the Google Analytics plugin I’m using.
Investigating the plugin that caused the validation error
Google Analytics for WordPress is a fantastic plugin. It makes integrating Google Analytics easy, and it has some excellent advanced settings.
One setting is to track outbound clicks and downloads as events so they are are viewable in Google Analytics.
To test the theory, I unchecked that box, saved the settings, and revalidated the web page.
It passed with flying colors.
Validation error identified, but I’m actually curious about tracking downloads
For the time being, I’m okay with leaving that feature turned off. I’ll let the plugin author know about it and hope the problem will be resolved soon.
Yes, I lose a feature to get back to valid code. Perhaps there is a support group for this kind of behavior.
But in my defense, this is just a personal site. I don’t make any money on it, and my interest in tracking downloads is just curiosity. I only have a few downloads or outbound links I’m interested in, and I have nothing riding on that knowledge beyond satisfied curiosity.
Still, the entirety of this problem can be laid to rest on a simple, meddlesome, and empty
target="" attribute. That’s irritating.
3 responses to “Google Analytics for WordPress (version 4.09) trips HTML validation when tracking outbound links”
To be honest, should target even be generated by the plugin? Isn’t that just bad news waiting to happen?
I can’t say as I’m surprised by the plugin breaking validation though, I rarely see as strict adherence to valid markup as I’d like from other plugin authors.
Also, you’re still broken according to validator. http://validator.w3.org/check?uri=http://blog.davingranroth.com/2010/11/google-analytics-for-wordpress-version-4-09-trips-html-validation-when-tracking-outbound-links/&charset=(detect+automatically)&doctype=Inline&group=0
Feel free to disregard this comment. :p
Yeah, I agree, why add a target attribute where none was needed before?
And thanks for pointing out this additional validator issue. I didn’t check the individual blog post pages.
However, it is using a
charsetattribute on the script element where none is needed. As of the current W3C work on HTML5, you only use
charseton a script when the
srcattribute is also used, referring to an external script resource.