teknohippy.net

I shot a 546 Portsmouth again yesterday night. That’s four in a row now. Shot six 7s, rather disappointing. Without them I’d have made the 550 Winter goal I set myself. Not much of the Winter season left now. Next chance is Monday evening, a little more concentration and we’ll get there.

During the aftermath of the footer hack, and becuase I’ve started to take fiction writing seriously, I’ve decided to split my blog into two. teknohippy.net is pretty much what it has been and anything about writing is now on http://iainmnorman.com.

Well I’ve learned my lesson regarding critical security updates. I’ve been running a couple of version behind the latest for months now.

I then spotted a whole bunch of 404s in Google’s webmaster tools. Really odd links that shouldn’t even exist on my site. So after investigating I discovered that my footer.php was full of spam links.

So I deleted them. Next time I checked they had come back. So I exported my posts as XML and ditched both the WordPress and the database. I then reinstalled the lastest version of WordPress and imported my posts. Next time I will upgrade when a security patch is realeased!

The only remaining problem is the damage done to my search engine listings, I have fallen off the map completely. Googlebot still hasn’t revisted my site since I repaired the damage, so who knows how long before things correct themselves, I have made a resumbission request just in case I’ve been blacklisted or something.

If like me you run an installation of DasBlog in a sub folder/app then you may run into this error message when you start using ASP.net 2.0 membership/role providers in the base app.

The SSE Provider did not find the database file specified in the connection string. At the configured trust level (below High trust level), the SSE provider can not automatically create the database file.

All that is required to fix is to add:

<roleManager enabled=”false”/>

to system.web in the DasBlog web.config.

As I’ve previously written about, I’ve been having some trouble with PayPal PDT ( Payment Data Transfer ) and Google Analytics e-commerce tracking.

If you’ve added Analytics to your PayPal thank-you page, and used PDT to get the data to be sent to Analytics and got that working nicely then you will have discovered that not every sale gets tracked, because not every shopper can be guaranteed to land on your thank-you page.

Now I’ve been doing some testing on an idea to get around this using IPN. The basic premise is this.

1. Google Analytics works through a request for __utm.gif from the Analytics server, to which is attached all the tracking information. 
2. On the page just before leaving for PayPal set the analytics script to local only.
3. Use url rewriting to hide a script behind your local __utm.gif.
4. Record all the details for the request for the local __utm.gif in a database, referenced to the session.
5. Send the session ID information through PayPal’s custom variable.
6. User finishes sale.
7. IPN script picks up sale, checks session ID and looks up the stored request.
8. IPN script rebuilds request and forwards to Google’s __utm.gif.

Now to test this before getting involved in databases and IPNs I just made two pages. One with Analytics set to remote, the next page with analytics set to local. Then I made a local __utm.gif just forward the request for the remote __utm.gif through a server side HTTP request.

Wait a day.

No joy, nothing showing up for the e-commerce tracking, or the visit to the second page, just the first page visits where the script was set to remote.

Then I fiddle for weeks trying to improve the request. Adding all the cookies etc. etc.

No joy.

So I took a look at the urchin.js file to determine whether or not the local request was being built any differently to the remote one. And it was. If you have a look through urchin.js searching for the local/remote variable (forget the name of it right now) then you’ll see that there are extra things appended to the end of the querystring for the remote call to _utm.gif. The extra stuff is the content of all the analytics cookies.

So I fiddle urchin.js and made a local copy that built the same request for remote and local, including all the cookie data. I had a couple of people hit the two pages and a day later…

Success, there is e-commerce transaction data, items, totals, everything in Analytics now.

I used different sources and the like for a couple of test and those have also come through. Even more surprising though is that where I have had other people test the two pages for me, their locations have been tracked and assigned to the e-commerce transactions correctly. Which I didn’t expect as it’s always the web server making that request, and it’s not moving around!

So that’s something to work on. I’ll keep you updated on the next stage of implementation.

This hasn’t been easy, so if any of this info saves you or your company time, then I am now shamelessly begging.