Currently testing in the Testlab (26-09-2008)

Warning: date() [function.date]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /home/hemmi3/public_html/blog/inc/items/model/_itemquery.class.php on line 628

Warning: date() [function.date]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /home/hemmi3/public_html/blog/inc/items/model/_itemquery.class.php on line 628

The QR Code widget is new. I need to get the caching right and then it's ready to be released. It's completely useless. I usually love those features. Remember my Lottery plugin?
Fr some more information on what it's all about visit: QR Code. The core code that generates the image is QRcode Perl CGI & PHP scripts ver. 0.50. The code is fully procedural. I wrapped it in a class and am able to call it from the plugin. I later found a WordPress plugin using the same code. He wraps it in an ob_start to retrieve the image. Ugly poetry.

ob_start();
require_once 'php/qr_img.php';
$out = ob_get_contents();
ob_end_clean();

Where I do

require( 'qr_code/php/qr_img.php' );
$qr_code = new qr_img;
$qr_code->prepare_image( $data );

I had some serious troubles getting the image to display. It would output only weird characters. The function imagepng() should take care of that. I now save to file first (imagepng() does that if you provide a filename as second argument, very cool.)
This is the maximum I can get into a QR Code image. The text is 'The Raven' by Edgar Allan Poe and it's the first six stanza's only (2316 characters, according to the specs it should be possible to do more.)

Who said: "Code is poetry"?

As mentioned, it needs to be cached now. That's done before, so I'll manage. MD5 all the variables, add .png, generate the image with that name and put it in a cache folder. (No, I did not nick this idea from the author of the WordPress plugin, I saw it done earlier with the font replacement thingy).
Next I can make all variables as a setting, but no need for that, those variables are extremely specific, like Error Correction Capacity, forced size (it now calculates the size based on length of data, more data would mean a larger image) and such. Not really interesting, not even as a setting. Would any user care if the image is a jpeg or a png?

Next up is the shoutbox. Blueyed cracked it (I won't tell at this moment, but it wasn't that hard). There were two errors, one caused by adding console.log in the js. People without FireFox *and* FireBug got errors. I mistakenly thought

if(console.log){console.log('Hello World!)}

would stop errors, but IE complains and to my amazement so does FireFox. Note to non geeks: FireBug uses console.log to output some debug data. It's like the alert in javaScript but it outputs to the console in FireBug.
The other error is a MySQL error. It pops up from time to time and is related to he table where the messages are stored. This is the code that created that table:

				'CREATE TABLE ' . $this->get_sql_table( 'messages' ) . "(
			`id` int(7) NOT NULL auto_increment,
			`user` varchar(255) NOT NULL,
			`msg` text NOT NULL,
			`time` int(11) NOT NULL,
			PRIMARY KEY  (`id`)
		)"

I haven't found what's wrong there. The error, whenever it pops up is

No KEY/INDEX defined for AUTO_INCREMENT column!

If you have any idea please let me know.

That's all for now. Do visit this blog from time to time and keep playing with those gagdets. Feel free to register to this blog so your name will be autofilled in the shoutbox (Once again really useless.) As a bonus registered users can turn this blog back to English. Gerard Prins sent me a recent Dutch translation so I'm testing that as well.

Warning: mktime() [function.mktime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /home/hemmi3/public_html/blog/inc/_core/_misc.funcs.php on line 870

Warning: date() [function.date]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /home/hemmi3/public_html/blog/inc/_core/_misc.funcs.php on line 981

Warning: date() [function.date]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /home/hemmi3/public_html/blog/inc/_core/_misc.funcs.php on line 986

Warning: date() [function.date]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /home/hemmi3/public_html/blog/inc/_core/_misc.funcs.php on line 986

Warning: date() [function.date]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /home/hemmi3/public_html/blog/inc/_core/_misc.funcs.php on line 987

Warning: date() [function.date]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /home/hemmi3/public_html/blog/inc/_core/_misc.funcs.php on line 988
This entry was posted on September 26th, 2008
Warning: mktime() [function.mktime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /home/hemmi3/public_html/blog/inc/_core/_misc.funcs.php on line 870

Warning: date() [function.date]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /home/hemmi3/public_html/blog/inc/_core/_misc.funcs.php on line 981
at 03:24:48 am and is filed under Main category.

Trackback address for this post

2 comments

Comment from: admin [Member]

I found the bug mentioned in the last part of this post. All developers notice this:
In the file /inc/_core/model/db/_upgrade.funcs.php on line 980 it starts looking for a key in a particular table. It uses regex to scan the query that creates the table. Unfortunately it searches for AUTO_INCREMENT in capital characters only.
This is not really an error on my side. SQL works with small characters as well but it is common and good use to capitalize SQL keywords. I'll never forget it again.

Comment from: admin [Member]

Well that didn fix it. But i was hot. It's the same regex I mentioned in the previous comment.
From the database table at re-enabling the regex misses the PRIMARY KEY since I had `id` between ticks. Blueyed solved it. Users of later verion 1.0.4 will experience some problems, but are solved in later versions. Tblue found a fix for that: simply move the PRIMARY KEY to the line where `id`is declared and not as closing line. The true fix will be in an upgrade for B2evo, but that may take some time.

This post has 1 feedback awaiting moderation...

Comment feed for this post

Testlab B2evo 3.0 alpha