I came across some interesting behavior when calling document.write multiple times. The first time I called it was fine, but if I called it again in a setTimeout, the page would go blank. Turns out that it’s because once the page loads and fires document ready event, it doesn’t know where the current cursor is. This causes the browser (happens in at least IE and FireFox) to start the page over from scratch, thus showing a blank screen.

So, don’t make the javascript call document.write after the page has loaded!

All of their databases are packaged with something called the EZDB system. I’m not sure what that is, but I can vouch that it made my database installation super simple. After you download the database, just find the file for your database (at the moment the support mysql, microsoft sql server, microsoft access, oracle, excel and CSV – comma separated values). That file will be ready to use as is or it will be the only file you need to set up your database (ie, sql insert statements that you just need to upload to your server).

I wanted to remove ALL javascript and css from the head, but still call the wp_head function since it loads other stuff (meta, plugins, etc). Most advice tells you to use wp_deregister_script() and wp_deregister_style() to individually remove each file, but you need to know the name they were registered as, which requires you to dig deep into code. I just wanted something that removed all of them, cleared it out. I couldn’t find a function that did this, so I made a workaround.

This is not supported by WordPress, so it may not work in the future, but works as of now. Also this only works if the css and js were added the correct way (via wp_enqueue_script() and wp_enqueue_style()) – if the styles and scripts are hardcoded in the theme, you’ll have to edit those theme files directly.

Clicktale’s free plan only allows you to see 2 page views per recording session. And that’s simply not enough to see if Clicktale is worth paying for. How are you supposed to decide whether to upgrade to a paid plan if you haven’t been able to gauge the power of the tool?

So, while you’re trying clicktale out, use this javascript bookmarklet to reveal the hidden page views. It simply hides the box that covers the screen after 2 pages have been seen. Drag the link below up to your browser bar, then you’ll have a button that you can press at the beginning of every playback which will prevent the box!

Today I was modifying someone else’s file when I noticed that when I uploaded it to the server it displayed horribly. All whitespace was gone, and in the place of newlines was ^M characters. Here’s a snapshot of how the file looked when I uploaded.

If I viewed it with ‘more filename.php’ I didn’t see the ^M but it looked as if the whole file was on one line, and some characters had been replaced by {. Strange.

It does not affect the server’s ability to run the file, but it does make maintenance a nightmare if you ever have to edit the file in the future.

I had been using Notepad++ (notepad plus plus) to edit it, and I had never had this problem with any of my files. Turned out the file had originally been made on a Mac, which caused these weird characters to show up (sometimes it happens on Windows too).

Luckily there’s an easy fix. With the file open in Notepad++, simply go to the Edit menu -> EOL Conversion -> Windows. It might also work if you choose Unix too. Then save the file, re-upload and you’re golden!

Part of the new geolocation api provides a method to get a user’s current position. In theory that’s awesome, but in practice it was returning inconsistent results. Sometimes it was accurate, other times it was off by miles. If I tried it multiple times in a row it would get more accurate, but only some of the time. The app I was working on needed better accuracy, so I tried a few things.

First I tried specifying the precision parameter (by default it is set to low precision):

This was MUCH more accurate, but it took about 45 seconds on my iphone to respond. Not okay. I looked to another solution: watchPosition(). It basically calls getCurrentPosition() multiple times so it can narrow in on where you are if you’re moving.

navigator.geolocation.watchPosition(centerMap);

Boom. Much better results. BUT it’s being called a lot, and I don’t want my map jumping around, I just want 1 accurate reading. I came up with the following solution:

Basically it starts watchPosition until 2 positions are returned (I mentioned earlier how the 2nd result is always more accurate than the first), then it stops following the user. I set the threshold to 2 because the success callback is only called when there is a change in location, so if I had set it higher and the user wasn’t moving I wouldn’t get what I want.

Every once in a while I get a submission to Song Key Finder that contains some weird characters (they showed up as boxes). I use the MusicBrainz database api to verify song and artist information, so my first thought was to consult with them. Since the characters appeared to be showing up in non-english songs, I looked into their international information:

MusicBrainz uses UTF-8 for all its data, which means that all the data is stored in Unicode and supports lots of different languages.

Got it. So now that I know their info is in UTF-8 I needed to make sure my page was being interpreted with that. Smashing Magazine provided a great article about character encodings which explains everything!

All the encoding problems…are caused by text being submitted in one character set and viewed in another. The solution is to make sure that every page on your website uses UTF-8. You can do this with one of these lines immediately after the <head> tag:

While attending the JavaScript conference FluentConf last week in San Francisco, I heard a few people talking about a tool called Errorception. They said it offered an easy way to track all the client-side errors your users are experiencing. Since I’m a fan of an error-free website, I decided to give it a try.

Signup was super simple – you don’t need a credit card to try it out and you can be up and running within minutes. I’ve only been using it for about a week so far, but here’s my list of pros and cons:

PROS

Reasonably priced. Their cheap plan is $5/month. Their 30 day free trial allows you to test it out without committing to anything.

Extremely high performance. After installing the code I profiled the load time of the script and it was about 5ms. I don’t think I’ve ever put anything on my pages that loads that quickly, not even static css on my own server.

Great interface. It groups duplicate errors to avoid muddying the reports. Everything is consolidated in an easy to read fashion and you can even get periodic emails letting you know of new errors.

Real-time. Errors started pouring in within minutes. I reached my daily cap (for my trial account) within about an hour.

It’s run by entrepreneur/developer Rakesh Pai. I emailed Rakesh a few questions and he went above and beyond helping me out. Rakesh is an extremely intelligent and thoughtful human being who wants everyone to succeed. He claims he’s no rock star, but what he’s been able to accomplish puts him in the class of Jimi Hendrix.

CONS

I’m having a hard time trying to replicate some of the errors. It provides you with the user’s browser and user agent and line number of the offending script, but that doesn’t seem to be enough. IE line numbers are reportedly innaccurate, and with so much JS minimized it’s hard to really trace the problem. Stack traces are not available. The website explains the reasoning for this and I agree with the choices that were made, so I’m not sure what to suggest. Since the goal of using this service is to eliminate errors I’m not sure how successful I’ll be if I can’t replicate them first.

SUMMARY

Great service run by great talent. The only shortcoming is perhaps a domain-problem that can’t be solved or a shortfall of my own programming intellect. I’d highly recommend anyone give it a shot by at least trying it out now.

We all hate captchas, so when I saw a new captcha alternative called Qaptcha I was slightly intrigued. Instead of typing in mangled words, you simply slide a slider bar to prove you are human. How simple!

But the more I looked at it, the more I thought about how it could be easily faked. All it’s doing is requiring a simple action on the client-side which would just call some ajax or something to set a cookie that you’re human. So why can’t a bot just call that javascript?

Turns out this is not secure at all. I posted on stack overflow and someone responded with a hack within a few minutes. Pretty impressive, but also pretty disappointing that it doesn’t accomplish what it’s supposed to.

I was curious if javascript was still executed by the browser even if it was within an element that is hidden in the DOM. A quick search yielded no conclusive evidence, so I decided to test myself.

Quick answer: Yes, it does still execute – for both inline and included javascript regardless of how it’s hidden (display:none or visibility:hidden).

I made a simple test script to see if scripts still run if hidden. Then I tested it on: Internet Explorer 7, 8, 9, Chrome, Safari, and Firefox and all work the same way.

Here’s the test script I used. Within each browser, I got 7 popup windows. In case you’re wondering. I wanted to test to see if including a javascript made any difference, so the ‘testjs.js’ script just makes a simple alert call.