OpenLinkz

I had a bunch of trouble toward the end of last week with my live stock quote widget that retrieves stock prices from Yahoo every 30 seconds throughout the day.

Having run into problems with the WidgetBox proxy service that allows widgets to retrieve data from other domains I had converted the widget into a Google Gadget. I then wrapped the Google Gadget within the WidgetBox widget so all those folks who were using the WidgetBox widget wouldn't be left with a non-functioning widget.

Last week, the Google Gadget began acting up. Using FireFox and Firebug, I was able to determine that the response from Yahoo in a simple CSV format was still functioning properly but the callback wasn't being executed within the gadget to actually read the response. I use the simple _IG_FetchContent function to execute the request and process the response.

In my experimenting, I discovered that using a Yahoo Pipe and rendering the output as JSON worked perfectly. Still, this seemed like too much overhead for such a simple request.

As it turns out, I had to make an adjustment to the URL at Yahoo that is used to request the stock price data. Where previously I used the following URL:

http://finance.yahoo.com/d/quotes.csv

Now I have to use this URL:

http://download.finance.yahoo.com/d/quotes.csv

If you type these URLs into your browser (with the requested symbols and request parameters), both of them would return the requested data. I can only think that some kind of redirection was taking place on the Yahoo site that made the Google Gadget function reject the response.

In summary, it seems these cross-domain calls can be awfully touchy. I apologize to any users who experienced an outage as a result of the problems in this widget. Hopefully, both Yahoo and Google will avoid making any changes for a while.

I recently installed a widget on my blog and it turns out that it was causing intermittent problems in Internet Explorer.

I was able to detect this situation because I had several AdSense ads in various positions on the page. I have a link unit at the top of the page, a regular banner/text ad a little further down the page, a skyscraper in a sidebar and another link unit at the bottom of the page.

I also use Google Analytics to track traffic to the blog. The Analytics code is installed at the bottom if the page. Analytics showed what seemed to be a falling off of traffic but there were no clues as to why.

Looking at the AdSense reports, however, some hints began to emerge. When reviewing the performance of the various ad channels (each ad is set up as its own channel), anomalies began to appear. Lots of impressions for the ad at the top of the page, 20% less impressions for those ads further down the page. This tipped me off that the page was not rendering completely.

Knowing that the page was not rendering completely suggests that some active component on the page was hanging up the browser. Some testing in both FireFox and Internet Explorer soon narrowed the problem down to IE. Then I began to eliminate the most recent widgets added to the page (there weren't many) which soon led me to the problem.

In summary --

It doesn't hurt to put a few AdSense ads in various positions on your blog or web pages, especially unobtrusive link units. It is important, though, that each ad be set up with a separate channel. The AdSense reports can then be used to ensure that the pages are rendering completely. And, of course, you can also more precisely monitor how the various ad positions are performing for their primary purpose as ad inventory.

With all the Javascript that many blogs and web pages are carrying, it is not unusual for certain sections of pages to encounter problems. The fine grained reporting provided by AdSense provides a good way to monitor and troubleshoot your pages.

Lately I have been switching the standard AdSense ads to the new managed ad units on both of my blogs (this one and blog.trade-radar.com). Some of these ads are coded directly in the blog template rather than inside a Blogger Gadget or Widget. A good example of where this kind of coding is required is the sliding ad panel that rises from the bottom of the browser window.

I have also been rolling out a redesign of the TradeRadar blog template. The redesign has required me to make a number of other kinds of changes directly to the template code itself.

Just this week, however, it seems like Blogger has started evaluating Google AdSense code and making undesired changes whenever I save the template.

This is actually the second phase in an aggravating series of events related to inserting AdSense code directly into the blog template.

Problem #1 --

The first problem I encountered had to do with the symbols for Javascript comments. When copying the ad code from the Google AdSense site, the variables that define the ad parameters are surrounded by Javascript comment symbols. Leave the comments in and the ad doesn't work. Take the comments out and the ad works fine.

This seems to be a Blogger situation only. Paste the standard ad code into any web page and it works fine with no changes. Paste the ad code into a Blogger template and it doesn't work.

The solution I have used to date is to delete the comments. Unfortunately, this now leads to the second problem.

Problem #2 --

Blogger doesn't recognize the format for managed ad units. If the ad unit code is surrounded by comment symbols, Blogger will not mess with it. As described above, however, I have found that I needed to remove the comment symbols in order to make the ad code work.

When the ad unit code is not surrounded by comment symbols, Blogger interferes with the code, trying to add a value for the AdSense publisher ID into the google_ad_client variable. This, of course, messes up the ad completely.

The workaround --

I took the Javascript variables that the managed ad needs and saved them into a Javascript file. I uploaded the file to one of my web sites. Then I used a simple script tag to retrieve the file immediately before the Google script tag that activates the ad.

This fixes the problem for now. Of course, it requires that you have your own domain where you can store your Javascript file.

Is anyone else encountering this problem? Do you have a different or better workaround? Feel free to leave a comment and let us know how you are handling this situation.