Whenever a client connects to the server, the server will look through all existing users and check if there is one that has the same account. If no, it allows the client to continue normally. If yes, it will send a “alive” message to the other client and first let the new client continue as usual. At the same time, it will wait for an answer from the other client. If a message is received, the new client will get disconnected, as the user is already connected.

This approach works very well on my server. To make this system work for guests too, a unique key would be needed for each user, which should get saved as a flash cookie (browser wide). That will also prevent the user trying to join by opening the chat in different browsers.

After endless hours of testing, I found out that for ExternalInterface to work in IE, 2 conditions have to be met.

1. The Flash needs to visible. Loading a flash into a hidden div does not work.
2. It has to be loaded before the document onload event. All Flash files loaded after the onload event can’t register any functions with ExternalInterface.

There seems to be an issue with transparent PNGs (with alpha channel) in IE 7, too. I had some ugly black background in the pictures even though other PNGs worked just fine. The reason was that it the div was hidden first. I guess IE 7 has some serious issues with invisible divs.

It finds all links automatically and if you want a specific link to be opened in a new window too, you’ll simply need to add rel="external" as an attribute of the link. Example:

<a href="http://www.junny.de/" rel="external">Junny's Blog</a>

People with Javascript disabled will have a normal link, whereas people with Javascript enabled will have a new window opened for them. You can download the script “Open In New Window” (oinw.js) here.

The script can be included just like any other Javascript:

<script type="text/javascript" src="oinw.js"></script>

Working on the Urania website plus making my cool new WordPress Plugin qTranslate pretty much took up all my time lately, so I haven’t been able to post anything. Sorry!

You won’t reach the black zone usually, but sometimes you do. And that’s when it gets annoying. Hosting a small website won’t get you into the black zone at all, but as soon as you do something on the server you will. The main problem is the memory limit, why make the virtual server think it has more memory than it actually has? To make it crash as soon as it wants more than I paid for?

Anyway, it’s time for a real root server. I talked with my friend Jonas and we decided to get one from Hetzner this time. They offer an Athlon 3700+ with 1 GB RAM and 2x 160GB hard disk for only € 49 a month, without setup fees. Traffic is included, the same goes for 6 IPs! So I ordered one yesterday. Let’s see when the server becomes available to me. Can’t wait to have my websites running lightning fast again.

Because I don’t want to be limited by some provider’s stupid limitations, I searched for a virtualized server. To avoid any unnecessary costs, I wanted a traffic flat rate too. My personal limit was € 20, if the server was performing nicely according to my expectations. I stumbled upon Keyweb, a hosting company with a really outdated, but still serious enough looking design. They offer two kinds of virtual servers, one kind is called “VRS” and the other “rootDS”. So what’s the difference between these two? Well, a rootDS has a guaranteed CPU speed whereas the VRS don’t. Because the rootDS prices start at € 25, I decided to get a VRS, so I ordered “VRS Start” for € 13 a month. Included in this price is a 10 Domain Plesk license, 256 MB guaranteed RAM and 2 IPs. Perfect, I thought, everything I wanted.

I ordered it one week ago and got it this Friday, that’s 3 days more than their promised delivery time. On top of that, I needed to call them several times. Just to clear things up, after my first call, the server was delivered within 2 days, but my order wasn’t processed at all before. Anyway, after getting the server, I found it running with Plesk 8.01, the worst possible version of Plesk. So I tried to update it, but it somehow crashed and Plesk wouldn’t start anymore. I didn’t know why, so I used the “Reinstall VRS” feature of Virtuozzo. It was a bad idea as it turned out to be messing things up even more. First it didn’t delete everything and then the fresh installation wasn’t working at all. Opening an Emergency Support Ticket solved my problem within 2 hours on Saturday 1:00 am.

So after I got the server running, I started migrating my websites with Plesk, but it always failed because Plesk went out of memory while decompressing the files. How can that be? I only got Apache running and that’s not taking 256 MB RAM away. A closer look with “top” showed me that the system has 2 GB of RAM, but Virtuozzo shuts the system down whenever the RAM usage goes above 384 MB, which is pretty stupid. The system and other processes takes out way too much RAM because it thinks there is still enough available. A lot on the QoS Alerts in Virtuozzo shows the idle system between yellow and green zone. Doing anything small causes the system to jump into the red zone. Uncompressing files will take you straight to the black zone, making Virtuozzo cancel any new memory request from the any process. This again causes processes to crash or freeze, where freezing will leave your system in the black zone, killing your own server just like a DoS-attack.

So in the end, the “VRS Start” virtual server can’t really be used at all, but Keyweb offers bigger virtual server for € 20 a month, called “VRS Premium”. I have immediately upgraded because I don’t want my server dying from a few web site requests. Upgrade was done 10 minutes after I ordered it. All in all the VRS seems to be pretty fast and stable from Keyweb and I hope I won’t have any more problems with it.

Afters hours of trying and fighting (especially with the IE box model bug), I found a way to realize this full height 2 column design with header and footer to work with Firefox, Opera and Internet Explorer (5.5, 6.0 and 7.0). So now, I am proud to be able to put the “W3C Valid XHTML 1.0 Transitional Logo” on my page.

After finishing the design, I started to work with Polygot. It’s not very intuitive, so it took me a day to figure it out how to get it completely working. Date Strings weren’t translated, and WordPress itself didn’t set the filter for “single_cat_title”, which broke the design with the long language string. So I needed to hack my way through. Now, all that is left is to translate everything. Because this is a long process, I’ll be doing it over time. So if you find something untranslated, please tell me. Thanks!

qin.at and qian.at

.at-domains are from Austria and still pretty expensive, that is why they were still unregistered. But due to an upgrade of services of our hoster, I got them for free. The normal price for an .at-domain is around € 49.00 each year plus setup fees. Well, you might find some new stuff there about me soon. Or shall I say http://qian.at/creating.a/new.website?

1. Moderation. If you save and review your comments, there will be no way for those spam messages to get through. But this method has one crucial disadvantage. Moderation needs time! So when you are busy, your comments won’t show up. Or even worse, when you get too much spam, you could accidentally delete ham (good posts).
2. Graphic verification. Many big websites uses this method. They show some code in an image which is readable by humans but not by bots. By asking the user to confirm the code, bots will be kept out very effectively. But using this is very annoying. Sometimes you can’t even correctly read the code.
3. Spam filter. This is just like using one for you mail program, but with possibility of false positives (ham being deleted).
4. Network based black lists. Some people try to use a blacklist of IPs which spammers use. This method has 2 major disadvantages. One is that spammers IP will change, always letting them through as soon as they change their IP. The other one is that Spam will be first let through.
5. Checksum method. This requires the user to have JavaScript turned on. When posting something, the browser calculates a checksum and sends it with the message to the server. The server checks whether the checksum matches. If it does, the post gets accepted or else rejected. But using this will keep all people without JavaScript from leaving messages.

Nothing really fitted my needs, so I thought around and combined Method 2 and 5 to a user friendly version. This is how my method works:

The server generates a 3-digit number and a verification field before the comment fields. At the same time, it inserts a hidden input field named “code” which contains the same number somehow encrypted. For now, this sounds like Method 2. Now here is the tricky part. Next, I added a JavaScript behind the comment field. This JavaScript reads and decrypts the code in the hidden input field and puts it in the verification field. At the same time, it hides the code and the verification field. This way, user with JavaScript on won’t need to enter the code. Only the users with disabled JavaScript will see the Code and the verification number. This Method comes from the idea that spammers have JavaScript disabled. JavaScript is slow and will slow down their process a lot. So when spammers disable it, they would have to enter the code which they cannot, so the bot spam will be kept out.

Of course this method isn’t perfect, as it doesn’t keep manually inputted spam away, but it will definitely not have any false positives. But this method will allow users with JavaScript to be able to comment comfortable.