Don’t use strtoupper with Japanese characters

It’s not like you can’t uppercase characters from Japanese, Chinese, Korean, etc languages, but certainly using strtoupper is not the proper method.

I have passed the last 48 hours trying to find an error that was dying one of my view scripts. No exception has been set or displayed and no error or warning what-so-ever was being displayed. Chasing a bug like this is one of the hardest things you can do.

After a lot of slashhamer debugging (echo mktime(); die;) and help from co-workers and friends I finally could find where the bug was.

The problem was that I was trying to display a Japanese encoded page and simply trying to strtoupper the title was failing and dying the whole script.

After this was found out, then the logical exit was using mb_strtoupper to uppercase it, but it also failed. This time it was fully my fault. Mb_strtoupper uses mb_internal_encoding to get (and set) the internal encoding to be used with that function. If you don’t specify the encoding it will simply get the default therefore failing on the function call creating the origin of my whole ghost bug.

The simple and complete solution for this was setting the encoding to UTF-8 while calling the mb_strtoupper function.

Point is, if you are using a multi-language system and is most likely to be under LATIM1, then whenever using the mb_* functions you must set them to UTF-8, otherwise you will be chasing a ghost bug (and it’s not fun).

Setting the mb_* functions is easy, one of the parameters is always the enconding, so, for example, for the mb_strtoupper function, the function call would be:

echo mb_strtoupper(‘大文字mcloide wordpressのドットドットコム’, ‘utf-8′);

Have fun …

Bug reporting

I have done a lot of applications and some of them had to be released in a Beta Version and as you probably know, beta is the first stable version that you can work with, but it might have a bug or two.

Most of the times I have just asked the users to submit an email with the feedback of what it’s going on. Most ot the times I have lost that email and had no reference about the bug.

I had two ways to work this out, one create a ticketing system or simply create a class that get’s the user information about the bug, saves and send an email.

Both have it’s pros and cons, but in this case I will release the bug class only. It’s simple, easy to adapt and it will store the bug information that is all that we need right now. 

You can download the class here and inside the class you will see (at top) the information about creating the table.

P.S. This class uses my MySQLiHandler class that is available in my older posts.

Important update: I have added more fields in the bug reporter and I have changed the way that the insert method works in the MySQLiHandler class. Please get the latest versions.

Google Maps in a tabbed profile

Consider that you have a profile page, tabbed, and in one of the tabs you have a Google Map with the pinpoint of the user. When the page loads, it will load the map aplication, but the map div will not be visible at that point.

When you hit the map tab, you will see the map loaded, but, with some areas missing or acting really weird.

What is happening is when the tab loads, the map is not fully loaded and the main document finishs to load before the map loads, so, it understands that the map area is smaller than really is and shows it like that, funny.

How to fix it? Simplier than you think. If you search around you are going to find some stuff like map force redraw, but there’s a simplier way to do it.

Add a setTimeout to load the map.

Here’s the whole process. Remove the onLoad=”loadThis()” from the body and inside the map tab, just after the map div, put the a javascript like this: setTimeout(‘loadThis()’,1000);

That’s all you need and your map will have more than enought time to load all info and display correctly.

Have fun.